From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from majordomo by infradead.org with local (Exim 3.03 #1) id 12daON-0001cU-00 for mtd-list@infradead.org; Fri, 07 Apr 2000 16:09:51 +0100 Received: from gate.mvhi.com ([194.205.184.34] helo=server.axiom.internal ident=mail) by infradead.org with esmtp (Exim 3.03 #1) id 12daOM-0001cO-00 for mtd@infradead.org; Fri, 07 Apr 2000 16:09:50 +0100 From: David Woodhouse In-Reply-To: References: To: Alexander Larsson Cc: mtd@infradead.org Subject: Re: get_mtd_device() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Apr 2000 16:11:58 +0100 Message-ID: <8078.955120318@devel2.axiom.internal> Sender: owner-mtd@imladris.demon.co.uk List-ID: alex@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@infradead.org