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
| ||
|
Date: Tue, 30 Mar 2010 15:42:26 -0700 From: Yinghai Lu <yinghai@...nel.org> To: Benjamin Herrenschmidt <benh@...nel.crashing.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 03/30/2010 02:30 PM, Benjamin Herrenschmidt wrote: > 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. already done. last night, Michael point that out. > > 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. never mind. > >>> 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. make 32 bit x86 can work from high to low now. > >> 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. ok, I will replace that later after it get stable. but at first will expose the find_lmb_area. will send out -v11, please check that version. Thanks Yinghai -- 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