On Tue, 2008-04-15 at 22:06 +0200, Pavel Machek wrote:

quoted text
> > > I'm not saying this kernel bug is likely to hit in practice. It is
> > > still a kernel bug.
> > > 
> > > Is the slowdown of lseek worth getting rid of this minor bug? Not
> > > sure, probably yes.
> > 
> > I think a slow down is the worse choice.  Adding a note to the
> > documentation saying that "By the way, on 32bit systems the seek call is
> > not atomic for 64bit file offsets, so if you happen to issue two at
> 
> That would be very wrong addition to documentation. If you really
> wanted to do something like this, you would probably want to say
> something like
> 
> "Doing concurrent seeks on one file is undefined. Kernel may end up
> with seeking to some other place."
> 
> Unfortunately, you'd have to get this addition into POSIX standard...

Is not treating the point not similar to undefined? And undefined
semantics cover pretty much anything, including the current behaviour.

FWIW I really think this issue is a non-issue; one cannot expect sane
behaviour of unsynchronized usage of a shared resource.

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