On Wed, 2008-04-16 at 10:15 +0200, Pavel Machek wrote: > On Tue 2008-04-15 22:28:55, Peter Zijlstra wrote: > > On Tue, 2008-04-15 at 22:06 +0200, Pavel Machek wrote: > > > > > > > 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. > > Why not? Kernel syscalls are traditionally atomic, and Lennard seems > to have found sentence in POSIX that says so. Ah, ok missed that part. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
