[PATCH] block: fix block_class iteration locking - Kernel

This is a discussion on [PATCH] block: fix block_class iteration locking - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: [PATCH] block: fix block_class iteration locking

  1. [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
    ---
    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

    --
    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/

  2. Re: [PATCH] block: fix block_class iteration locking

    On Mon, 14 Jul 2008 15:06:08 +0900,
    Tejun Heo 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


    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...
    --
    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/

  3. 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
    --
    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/

  4. Re: [PATCH] block: fix block_class iteration locking

    On Mon, 14 Jul 2008 20:50:57 +0900,
    Tejun Heo 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.
    --
    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/

+ Reply to Thread