Hi! > So other than that, is there any case in which lseek being not atomic > can cause an application to break if it wasn't already broken (due to > having a race condition by trying to do 2 or more seeks on the same file > handle at the same time)? If not, I think adding any kind of locking to > seek in the kernel (which would I think have to cause a slight slow > down) is a bad move. But hey that's just my opinion. :) I won't be > upset either way. Of course I can write an application that will be broken by this, and was not broken before. It will be slightly nasty code. Come on, you can do this too ;-). > > 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... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
