Oliver Neukum wrote: > Am Mittwoch, 18. November 2009 18:27:30 schrieb Jamie Lokier: > > > No. Your logic is flawed > > > > > > The BKL is protected something here - it protects the change of offset > > > with respect to other BKL users within drivers. The question is what if > > > anything in any other driver code depends upon the BKL and uses it to > > > protect f_pos. Probably very little if anything but a grep for f_pos > > > through the drivers might not be a bad idea before assuming this. Very > > > few touch f_pos except in their own llseek method. > > > > Of course, drivers shouldn't be using f_pos outside their llseek > > method, as they should all behave the same with pread/pwrite as with > > llseek+read/write. > > Might not a driver update f_pos after read/write? It could indirectly, through *ppos. There should be no direct accesses to f_pos outseek llseek. If there are still, those might indicate driver bugs. (I'm not 100% sure about this - hence asking). Drivers used to update f_pos indirectly through *ppos, and for this, Alan's observation about BKL protecting the value from changing does apply. But nowadays, even that doesn't happen. sys_read() and sys_write() make a copy of f_pos using file_pos_read(), so drivers cannot see the value change during the call - except for their own change. I find myself wondering why the VFS isn't responsible for the position update instead of the driver... Would it be a valid cleanup to move it from the driver to VFS? -- Jamie -- 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
