On Mon, Nov 02, 2009 at 04:51:52PM +0100, Arnd Bergmann wrote: > I looked at what places in the code manipulate file->f_pos directly > and found that almost all the uses in driver code are broken because > they don't take any locks. Most of them are in driver specific > lseek operations. Others are in read/write methods and are even > more broken because the change gets immediately overwritten by > vfs_read/vfs_write when the driver method returns. > > IMHO, we should complete the pushdown into all ioctl methods > that John and Thomas have started working on, fixing the lseek > methods in those files we touch. > > When that is done, all interaction between default_llseek and > driver locking has to be with explicit calls to lock_kernel > in those drivers, so we can reasonably well script the search > for drivers needing the BKL in llseek: everyhing that > a) defines file_operations without an llseek function, > b) touches f_pos somewhere, and > c) calls lock_kernel() somewhere > That should only be a small number and when they are fixed, > we can remove default_llseek and instead call generic_file_llseek > for any file operation without a separate llseek method.
As mentioned before making generic_file_llseek the new default is probably a bad idea. The majority of our file_operations instances don't actually support seeking, so no_llseek should become the new default if you spend some effort on converting things. Anything that wants to allow seeking will have to set a llseek method. This also mirrors what we do for other file operations. None of the major ones has a non-trivial default, it's either silently succeeding for a selected few like open or release or returning an error for operatings that actually do something like read and write. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev