Messages in this thread Patch in this message | | | Date | Fri, 8 Sep 2006 02:08:53 +0400 | From | Alexey Dobriyan <> | Subject | Re: Naughty ramdrives |
| |
> So I assume udev is still madly crunching on its message backlog while > this is happening? > > If so, ug.
OK. I'll let it stabilize, sorry.
> > This was noticed while investigating #4899 > > http://bugme.osdl.org/show_bug.cgi?id=4899 > > where /dev/ram0 when opened, pins module indefinitely. It seems that > > adding ->release() which undoes > > > > inode = igrab(bdev->bd_inode); > > > > should do the trick. Am I right?
> Looks right. > > I'm not sure that igrab() is needed though. Probably bd_openers is > sufficient. > > I'm also not sure that rd_open() needs to play with bd_openers. > fs/block_dev.c:do_open() already does that.
Maybe start with closing open/open race? That's what drivers/char/raw.c does... ------------------------------------------------ [PATCH 1/2] rd: protect rd_bdev[] with mutex
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> ---
drivers/block/rd.c | 4 ++++ 1 file changed, 4 insertions(+)
--- a/drivers/block/rd.c +++ b/drivers/block/rd.c @@ -56,6 +56,7 @@ #include <linux/buffer_head.h> /* for i #include <linux/backing-dev.h> #include <linux/blkpg.h> #include <linux/writeback.h> +#include <linux/mutex.h> #include <asm/uaccess.h> @@ -63,6 +64,7 @@ #include <asm/uaccess.h> */ static struct gendisk *rd_disks[CONFIG_BLK_DEV_RAM_COUNT]; +static DEFINE_MUTEX(rd_mutex); static struct block_device *rd_bdev[CONFIG_BLK_DEV_RAM_COUNT];/* Protected device data */ static struct request_queue *rd_queue[CONFIG_BLK_DEV_RAM_COUNT]; @@ -343,6 +345,7 @@ static int rd_open(struct inode *inode, { unsigned unit = iminor(inode); + mutex_lock(&rd_mutex); if (rd_bdev[unit] == NULL) { struct block_device *bdev = inode->i_bdev; struct address_space *mapping; @@ -382,6 +385,7 @@ static int rd_open(struct inode *inode, gfp_mask |= __GFP_HIGH; mapping_set_gfp_mask(mapping, gfp_mask); } + mutex_unlock(&rd_mutex); return 0; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |