linux-kernel - Re: [PATCH v4 06/12] 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]

Message-ID: <20131207133048.GA4183@pd.tnic>
Date:	Sat, 7 Dec 2013 14:30:48 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Dave Young <dyoung@...hat.com>
Cc:	mjg59@...f.ucam.org, linux-efi@...r.kernel.org,
	toshi kani <toshi.kani@...com>, matt@...sole-pimps.org,
	greg@...ah.com, x86@...nel.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	horms@...ge.net.au, ebiederm@...ssion.com, hpa@...or.com,
	vgoyal@...hat.com
Subject: Re: [PATCH v4 06/12] efi: export efi runtime memory mapping to sysfs

On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote:
> Hi, all
> 
> Update my status:
> 
> I have finished most of thecode related changes including the krealloc
> fixes (both for original code and my new code). And I'm slowly
> moving the kexec related stuff to efi_kexec.c, this involves
> some other cleanups, such as:
> efi_systab_init:
>  -> move 64bit code to efi_64.c, move 32bit code to efi_32.c
> 
> efi_setup global variable is changing to physical address, ioremapping
> it when necessary instead of directly using the virt addr because
> previously the virt addr will be freed until entering virtual mode,
> it's possible a leak in case something is wrong in the middle also it
> occupies the ioremap slot a little bit long.
> 
> There's also other problems, so I still need a few days probably
> a week to carefully restructure the code.

Those are all lofty goals but beware that trying to solve it all at
once can be very painful and can cause unnecessary work for both coders
and reviewers. Especially if the patchset grows out of proportion which
makes it much harder to review and deal with.

So, from my experience and if I were you, I'd try to address the most
important issue I'm trying to fix, have 10ish nice clean patches and put
the rest on the TODO list. This is much easier to deal with for everyone
involved than trying to solve it all at once.

Besides, if you solve it all at once, what are you going to work on
afterwards? :-)

HTH.

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