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 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).

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.


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