[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E807713.5060401@free-electrons.com>
Date: Mon, 26 Sep 2011 14:58:59 +0200
From: David Wagner <david.wagner@...e-electrons.com>
To: dedekind1@...il.com
CC: linux-mtd <linux-mtd@...ts.infradead.org>,
linux-embedded <linux-embedded@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Tim Bird <tim.bird@...sony.com>,
David Woodhouse <dwmw2@...radead.org>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCHv6] UBI: new module ubiblk: block layer on top of UBI
Hi,
On 09/23/2011 12:58 PM, Artem Bityutskiy wrote:
[...]
> 2. Please, could you explain what prevents the following crash/issue:
>
> modprobe ubiblk volumes=0:0
> mkfs.ext3 /dev/ubiblk0
> mount -t ext3 /dev/ubiblk0 /mnt/fs
> rmmod ubiblk
>
> Not that I think this is a problem, I just do not realize what would
> prevent ubiblk from being unloaded when it is mounted. Did you test this
> scenario?
I forgot to address this in the v7, so:
The kernel has an internal refcounter for each module. It increases
with each module that uses it and for each open device owned by it.
In the case of ubiblk, we have:
static const struct block_device_operations ubiblk_ops = {
.owner = THIS_MODULE,
.open = ubiblk_open,
.release = ubiblk_release,
};
The "owner" field makes ubiblk devices owned by ubiblk, so each open
device increases the refcounting and if the user tries to rmmod ubiblk
when there are still open ubiblk devices, it will get an EBUSY error.
Regards,
David.
--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists