linux-kernel - Re: [PATCH] x86: ioremap mptable -v2

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]

Date:	Mon, 2 Mar 2009 21:57:27 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Kevin O'Connor <kevin@...onnor.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Stefan Reinauer <stepan@...esystems.de>,
	linux-kernel@...r.kernel.org, coreboot@...eboot.org
Subject: Re: [PATCH] x86: ioremap mptable -v2


* Yinghai Lu <yinghai@...nel.org> wrote:

> Ingo Molnar wrote:
> > * Yinghai Lu <yinghai@...nel.org> wrote:
> > 
> >> V3: according to Ingo, seperate get_mpc_size()
> > 
> > No, that was not my suggestion. My suggestion was to separate 
> > this whole 'else if' branch:
> > 
> >>  	} else if (mpf->physptr) {
> >> +		struct mpc_table *mpc;
> >> +		unsigned long size;
> >>  
> >> +		size = get_mpc_size(mpf->physptr);
> >> +		mpc = early_ioremap(mpf->physptr, size);
> >>  		/*
> >>  		 * Read the physical hardware table.  Anything here will
> >>  		 * override the defaults.
> >>  		 */
> >> -		if (!smp_read_mpc(phys_to_virt(mpf->physptr), early)) {
> >> +		if (!smp_read_mpc(mpc, early)) {
> >>  #ifdef CONFIG_X86_LOCAL_APIC
> >>  			smp_found_config = 0;
> >>  #endif
> > 
> > ... into a helper function - if that improves the code.
> oh, i missed it
> > Your patch does early_ioremap, iounmap then ioremap and iounmap - 
> > quite pointlessly.
> try to get exact mpc size.
> > 
> > You should resist cleanup suggestions that make the code worse, 
> > even if it comes from a maintainer :-)
> 
> we could do that later. to make __get_smp_config smaller and readable.

No, do it in two separate patches please: _first_ do the whole 
cleanup of these functions - on the assumption and expectation 
that it wont break anything. Then add the early_ioremap() change 
in a second patch - on top of the cleanup patch.

If we do a cleanup _after_ a functional change then we make the 
feature patch harder to revert and harder to fix as well. We'd 
always have to 'see through' the cleanup patch when considering 
breakages caused by the functional patch.

Like i suggested in my first reply ;-)

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