lkml.org 
[lkml]   [2009]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: Fix f_flags races without the BKL
    On Mon, Dec 29, 2008 at 04:13:52AM -0700, Jonathan Corbet wrote:
    > Accesses to the f_flags field have always involved a read-modify-write
    > operation, and have always been racy in the absence of the BKL. The recent
    > BKL-removal work made this problem worse, but it has been there for a very
    > long time. The race is quite small, and, arguably, has never affected
    > anybody, but it's still worth fixing.
    >
    > After pondering for a while, I couldn't come up with anything better than a
    > global file->f_flags mutex. There's no point in bloating struct file with
    > a mutex just for this purpose; it's hard to imagine that there will be any
    > real contention for this lock.

    Bloating with mutex is over the top, indeed, but why can't we simply keep
    a pointer to fasync_struct in there? Do we ever have a struct file with
    several fasync_struct? They'd have to be on different queues and I don't
    see any cases where that would happen...


    \
     
     \ /
      Last update: 2009-01-02 19:45    [W:0.020 / U:90.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site