linux-kernel - Re: [PATCH 1/2 v2] x86: add max

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: <4FDA42CC.2090807@landley.net>
Date:	Thu, 14 Jun 2012 15:00:12 -0500
From:	Rob Landley <rob@...dley.net>
To:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Wen Congyang <wency@...fujitsu.com>, tglx@...utronix.de,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2 v2] x86: add max_addr boot option

On 06/13/2012 09:06 PM, Kamezawa Hiroyuki wrote:
>> You're adding an option because you consider it less confusing for your
>> end users who are digging into kernel parameters, but you will set this
>> new option for your users because they haven't got the information to
>> set it themselves?
>>
> 
> My users don't need to know about hardware settings and the meaning of
> kernel params. They'll just do as we ask to do.

So you're adding a new feature that only you will use, because the
existing way of doing it confuses... you.

>> So you're saying there are already two ways to do this, but you want to
>> add a third to be less confusing for end users who are modifying the
>> linux kernel boot parameters by hand using information only you can
>> supply to them?
>>
>> I'm confused...
>>
> 
> I'm just saying current mem= implemenation seems buggy because spec. and
> impl. doesn't match. So, we're just afraid that someone other than us
> will fix it and break our assumption how mem= works. It's dangerous to
> build a production on a feature where spec. and impl. doesn't match.
> So, we proposed to add max_addr= option for avoiding that situation.

So fix the spec, or fix the implementation. Don't add a random new
duplicate way to do the same thing because you're afraid that open
source code might change, but somehyow the new code you propose to add
won't (presumably due to being so profoundly uninteresting to the rest
of the world that nobody will notice it's there).

Sigh.  On arm you can go "mem=size@...rt", which can be repeated. I.E.
you can, on the kernel command line, tell it where all the chunks of
physical memory it should use actually live. Letting x86 do that might
be nice. Adding a clipping option to the normal memory probing, so
memory probing has to fail in a certain specific way in order for this
to even apply? Not so much...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.
--
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/