lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20081220113419.GB2581@cmpxchg.org>
Date:	Sat, 20 Dec 2008 12:34:20 +0100
From:	Johannes Weiner <hannes@...xchg.org>
To:	Guennadi Liakhovetski <lg@...x.de>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] bitmap: fix bitmap_find_free_region()

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ