linux-kernel - Re: [PATCH 0/8] x86, acpi: Move acpi_initrd

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: <1377202292.10300.693.camel@misato.fc.hp.com>
Date:	Thu, 22 Aug 2013 14:11:32 -0600
From:	Toshi Kani <toshi.kani@...com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Zhang Yanfei <zhangyanfei.yes@...il.com>,
	Tang Chen <tangchen@...fujitsu.com>, konrad.wilk@...cle.com,
	robert.moore@...el.com, lv.zheng@...el.com, rjw@...k.pl,
	lenb@...nel.org, tglx@...utronix.de, mingo@...e.hu, hpa@...or.com,
	akpm@...ux-foundation.org, trenn@...e.de, yinghai@...nel.org,
	jiang.liu@...wei.com, wency@...fujitsu.com, laijs@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, izumi.taku@...fujitsu.com,
	mgorman@...e.de, minchan@...nel.org, mina86@...a86.com,
	gong.chen@...ux.intel.com, vasilis.liaskovitis@...fitbricks.com,
	lwoodman@...hat.com, riel@...hat.com, jweiner@...hat.com,
	prarit@...hat.com, zhangyanfei@...fujitsu.com,
	yanghy@...fujitsu.com, x86@...nel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.

Hello Tejun,

On Thu, 2013-08-22 at 14:31 -0400, Tejun Heo wrote:
> On Thu, Aug 22, 2013 at 09:52:09AM -0600, Toshi Kani wrote:
> > I understand that you are concerned about stability of the ACPI stuff,
> > which I think is a valid point, but most of (if not all) of the
> > ACPI-related issues come from ACPI namespace/methods, which is a very
> > different thing.  Please do not mix up those two.  The ACPI
> 
> I have no objection to implementing self-conftained earlyprintk
> support.  If that's all you want to do, please go ahead but do not
> pull in initrd override or ACPICA into it.

If you are referring ACPICA as the AML interpreter, right, we do not
move it up as I explained before.  We are trying to move up the ACPI
table init code (which is part of ACPICA, but has nothing to do with
AML.)

Note that ia64 also uses ACPI, and calls acpi_table_init() in
setup_arch() before initializing the bootmap in find_memory().

> > namespace/methods stuff remains the same and continues to be initialized
> > at very late in the boot sequence.
> > 
> > What's making the patchset complicated is acpi_initrd_override(), which
> > is intended for developers and allows overwriting ACPI bits at their own
> > risk.  This feature won't be used by regular users. 
> 
> Yeah, please forget about that in earlyboot.  It doesn't make any
> sense to fiddle with initrd that early during boot.

I think the reason why Tang is working on this stuff again is that his
previous change (which was once accepted) had broken initrd.  So, he'd
have to support it this time...

> > If you are referring the issue of kernel image location, it is a
> > limitation in the current implementation, not a technical limitation.  I
> > know other OS that supports movable memory and puts the kernel image
> > into a movable memory with SRAT by changing the bootloader.
> 
> I'm not saying that problem shouldn't be solved.  I'm saying what you
> guys are pushing doesn't help solving it at all.  It's too late in the
> boot process.  It needs to be handled either by bootloader or earlier
> kernel kexecing the actual one and super-early SRAT doens't help at
> all in either case, so what's the point of pulling ACPI code in when
> it doesn't contribute to solving the problem properly?

It's too late for the kernel image itself, but it prevents allocating
kernel memory from movable ranges after that.  I'd say it solves a half
of the issue this time.

> > Also, how do you support local page tables without pursing SRAT early?
> 
> Does it even matter with huge mappings?  It's gonna be contained in a
> single page anyway, right?

Are the huge mappings always used?  We cannot force user programs to use
huge pages, can we?

> > Initializing page tables on large systems may take a long time, and I do
> > think that earlyprink needs to be available before that point.
> 
> Yeah, sure, implement it in *minimal* way which doesn't affect
> anything if not explicitly enabled by kernel param like other
> earlyprintks.  It doens't make any sense to add dependency to acpi
> from early boot for that.

It makes sense because it needs to obtain the config info from ACPI
tables.

As for the maintainability, I am far more concerned with your suggestion
of having a separate page table init code when SRAT is used.  This kind
of divergence is a recipe of breakage.

Thanks,
-Toshi

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