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    [from the cache]
©2003-2011 Jasper Spaans