]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
ext4: make grpinfo slab cache names static
authorEric Sandeen <sandeen@redhat.com>
Sat, 12 Feb 2011 13:12:18 +0000 (08:12 -0500)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 17 Feb 2011 23:14:21 +0000 (15:14 -0800)
commit2be2f98b96e349873e45705b52a967149acd90b7
treef3dbd49302a16d9a1a724451496a55a490a6ffa7
parent617d99a8ddc9a8cfc8ab53b268e7f344c2c30c9e
ext4: make grpinfo slab cache names static

commit 2892c15ddda6a76dc10b7499e56c0f3b892e5a69 upstream.

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]

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/ext4/mballoc.c