summaryrefslogtreecommitdiff
path: root/fs/ext4/super.c
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2011-02-12 16:12:18 +0300
committerTheodore Ts'o <tytso@mit.edu>2011-02-12 16:12:18 +0300
commit2892c15ddda6a76dc10b7499e56c0f3b892e5a69 (patch)
treebd2aa2add525d91991975e5678ef5bfe9175bdd8 /fs/ext4/super.c
parentd50bdd5aa55127635fd8a5c74bd2abb256bd34e3 (diff)
downloadlinux-2892c15ddda6a76dc10b7499e56c0f3b892e5a69.tar.xz
ext4: make grpinfo slab cache names static
In 2.6.37 I was running into oopses with repeated module loads & unloads. I tracked this down to: fb1813f4 ext4: use dedicated slab caches for group_info structures (this was in addition to the features advert unload problem) The kstrdup & subsequent kfree of the cache name was causing a double free. In slub, at least, if I read it right it allocates & frees the name itself, slab seems to do something different... so in slub I think we were leaking -our- cachep->name, and double freeing the one allocated by slub. After getting lost in slab/slub/slob a bit, I just looked at other sized-caches that get allocated. jbd2, biovec, sgpool all do it more or less the way jbd2 does. Below patch follows the jbd2 method of dynamically allocating a cache at mount time from a list of static names. (This might also possibly fix a race creating the caches with parallel mounts running). [Folded in a fix from Dan Carpenter which fixed an off-by-one error in the original patch] Cc: stable@kernel.org Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/super.c')
0 files changed, 0 insertions, 0 deletions