Re: VFS locking: f_pos thread-safe ?

[Andrew Morton]

Matt <dirtbird@xxxxxxxxxxxx> wrote:
>
> > Werner Almesberger <wa@xxxxxxxxxxxxxxx> wrote:
> >>
> >> "[...] read( ) [...] shall be atomic with respect to each other
> >>   in the effects specified in IEEE Std. 1003.1-200x when they
> >>   operate on regular files. If two threads each call one of these
> >>   functions, each call shall either see all of the specified
> >>   effects of the other call, or none of them."
> 
> > Whichever thread finishes its read last gets to update f_pos.
> 
> > I'm struggling a bit to understand what they're calling for there.  If
> > thread A enters a read and then shortly afterwards thread B enters the
> > read, does thread B see an f_pos which starts out at the beginning of A's
> > read, or the end of it?
> 
> > Similar questions apply as the threads exit their read()s.
> 
> > Either way, there's no way in which we should serialise concurrent readers.
> > That would really suck for sensible apps which are using pread64().
> 
> Surely, we can just serialise read() (and related) calls that modify f_pos?
> Since pread() doesn't modify f_pos we shouldn't need to serialise those calls
> no? Also doesn't spec make the same claims about other calls that modify
> f_pos such as write()?

We could do somethnig like that.

But is there any application in which two threads simultaneously perform
read() against the same fd which is not already buggy?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/