linux-kernel - Re: [PATCH 07/16] x86: Remove custom apic->cpu_to_logical

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: <alpine.LFD.2.00.1012101215550.2653@localhost6.localdomain6>
Date:	Fri, 10 Dec 2010 12:18:42 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Tejun Heo <tj@...nel.org>
cc:	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, eric.dumazet@...il.com, yinghai@...nel.org,
	brgerst@...il.com, gorcunov@...il.com, penberg@...nel.org
Subject: Re: [PATCH 07/16] x86: Remove custom apic->cpu_to_logical_apicid()
 implementations

On Fri, 10 Dec 2010, Tejun Heo wrote:

> Hello, Thomas.
> 
> On 12/09/2010 10:28 PM, Thomas Gleixner wrote:
> >> After the previous patch, apic->cpu_to_logical_apicid() is no longer
> >> used.  The callback will be repurposed.  Remove all the custom
> > 
> > That's a very bad idea. You remove the callbacks from the esoteric
> > platforms, but you keep the other implementation in the tree.
> >
> > It's not longer used now, so remove all incarnations and get rid of
> > all those useless = NULL initializations at the same time. Then
> > implement a new callback with a different name.
> 
> Yeah, that would be cleaner.  I wasn't very sure about clearing
> unimplemented apic ops.  Currently the rule seems to be always setting
> them to NULL and I didn't want to re-do that with a new callback.
> 
> > It's slightly more work and code churn, but it makes the change
> > entirely clear. It'd be also nice to annotate in the function name
> > that this is 32bit only or even make it 32bit dependent if it's not
> > too much ifdeffery
> 
> Yeah, sure, if the silly NULL assignments aren't necessary, I don't
> think it would be much more churn anyway.

I don't see much point in them, as static struct initializing fills
all unset members with zero anyway. And we have no way to check with
the compiler that every instance has really initialized all members,
which would make sense to ensure that people look at all instances
when they add new members.

Thanks,

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