Messages in this thread Patch in this message | | | Date | Mon, 9 Jun 2008 16:28:09 +0200 | From | "Vegard Nossum" <> | Subject | Re: [bug, 2.6.26-rc4/rc5] sporadic bootup crashes in blk_lookup_devt()/prepare_namespace() |
| |
On 6/9/08, Vegard Nossum <vegard.nossum@gmail.com> wrote: > It seems that this list (block_class.devices) is protected by > block_class_lock in block/genhd.c. This list is only ever modified by > device_add() and device_del() in drivers/base/core.c. Both of those > are (only) protected by dev->class->sem, however. Is there a locking > mismatch here? But none of the locking code here seems to be changed > in years...
I think this seems correct.
Everywhere else where we traverse the struct class->devices list, they have down(&class->sem); first and up(&class->sem); afterwards.
Commit fd04897bb20be29d60f7e426a053545aebeaa61a even has this hunk: @@ -177,8 +177,7 @@ struct class { struct list_head devices; struct list_head interfaces; struct kset class_dirs; - struct semaphore sem; /* locks both the children and interface - + struct semaphore sem; /* locks children, devices, interfaces */ struct class_attribute * class_attrs; struct class_device_attribute * class_dev_attrs; struct device_attribute * dev_attrs;
So why doesn't block/genhd.c do this too? It seems to me that the mutex locking here is simply a remnant of old code that happened to not crash in most cases by chance.
Vegard
-- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036
| |