I was looking at the code for register_blkdev and unregister_blkdev. I
found that no
locking (spinlocks) are used to protect the blkdevs struture in these
functions. I suspect
we have not seen a problem till now since
Either
1. register_blkdev is called from modules, and only module
initialization is protected.
2. register_blkdev is called during init time for drivers in the kernel
and I am not sure
about whether calls to register_blkdev at this time are implicitly
serialized, since only
1 CPU is active during initialization
Anway, what I needed to know was if (1) and (2) are enough to ensure
safety in register_blkdev
and unregister_blkdev.
May be I am missing something, there is already some lock which is held
before these routines
are invoked, I could not find any.
Comments
Thanks,
Balbir Singh.
On Wed, 10 Oct 2001, BALBIR SINGH wrote:
> I was looking at the code for register_blkdev and unregister_blkdev. I
> found that no
> locking (spinlocks) are used to protect the blkdevs struture in these
> functions. I suspect
> we have not seen a problem till now since
... they are only called under BKL; ditto for lookups in the tables they
(de-)populate.
Alexander Viro wrote:
>>I was looking at the code for register_blkdev and unregister_blkdev. I
>>found that no
>>locking (spinlocks) are used to protect the blkdevs struture in these
>>functions. I suspect
>>we have not seen a problem till now since
>>
>
>... they are only called under BKL; ditto for lookups in the tables they
>(de-)populate.
>
What I wanted to know was, who is calling/holding the BKL? Is it because
lock_kernel is called in sys_create_module() and sys_init_module().
I also looked at sd.c, it does not hold the BKL before calling register_blkdev()
it calls devfs_register_blkdev() from sd_init().
Maybe I am still missing something.
Balbir
On Wed, 10 Oct 2001, BALBIR SINGH wrote:
> Alexander Viro wrote:
>
> >>I was looking at the code for register_blkdev and unregister_blkdev. I
> >>found that no
> >>locking (spinlocks) are used to protect the blkdevs struture in these
> >>functions. I suspect
> >>we have not seen a problem till now since
> >>
> >
> >... they are only called under BKL; ditto for lookups in the tables they
> >(de-)populate.
> >
> What I wanted to know was, who is calling/holding the BKL? Is it because
> lock_kernel is called in sys_create_module() and sys_init_module().
All module init code is under BKL and will stay that way for a long time.
If that ever becomes not true, we are in for much more pain that
register_blkdev() races - you would need to do audit of all drivers to
pull something like that.
Alexander Viro wrote:
>All module init code is under BKL and will stay that way for a long time.
>If that ever becomes not true, we are in for much more pain that
>register_blkdev() races - you would need to do audit of all drivers to
>pull something like that.
>
I suspected that the locking in init_module was preventing bad
things from happening in {devfs_}register_blkdev, I am sure now.
Balbir