On Fri, 28 Jul 2000, Alan Cox wrote:
> > > Audit all char and block drivers to ensure they are safe with the 2.3
> > > locking - a lot of them are not especially on the open() path.
> >
> > What about the open() path? They have (or grab) BKL there, so it should
> > not be something special. Now, read() and write()...
>
> They dont all get open right either ;) And yes a lot get read/write wrong
Oh? I would be glad to know where I've fscked up - I'll fix that. I went
through all ->open() instances and placed BKL into every dubious one.
Notice that chain callers inherit the protection - e.g. BKL in
chrdev_open() protects those instances of ->open() who are called only in
that place, etc. To the best of my knowledge everything that can be called
directly (not by other ->open() instance) is either obviously SMP-safe or
grabs BKL itself. Everything that may end up in ->i_fop->open() or
->proc_fops->open() should be OK, unless I've fscked up...
I have a patch moving BKL all way down the chain for character devices
(not a big deal, there were several [3 or 4] places that required
non-trivial changes to make them SMP-safe, the rest was mechanical
shifting). But I'm not sure that it's really worth it. Having no
exceptions in the locking rule (i.e. "_every_ ->open() may be called
without BKL") would be nice, but it would mean an additional work for
3rd-party folks - I've covered all instances in the tree, but I'm not
fscking clairvoyant and can't remotely fix 3rd-party code...
BTW, fops_get() uses try_inc_mod_count() now, so rmmod problems for
file_operations are gone. Subsystems that use something else (TTY, etc.)
are still vulnerable, though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:28 EST