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.023 / U:1.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site