Messages in this thread | | | Date | Wed, 19 Sep 2012 14:27:37 -0700 (PDT) | From | David Rientjes <> | Subject | Re: 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.
| |