lkml.org 
[lkml]   [2012]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 3.6rc6 slab corruption.
On Wed, 19 Sep 2012, Linus Torvalds wrote:

> > Create a 350 processes reading /sys/kernel/debug/kvm/spinlocks/histo_blocked
> > file simultaneously in while loop for more than 3 hours on my box.
>
> You need to open the file a single time, and then after that sinelg
> open (either threaded or with fork()) do multiple concurrent copies
> something like
>
> for (;;) {
> char buf[1024];
> lseek(fd, 0, SEEK_SET);

These are non-seekable files, so this will always fail. That makes the
race much more difficult to trigger: the read needs to call
u32_array_read() with both threads finding *ppos == 0 and then race
between the kfree() and resetting of file->private_data pointer.

[ I'm surprised that Dave was able to trigger this so often that he has
800MB of log. ]

Anyway, I instrumented the kernel to open the race by sleeping after
checking *ppos == 0 and immediately after the kfree() and I could
reproduce the issue but with a "Object already free" error rather than a
redzoning error.

I assumed this was because Dave didn't have a certain slub debug option
enabled or redzoning was checked before double-free, but it turns out this
should always be caught first. For some reason the freed object is not
being found on the partial slab's freelist.

> read(fd, buf, sizeof(buf));
> }
>
> or similar. But it's important that they all share the same struct file.
>
> It's also likely to make it easier to trigger the race if you have a
> kernel with preemption enabled.
>
> And you need to have SLAB debugging enabled to actually *see* the
> messages. Otherwise you'll have just (possibly silent) corruption or a
> memory leak.


\
 
 \ /
  Last update: 2012-09-20 00:01    [W:0.066 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site