On Wed, 21 Oct 2009, Frederic Weisbecker wrote:
> On Wed, Oct 21, 2009 at 11:33:17PM +0200, John Kacur wrote: > > > Should we better pushdown default_llseek to every to every > > > file operations that don't implement llseek? > > > I don't know how many of them don't implement llseek() though. > > > > > > That said we can't continue anymore with this default attribution > > > of default_llseek() on new fops. > > > > > > > If you don't explicitly set it to no_llseek, you automatically get the > > default_llseek, which uses the BKL. So if your driver doesn't need it, it > > is best to explicitly set it to no_llseek. > > > Sure, that's the right thing to do. > > > > There is also a generic_file_llseek_unlocked, somewhat analogous to the > > unlocked_ioctls that you can use if you don't need to provide a full > > llseek yourself. > > > No problem with that. Setting no_llseek or generic_file_llseek_unlocked, > depending on the context is the right thing to do. > > What I'm wondering about concerns the future code that will have > no llsek() implemented in their fops. > > We can't continue to use default_llseek() for future code unless we > want to continue these post reviews and fixes forever. > I'm thinking that the simplier approach, would be to make the default_llseek the unlocked one. Then you only have to audit the drivers that have the BKL - ie the ones we are auditing anyway, and explicitly set them to the bkl locked llseek. There might be a hidden interaction though between the non-unlocked variety of ioctls and default llseek though. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
