get_mtd_device()
David Woodhouse
dwmw2 at infradead.org
Fri Apr 7 11:11:58 EDT 2000
alex at cendio.se said:
> Why was get_mtd_device() removed?
Locking issues.
I need to change the __MOD_INC_USE_COUNT(mtd->module) calls in the user
modules to use try_inc_mod_count() on 2.3, and to deal appropriately with
failure. This will make me mostly happy about the race conditions which
currently exist with drivers being unloaded at the same time as a user
module's open() function is being called on a different CPU.
This means that the driver module unload path goes...
Acquire unload_lock in kernel/module.c
call cleanup_module()
-> Acquire mtd_table_mutex
Remove the mtd_info from the list
Drop mtd_table_mutex
Drop unload_lock
Now, I'm unhappy that I've just noticed that the unload_lock is a spinlock and
hence perhaps cleanup_module() shouldn't be allowed to sleep, and hence can't
try to acquire the mtd_table_mutex semaphore.
But besides this problem, which is going to bite a _lot_ of things, the
behaviour of get_mtd_device would have to be something like...
Acquire mtd_table_mutex
go through the mtd_table to get the one we want
call try_inc_mod_count()
--> Acquire unload_lock
increase the use count
Drop unload_lock
Drop mtd_table_mutex
Spot the deadlock. If you can tell me how to fix it, you can have
get_mtd_device() back :)
> I need it or something like it in jffs to get the mtd device from the
> minor device of the mtdblock device i shall mount.
Could we add an ioctl() to mtdblock instead, to allow jffs to get direct
access to the mtd_info struct that way?
Actually, I'd prefer in the end that mtdblock not be required for jffs to work
- after all, it's not really necessary except to keep mount(8) happy.
We ought to be able to use 'mount /dev/mtd0 -tjffs /mnt/wherever'
--
dwmw2
To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
More information about the linux-mtd
mailing list