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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87abi0semc.fsf@saeurebad.de>
Date:	Thu, 05 Jun 2008 06:13:47 +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:

> Hi.
>
>> > 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?
>
> Yes.

Okay.

>> 
>> 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.
>
> Ok. I'll try it.

Thanks!

>> > 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?
>
> Last_sidx is ok. But, last_offset seems to be used to manage some
> allocated smaller chunks than one page. I'm not sure last_eidx is ok.

Sorry, my fault.

How about last_offset -> last_end_off to reflect that it is the offset
of the last allocations end?

And last_succes -> hint_idx to reflect that it is an index we start
searching from but it is not strict and we fall back if we find nothing
starting from there.  Also free_bootmem* sets it as a hint from where we
could start searching.

I also would set last_success/hint_idx to the _end_ of the successful
allocation (instead of the beginning of it) in alloc_bootmem_core
because we do not want to search for a new free block from the beginning
of the last allocation but rather right after it.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ