linux-kernel - Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs

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]

Date:	Thu, 12 Dec 2013 21:53:46 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Dave Young <dyoung@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
	x86@...nel.org, mjg59@...f.ucam.org, hpa@...or.com,
	James.Bottomley@...senPartnership.com, vgoyal@...hat.com,
	ebiederm@...ssion.com, horms@...ge.net.au,
	kexec@...ts.infradead.org, greg@...ah.com, matt@...sole-pimps.org,
	toshi.kani@...com
Subject: Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs

On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> Sorry that I forgot to explain this in changelog, should ask you before.
> 
> I did try moving it to efisubsys_init but it need add extern declaration

So what? Add it.

> for efi_runtime_map_init. Since link order will ensure it being called after
> efisubsys_init I think it's fine with this static function.

This is actually exactly the reason why it shouldn't be another
subsys_initcall() if it can be helped. People would need to go have a
look at drivers/firmware/efi/Makefile to realize that the link order is
ok.

And, this is prone to future breakage if people go and move code around
and thereby change the link order.

Please call efi_runtime_map_init from efisubsys_init.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/