Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Device-mapper Development (http://www.linux-archive.org/device-mapper-development/)
-   -   remove spurious decrement of write_lock_pending in the case of a recycled block. (http://www.linux-archive.org/device-mapper-development/560200-remove-spurious-decrement-write_lock_pending-case-recycled-block.html)

Mikulas Patocka 08-03-2011 02:50 PM

remove spurious decrement of write_lock_pending in the case of a recycled block.
 
I think this is not correct.

The problem here is that the block may have been recycled and the newly
created block may have the same block number as the old block.

If b->where != block, we know that the block was recycled.
If b->where == block, the block may have been recycled or not and we
don't know.


I think the correct solution could be: make write_lock_pending a boolean
variable, not a counter.

Set write_lock_pending inside __wait_block when we are about to wait (the
block may have been recycled each time we waited, so we need to set it
each time we are going to wait)
Clear write_lock_pending when __wait_unlocked exits.

If we make it a boolean variable, double clearing makes no harm.

Mikulas

On Tue, 2 Aug 2011, Joe Thornber wrote:

> ---
> drivers/md/persistent-data/dm-block-manager.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/md/persistent-data/dm-block-manager.c b/drivers/md/persistent-data/dm-block-manager.c
> index b68be88..d27ab6e 100644
> --- a/drivers/md/persistent-data/dm-block-manager.c
> +++ b/drivers/md/persistent-data/dm-block-manager.c
> @@ -756,9 +756,15 @@ retry:
>
> b->write_lock_pending++;
> __wait_unlocked(b, &flags);
> - b->write_lock_pending--;
> if (b->where != block)
> + /*
> + * Recycled blocks have their
> + * write_lock_pending count reset
> + * to zero, so no need to undo the
> + * above increment.
> + */
> goto retry;
> + b->write_lock_pending--;
> }
> break;
> }
> --
> 1.7.4.1
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Joe Thornber 08-04-2011 09:06 AM

remove spurious decrement of write_lock_pending in the case of a recycled block.
 
On Wed, Aug 03, 2011 at 10:50:33AM -0400, Mikulas Patocka wrote:
> I think this is not correct.

I had a similar thought last night, however my concern was the
previous 'read' patch that you've acked. I'll go back and look at
these today.

- Joe

>
> The problem here is that the block may have been recycled and the newly
> created block may have the same block number as the old block.
>
> If b->where != block, we know that the block was recycled.
> If b->where == block, the block may have been recycled or not and we
> don't know.
>
>
> I think the correct solution could be: make write_lock_pending a boolean
> variable, not a counter.
>
> Set write_lock_pending inside __wait_block when we are about to wait (the
> block may have been recycled each time we waited, so we need to set it
> each time we are going to wait)
> Clear write_lock_pending when __wait_unlocked exits.
>
> If we make it a boolean variable, double clearing makes no harm.
>
> Mikulas
>
> On Tue, 2 Aug 2011, Joe Thornber wrote:
>
> > ---
> > drivers/md/persistent-data/dm-block-manager.c | 8 +++++++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/md/persistent-data/dm-block-manager.c b/drivers/md/persistent-data/dm-block-manager.c
> > index b68be88..d27ab6e 100644
> > --- a/drivers/md/persistent-data/dm-block-manager.c
> > +++ b/drivers/md/persistent-data/dm-block-manager.c
> > @@ -756,9 +756,15 @@ retry:
> >
> > b->write_lock_pending++;
> > __wait_unlocked(b, &flags);
> > - b->write_lock_pending--;
> > if (b->where != block)
> > + /*
> > + * Recycled blocks have their
> > + * write_lock_pending count reset
> > + * to zero, so no need to undo the
> > + * above increment.
> > + */
> > goto retry;
> > + b->write_lock_pending--;
> > }
> > break;
> > }
> > --
> > 1.7.4.1
> >

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


All times are GMT. The time now is 06:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.