Clearly f_pos atomicity has been handled differently in the not-so-distant past:
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg01628.html
And equally clearly the current generic_file_llseek semantics are
erroneous for large offsets, and we shouldn't be taking the inode
mutex in any case other than SEEK_END:
http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100584441922835&w=2
read_write.c is a perfect example of the relative amateurishness of
parts of the Linux kernel. It has probably gone through a dozen major
refactorings in fifteen years but has never acquired a "theory of
operations" section justifying the errors returned in terms of
standards and common usage patterns. It doesn't have assertion-style
precondition/postcondition checks. It's full of bare constants and
open-coded flag tests. It exposes sys_* and vfs_* and generic_file_*
without any indication of which sanity checks you're bypassing when
you call the inner functions directly. It leaks performance right and
left with missing likely() macros and function calls that can't be
inlined because there's no interface/implementation split. And then
you want to tell me that it costs too much to spinlock around f_pos
updates when file->f_count > 1? Give me a break.
-
