linux-kernel - Re: [PATCH 07/31] lmb: Add reserve_lmb/free

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1269984635.7101.59.camel@pasglop>
Date:	Wed, 31 Mar 2010 08:30:35 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	michael@...erman.id.au, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 07/31] lmb: Add reserve_lmb/free_lmb

On Mon, 2010-03-29 at 23:12 -0700, Yinghai Lu wrote:
> 
> 1. you want to reserve rangeA
> 2. before that will check if region array is big enough,
> 3. if region is not big enough, will call lmb_alloc to get new range.
>    lmb_alloc could return rangB that is overlapped with rangeA
> 4. current lmb_alloc only honor limit, and doesn't honor low limit.

I see. This is a direct consequence of you wanting to use find/reserve
instead of alloc tho :-)

This is also easily fixed. Instead of doing the resize "on demand" like
I originally proposed, do it at the end of reserve/alloc. If the number
of free entries is down to 1 or 0, then alloc a new chunk.

Of course, all of that requires that reservations done from FW to take
memory out because it must not be accessed need to be all done before
the first grow of the array, and so the static array must be sized
accordingly. We may want to catch these things too. We don't want to
warn on multiple overlapping lmb_reserve() tho on powerpc...

> another usage is: for temporary buffer, like range array for
> subtraction. we don't need to do free later.

Sorry, doesn't parse.

> > Ie. It should all be one single find/allocation function.
> > 
> > In fact, you want to split lmb_find from lmb_reserve, then just make
> > lmb_alloc use the above, I don't want 2 implementations of the same
> > thing (maybe call it __lmb_find to expose the fact that it's a low
> level
> > function to avoid for normal use).
> 
> that is some difference between them, and lmb_alloc doesn't honor low
> limit.

If you want a low and a high limit, then add the low limit to
lmb_alloc_base(), it's easy to fix all callers, there aren't many, and
make not one but two defaults for lmb_alloc(), one for the low limit and
one for the high limit. Problem solved.

> we can provide
> lmb_find_area
> lmb_reserve_area
> lmb_free_area
> 
> and use lmb_find_area + lmb_reserve_area to get one lmb_alloc()

I still don't understand why you insist on using find + reserve instead
of alloc in x86 land. Can you give me a proper explanation as to why
that is needed since it seems to be causing problems, and so far and I
don't see what it solves.

> x86 sometime is using find_lmb_area to find big area, and use those
> area and later reserve actually used area.

That's very wrong. If you use something, alloc/reserve it. You can
always free it later.

> you could use lmb_alloc, and later lmb_free not used. that is equal to
> lmb_find + lmb_reserve + lmb_free ...

Sure, then just do alloc + later free.

Cheers,
Ben.

--
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/