Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1628229 > unrolled thread

Re: [PATCH] dm-region-hash: fix strange usage of mempool_alloc.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] dm-region-hash: fix strange usage of mempool_alloc. Mikulas Patocka <mpatocka@redhat.com> - 2017-04-21 15:10 +0200
    Re: [dm-devel] [PATCH] dm-region-hash: fix strange usage of    mempool_alloc. NeilBrown <neilb@suse.com> - 2017-04-24 03:50 +0200

#1628229 — Re: [PATCH] dm-region-hash: fix strange usage of mempool_alloc.

On Mon, 10 Apr 2017, NeilBrown wrote:

> mempool_alloc() should only be called with GFP_ATOMIC when
> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
> says that it is safe to wait indefinitely.  So this code is
> inconsistent.
> 
> Clearly it is OK to wait indefinitely in this code, and
> mempool_alloc() is able to do that.  So just use
> mempool_alloc, and allow it to sleep.  If no memory is
> available it will wait for something to be returned to the
> pool, and will retry a normal allocation regularly.

The region hash code is buggy anyway, because it may allocate more entries 
than the size of the pool and not give them back.

That kmalloc was introduced in the commit c06aad854 to work around a 
deadlock due to incorrect mempool usage.

Your patch slightly increases the probability of the deadlock because 
mempool_alloc does all allocations with __GFP_NOMEMALLOC, so it uses 
higher limit than kmalloc(GFP_NOIO).

Mikulas

> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
>  drivers/md/dm-region-hash.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c
> index 85c32b22a420..a6279f5d779e 100644
> --- a/drivers/md/dm-region-hash.c
> +++ b/drivers/md/dm-region-hash.c
> @@ -287,9 +287,7 @@ static struct dm_region *__rh_alloc(struct dm_region_hash *rh, region_t region)
>  {
>  	struct dm_region *reg, *nreg;
>  
> -	nreg = mempool_alloc(rh->region_pool, GFP_ATOMIC);
> -	if (unlikely(!nreg))
> -		nreg = kmalloc(sizeof(*nreg), GFP_NOIO | __GFP_NOFAIL);
> +	nreg = mempool_alloc(rh->region_pool, GFP_NOIO);
>  
>  	nreg->state = rh->log->type->in_sync(rh->log, region, 1) ?
>  		      DM_RH_CLEAN : DM_RH_NOSYNC;
> -- 
> 2.12.2
> 
> 

[toc] | [next] | [standalone]

#1629121 — Re: [dm-devel] [PATCH] dm-region-hash: fix strange usage of mempool_alloc.

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 21 2017, Mikulas Patocka wrote:

> On Mon, 10 Apr 2017, NeilBrown wrote:
>
>> mempool_alloc() should only be called with GFP_ATOMIC when
>> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
>> says that it is safe to wait indefinitely.  So this code is
>> inconsistent.
>> 
>> Clearly it is OK to wait indefinitely in this code, and
>> mempool_alloc() is able to do that.  So just use
>> mempool_alloc, and allow it to sleep.  If no memory is
>> available it will wait for something to be returned to the
>> pool, and will retry a normal allocation regularly.
>
> The region hash code is buggy anyway, because it may allocate more entries 
> than the size of the pool and not give them back.
>
> That kmalloc was introduced in the commit c06aad854 to work around a 
> deadlock due to incorrect mempool usage.
>
> Your patch slightly increases the probability of the deadlock because 
> mempool_alloc does all allocations with __GFP_NOMEMALLOC, so it uses 
> higher limit than kmalloc(GFP_NOIO).
>

Thanks for the review.

I had a look at how the allocation 'dm_region' objects are used,
and it would take a bit of work to make it really safe.
My guess is __rh_find() should be allowed to fail, and the various
callers need to handle failure.
For example, dm_rh_inc_pending() would be given a second bio_list,
and would move any bios for which rh_inc() fails, onto that list.
Then do_writes() would merge that list back into ms->writes.
That way do_mirror() would not block indefinitely and forward progress
could be assured ... maybe.
It would take more work than I'm able to give at the moment, so
I'm happy to just drop this patch.

Thanks,
NeilBrown

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web