2008-07-14 06:06:35

by Tejun Heo

[permalink] [raw]
Subject: [PATCH] block: fix block_class iteration locking

genhd.c used block_class_lock when it wants to iterate over
block_class.devices list. This is incorrect as block_class_lock has
nothing to do with synchronization around block_class.devices list, so
there's a window, albeit small, where the list can change while it's
being iterated over. Fix it by using block_class.sem instead.

Signed-off-by: Tejun Heo <[email protected]>
---
block/genhd.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index b922d48..b646e7e 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -234,7 +234,7 @@ void __init printk_all_partitions(void)
char buf[BDEVNAME_SIZE];
int n;

- mutex_lock(&block_class_lock);
+ down(&block_class.sem);
/* For each block device... */
list_for_each_entry(dev, &block_class.devices, node) {
if (dev->type != &disk_type)
@@ -275,7 +275,7 @@ void __init printk_all_partitions(void)
}
}

- mutex_unlock(&block_class_lock);
+ up(&block_class.sem);
}

#ifdef CONFIG_PROC_FS
@@ -285,7 +285,7 @@ static void *part_start(struct seq_file *part, loff_t *pos)
loff_t k = *pos;
struct device *dev;

- mutex_lock(&block_class_lock);
+ down(&block_class.sem);
list_for_each_entry(dev, &block_class.devices, node) {
if (dev->type != &disk_type)
continue;
@@ -311,7 +311,7 @@ static void *part_next(struct seq_file *part, void *v, loff_t *pos)

static void part_stop(struct seq_file *part, void *v)
{
- mutex_unlock(&block_class_lock);
+ up(&block_class.sem);
}

static int show_partition(struct seq_file *part, void *v)
@@ -533,7 +533,7 @@ static void *diskstats_start(struct seq_file *part, loff_t *pos)
loff_t k = *pos;
struct device *dev;

- mutex_lock(&block_class_lock);
+ down(&block_class.sem);
list_for_each_entry(dev, &block_class.devices, node) {
if (dev->type != &disk_type)
continue;
@@ -560,7 +560,7 @@ static void *diskstats_next(struct seq_file *part, void *v, loff_t *pos)

static void diskstats_stop(struct seq_file *part, void *v)
{
- mutex_unlock(&block_class_lock);
+ up(&block_class.sem);
}

static int diskstats_show(struct seq_file *s, void *v)
@@ -658,7 +658,7 @@ dev_t blk_lookup_devt(const char *name, int part)
struct device *dev;
dev_t devt = MKDEV(0, 0);

- mutex_lock(&block_class_lock);
+ down(&block_class.sem);
list_for_each_entry(dev, &block_class.devices, node) {
if (dev->type != &disk_type)
continue;
@@ -671,7 +671,7 @@ dev_t blk_lookup_devt(const char *name, int part)
break;
}
}
- mutex_unlock(&block_class_lock);
+ up(&block_class.sem);

return devt;
}
--
1.5.4.5


2008-07-14 11:42:58

by Cornelia Huck

[permalink] [raw]
Subject: Re: [PATCH] block: fix block_class iteration locking

On Mon, 14 Jul 2008 15:06:08 +0900,
Tejun Heo <[email protected]> wrote:

> genhd.c used block_class_lock when it wants to iterate over
> block_class.devices list. This is incorrect as block_class_lock has
> nothing to do with synchronization around block_class.devices list, so
> there's a window, albeit small, where the list can change while it's
> being iterated over. Fix it by using block_class.sem instead.
>
> Signed-off-by: Tejun Heo <[email protected]>

Greg has some patches sitting in his tree that convert those functions
to use class_{for_each,find}_device() instead - and that looks like the
clean solution, especially since the class implementation details will
be moved into a private structure. One worry though...


> @@ -285,7 +285,7 @@ static void *part_start(struct seq_file *part, loff_t *pos)
> loff_t k = *pos;
> struct device *dev;
>
> - mutex_lock(&block_class_lock);
> + down(&block_class.sem);
> list_for_each_entry(dev, &block_class.devices, node) {
> if (dev->type != &disk_type)
> continue;
> @@ -311,7 +311,7 @@ static void *part_next(struct seq_file *part, void *v, loff_t *pos)
>
> static void part_stop(struct seq_file *part, void *v)
> {
> - mutex_unlock(&block_class_lock);
> + up(&block_class.sem);
> }
>
> static int show_partition(struct seq_file *part, void *v)
> @@ -533,7 +533,7 @@ static void *diskstats_start(struct seq_file *part, loff_t *pos)
> loff_t k = *pos;
> struct device *dev;
>
> - mutex_lock(&block_class_lock);
> + down(&block_class.sem);
> list_for_each_entry(dev, &block_class.devices, node) {
> if (dev->type != &disk_type)
> continue;
> @@ -560,7 +560,7 @@ static void *diskstats_next(struct seq_file *part, void *v, loff_t *pos)
>
> static void diskstats_stop(struct seq_file *part, void *v)
> {
> - mutex_unlock(&block_class_lock);
> + up(&block_class.sem);
> }
>
> static int diskstats_show(struct seq_file *s, void *v)

With your patch, you protect against adding/removing devices to/from
the class between _start and _stop. This wasn't done previously, and
won't be done with Greg's patches (which leaves in the
locking/unlocking of block_class_lock). Not sure if I'm missing
something here...

2008-07-19 10:24:26

by Tejun Heo

[permalink] [raw]
Subject: Re: [PATCH] block: fix block_class iteration locking

Cornelia Huck wrote:
> Greg has some patches sitting in his tree that convert those functions
> to use class_{for_each,find}_device() instead - and that looks like the
> clean solution, especially since the class implementation details will
> be moved into a private structure. One worry though...

Yeah, that sounds nice.

> With your patch, you protect against adding/removing devices to/from
> the class between _start and _stop. This wasn't done previously, and
> won't be done with Greg's patches (which leaves in the
> locking/unlocking of block_class_lock). Not sure if I'm missing
> something here...

That's mostly the point of this patch. It wasn't protected properly
before. It would be best if there's a safe iterator (maybe use klist?).

Thanks.

--
tejun

2008-07-21 17:55:25

by Cornelia Huck

[permalink] [raw]
Subject: Re: [PATCH] block: fix block_class iteration locking

On Mon, 14 Jul 2008 20:50:57 +0900,
Tejun Heo <[email protected]> wrote:

> > With your patch, you protect against adding/removing devices to/from
> > the class between _start and _stop. This wasn't done previously, and
> > won't be done with Greg's patches (which leaves in the
> > locking/unlocking of block_class_lock). Not sure if I'm missing
> > something here...
>
> That's mostly the point of this patch. It wasn't protected properly
> before. It would be best if there's a safe iterator (maybe use klist?).

Hm, I don't see how a klist would help here since it still allows to
add/remove devices during walking the file.

What we need is more like a "lock/unlock the device list" operation and
a lockless iterator - that would give the same semantics as your patch.