Messages in this thread | | | Date | Tue, 25 Jan 2000 00:24:59 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [RFC] change in /proc/devices |
| |
On Tue, 25 Jan 2000, Alan Cox wrote:
> > But sys_open does lock_kernel(), filp_open(), unlock_kernel(). > > file_open drives module_init etc. All the module initialization should > > be running under the big kernel lock, the second open should suspend > > lock_kernel is a lock only for _non_blocking_ code cases.
Yup.
> > until the first one completes. If we are seeing races then something > > is dropping the kernel lock at the wrong place or not reaquiring it > > correctly. > > It is being dropped when drivers block - eg partition scanning perhaps or > a kmalloc of GFP_KERNEL.
It's mostly the latter case.
> I think perhaps we need a module_lock that forbids just module load/unload > when its held. A reader/writer lock with the unload as the writer and > the rest as readers ?
IMO I have a better variant. I'm doing an equivalent of routing for the device numbers. I.e. maintain a tree of devno blocks. The lowest layer (leaves) consists of disk ranges. The next one consists of the ranges assigned to drivers. Now, every range is created locked. I.e. any lookup (I'm doing them on blkdev_{get,open} if block_device is not bound to disk_struct yet) will block if it meets a locked range. When driver had registered all disks it unlocks the driver ranges (disk ranges are unlocked in the end of register_disk()). Removing a locked range wakes everybody blocked, indeed. That solves the problem with races upon load. Unloading the module is trickier, but simple move of unregister_blkdev() (erm... unregister_block_driver() in the new variant - they have different arguments, so I don't like the idea of reusing the name) into the very beginning of module_cleanup() does the thing.
But yes, module unloading is pain in ass, for in _many_ places we are doing the wrong thing wrt the access to module-provided data. Proper threading will be very painful, so I don't think that it's 2.4 stuff - we will have to do serious analysis of places where we export/use such data. And it's not going to be pleasant.
- 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/
| |