lkml.org 
[lkml]   [2006]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-09-08 00:11    [W:0.044 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site