All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Guennadi Liakhovetski <lg@denx.de>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] bitmap: fix bitmap_find_free_region()
Date: Fri, 19 Dec 2008 15:47:26 +0100	[thread overview]
Message-ID: <20081219144726.GA1991@cmpxchg.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0812191413520.4536@axis700.grange>

On Fri, Dec 19, 2008 at 02:18:22PM +0100, Guennadi Liakhovetski wrote:
> On Fri, 19 Dec 2008, Johannes Weiner wrote:
> 
> > On Fri, Dec 19, 2008 at 12:26:41PM +0100, Guennadi Liakhovetski wrote:
> > > Currently bitmap_find_free_region() assumes, that the requested region 
> > > size is smaller than the entire bitmap. If this is not the case it fails 
> > > to detect it and returns success, while pointing at a position outside of 
> > > the region.
> > > 
> > > Signed-off-by: Guennadi Liakhovetski <lg@denx.de>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > ---
> > > It is hard to believe, that this is a bug, last time this code was touched 
> > > in 2006... Or should the caller guarantee, that the requested region is 
> > > not larger than the bitmap? Then dma_alloc_from_coherent() is buggy, which 
> > > is where I hit this bug. But it seems to me bitmap_find_free_region() 
> > > should be fixed.
> > > 
> > > diff --git a/lib/bitmap.c b/lib/bitmap.c
> > > index 1338469..079c5e3 100644
> > > --- a/lib/bitmap.c
> > > +++ b/lib/bitmap.c
> > > @@ -950,6 +950,9 @@ int bitmap_find_free_region(unsigned long *bitmap, int bits, int order)
> > >  {
> > >  	int pos;		/* scans bitmap by regions of size order */
> > >  
> > > +	if (bits < 1 << order)
> > > +		return -ENOMEM;
> > 
> > I think this is an error on the callsite, so a WARN_ON() might be good
> > to spot these.  I would be interested in the callpath that triggered
> > this bug for you.
> 
> As I said above it's called from dma_alloc_from_coherent() from 
> dma_alloc_coherent().

Sure, but someone must have done dma_declare_coherent_memory() before
with a size smaller than it later passed to dma_alloc_coherent(), no?

I think we should add the check, WARN if it's true and return an
appropriate error number.  It will be handled gracefully then and we
still know which callsite screwed up.

	Hannes

  parent reply	other threads:[~2008-12-19 14:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-19 11:26 [PATCH] bitmap: fix bitmap_find_free_region() Guennadi Liakhovetski
2008-12-19 13:02 ` Johannes Weiner
2008-12-19 13:18   ` Guennadi Liakhovetski
2008-12-19 13:59     ` Pekka Enberg
2008-12-19 14:47     ` Johannes Weiner [this message]
2008-12-19 15:09       ` Guennadi Liakhovetski
2008-12-19 22:45         ` Johannes Weiner
2008-12-19 23:19           ` Guennadi Liakhovetski
2008-12-20 11:34             ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081219144726.GA1991@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=lg@denx.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.