From: Johannes Weiner <hannes@cmpxchg.org>
To: Guennadi Liakhovetski <lg@denx.de>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] bitmap: fix bitmap_find_free_region()
Date: Sat, 20 Dec 2008 12:34:20 +0100 [thread overview]
Message-ID: <20081220113419.GB2581@cmpxchg.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0812200005430.9649@axis700.grange>
On Sat, Dec 20, 2008 at 12:19:46AM +0100, Guennadi Liakhovetski wrote:
> Well, I don't quite understand. Doesn't bitmap_find_free_region() _have_
> to return an error if the request cannot be satisfied? Isn't it what it
> does if after scanning the bitmap no suitable free region is found?
There is a difference here. In the case it already checks, the
request was sane but couldn't be satisfied due to prior requests.
This is an expected situation on the bitmap allocator level.
The check you want to add is for fixing up the caller.
This API is especially clear on that separation because the caller
even has to pass in the size of the bitmap, so itself should ensure
that the combination of bitmap size and request size is sane.
> What's the difference? Why don't we want to fix _that_ function? It
> also has other users - currently I see 3 of them in the kernel:
>
> mm/vmalloc.c
This has its own sanity checks. It's a bug for the user of vb_alloc()
to pass a size that is larger than VMAP_MAX_ALLOC pages and the bitmap
has a minimum of VMAP_MAX_ALLOC * 2 bits.
> arch/powerpc/sysdev/msi_bitmap.c (5 occurrences)
The users allocating irqs from there seem all sane and doing only low
orders. Not yet quite through, though.
> arch/sh/kernel/cpu/sh4/sq.c
Not yet looked into it.
> Yes, I understand that the caller _can_ verify whether the requested
> region at all fits into the bitmap, but from the PoV of offering a
> consistent API this seems strange.
Not really. The user that is supposed to use the bitmap also sets it
up. If the requests are bogus wrt the original parameters it's the
users fault, not that of the API.
> Thanks
> Guennadi
Hannes
prev parent reply other threads:[~2008-12-20 11:35 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
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 [this message]
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=20081220113419.GB2581@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=lg@denx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox