linux-kernel - Re: [PATCH -mm 11/14] bootmem: respect goal more likely

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: <87fxrtaqwl.fsf@saeurebad.de>
Date:	Wed, 04 Jun 2008 22:25:46 +0200
From:	Johannes Weiner <hannes@...urebad.de>
To:	Yasunori Goto <y-goto@...fujitsu.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm 11/14] bootmem: respect goal more likely

Hi,

Yasunori Goto <y-goto@...fujitsu.com> writes:

>> This check is backwards and probably made your boot fail.
>> 
>> >> +		if (limit && limit < bdata->node_boot_start)
>> >> +			continue;
>> 
>> Changed this to break, because we don't need to search any further if
>> the current node already starts at/above the limit (remember, we walk a
>> list sorted by ->node_boot_start here).
>> 
>> I also made the checks more intuitively understandable.
>> 
>> Could you try the following fix on top of this patch?
>
> I tried it. However, my box cannot boot yet.
>
>>>  	max -= PFN_DOWN(bdata->node_boot_start);
>>>  	start -= PFN_DOWN(bdata->node_boot_start);
>>> +	fallback -= PFN_DOWN(bdata->node_boot_start);
>
> I thought this fallback was wrong at first, 
> because fallback may point 0 at this time,
> it doesn't point start_pfn of this node.
>
> But even if here is commented out, kernel can't boot up yet.

Oh, that should go out, sorry.  It is a left-over from another way to do
it.  Should pay more attention :/

> I'd like to straggle more, but may be need more time,
> because, IA64 doesn't have early_printk, and console is not enable
> at here.....

Hm, just to make sure: this is the patch that breaks booting, right?  If
you apply all patches in the series before this one, the machine boots
fine?

Could you boot a working image with bootmem_debug in the command line?
Perhaps seeing the usual bootmem usage on this box gives a hint what is
broken.

> P.S.
> I was very confused by local variable namimng in alloc_bootmem_core. 
> I suppose start, max, and end, should be named like
> sidx, eidx, and midx. They are not pfn, but index of bitmap.

Okay, I will make them more clear.

> However, new_start and new_end should be named as new_start_offset and
> new_end_offset. They are not index, but offset from start address of
> the node.

Yes, that too.  I would also rename last_offset to last_eidx and
last_success to last_sidx.  What do you think?

	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/