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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
