[RFC] change in /proc/devices

[Alexander Viro]

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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/