> POSIX defines "the right thing".  the last version of SUS is apparently
> different, but previous versions did specify atomicity requirements for
> read() and write().

Oh, yes. The atomicity, where read() won't be exposed to
partial write()s, is important. Good point.
 
> > If the application layer isn't taking care of such races, arbitrary
> > rules in the kernel or (the|a) file system won't save them.
> > 
> > Consider stat(2). ...
> > There is non-zero probability that the struct st in userland is
> > stale before control is returned to the application, let alone
> > whether it's accurate when acted upon (like ls(1) printing).
> 
> the issue we're discussing is read() and write() serialization.
> yes, the info returned by stat() can become stale before an application
> gets a chance to look at it, but that's not relevant for the
> topic at hand.

In terms of atomicity, I agree.

Most system interfaces observe volatile state. The scenario
for stat() could just as easily be a scenario for read().
Introduce something like NFS into the mix and the probability
increases.

What I was driving at is that over aggressive serialization can't
ever overcome the volatility, but could be counterproductive
to the motivations of something like O_DIRECT.

> > These races simply can't be overcome below the syscall level.
> > 
> > In short, nobody should worry about serializing intersecting
> > direct reads/writes (or non-direct for that matter) too much.
> > Don't worry, be happy.
> 
> some applications rely on this serialization, so it does seem
> appropriate to worry about it.

I think what you mean to say is some applications rely on
the atomicity guarantees rather than serialization. Or am
I missing something?

Regards,
	-gww