Re: 3.6rc6 slab corruption.

[Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>]

On 09/20/2012 08:16 AM, David Rientjes wrote:
> On Thu, 20 Sep 2012, Raghavendra K T wrote:
>
>> Only problem, I find is histogram data expands dynamically (because it
>> changes). I think having static allocation of 352 bytes as suggested
>> Linus is a good idea.
>>
>
> Certainly, but it's a different topic and would be a subsequent patch to
> either my patch or Konrad's patch.  Before that's done, I think we should
> fix the race condition that currently exists either by:
>
>   - merging my patch (which I can sign-off and write a changelog for if
>     Konrad agrees), or
>
>   - merging Konrad's patch and introducing a mutex so that it's possible to
>     do many reads to collect statistics after opening the file a single
>     time with a single fd.
>
> Since these files are incapable of doing lseek, it would seem that my
> patch would be best and you'd simply want to close() + open() to read new
> data, which also guarantees that all readers get the same information.
> The only reason I hesitate on that and will defer to Konrad's opinion is
> because the way the code is currently written looks like it was intended
> to copy the data are read() rather than open(); in other words, it almost
> seems as if they were made to be non-seekable after the u32_array_read()
> implementation was complete and it was at one time possible to do an
> lseek(SEEK_SET).

Yes. common use case is just open once,read and close.
i.e. cat /sys/kernel/debug/../histoblocked

I also don't see why we have to keep fd open to read it.
But yes let Konrad comment on that.


> After that's fixed, and to address your concern, we can simply do the
> allocation of file->private_data for the maximum size possible when the
> file is created as a follow-up patch.

I agree, missed that once we do a open and then read it we are done.