Re: 3.6rc6 slab corruption.

[David Rientjes]

On Wed, 19 Sep 2012, Linus Torvalds wrote:

> That does look simpler, and avoiding the lock is a good idea. Since we
> don't support lseek() (or pread/pwrite) on that thing anyway, there's
> no way to keep the fd open and just re-use it to read the data over
> and over, so populating it at open time sounds like a good solution
> with no real downsides.
> 

Yeah, my patch is functionally the same as what we currently have with the 
only exception being that it isn't racy.  I'm wondering if that's what we 
really want, though, since the data read from the file will remain 
persistent as long as it is opened.  That obviously happens in my patch 
because we allocate and copy the buffer at open(), but also happens 
implicitly with the old code precisely because it's a non-seekable file 
and *ppos == 0 only once (when not racy).

So if the API for these xen files is to remain persistent after open() as 
it currently does, then my patch solves the issue.  However, if the API 
wants to allow to only open() once and then read the spinlock_stats data 
continuously, then we'll need the mutex: allocate the file->private_data 
buffer once at open() for the maximum allowable size and then copy to the 
buffer from xen's spinlock_stats under the protection of the mutex to 
read().

Konrad?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/