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:	Mon, 27 Sep 2010 17:07:04 -0700
From:	Guenter Roeck <guenter.roeck@...csson.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Pekka Enberg <penberg@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	Fenghua Yu <fenghua.yu@...el.com>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [PATCH v2] hwmon (coretemp): Fix build breakage if SMP is
 undefined

On Mon, Sep 27, 2010 at 07:44:01PM -0400, Linus Torvalds wrote:
> On Mon, Sep 27, 2010 at 4:27 PM, Guenter Roeck
> <guenter.roeck@...csson.com> wrote:
> > On Mon, Sep 27, 2010 at 09:02:57AM -0400, Pekka Enberg wrote:
> >> On Mon, Sep 27, 2010 at 3:59 PM, Ingo Molnar <mingo@...e.hu> wrote:
> >> >
> >> > * Guenter Roeck <guenter.roeck@...csson.com> wrote:
> >> >
> >> >> +#ifdef CONFIG_SMP
> >> >> +#endif
> >> >> +#ifdef CONFIG_SMP
> >> >> +#endif
> >> >
> >> > Hm, this tickles my uglo-meter. Is there no cleaner way, preferably one
> >> > that doesnt involve preprocessor directives?
> >>
> >> Implement cpu_sibling_mask() on UP so that the loop goes away?
> >
> > So what is the take ? Looks like Linus won't accept my patch without someone
> > else signing off on it. If the uglo-meter prevents it from being accepted,
> > I'll be happy to submit the SMP cleanup patch instead. As I mentioned
> > before, I would prefer that to go into -next.
> 
> I'd _much_ rather see cpu_sibling_mask() on UP, and just have the loop go away.
> 
> But that would be a generic change. Something like the (UNTESTED!)

Which is why I didn't do it...

> attached. It returns a NULL, since it would always be a bug to
> actually _use_ the (nonexistent) mask. And that's fine for things like
> for_each_cpu() that will then happily ignore the mask.
> 
> Ingo, does this make those randconfig things work? I think it's
> prettier than the horrible "sprinkle #ifdef CONFIG_SMP around in
> random places".
> 
>                         Linus

>  include/linux/smp.h |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/smp.h b/include/linux/smp.h
> index cfa2d20..ad48077 100644
> --- a/include/linux/smp.h
> +++ b/include/linux/smp.h
> @@ -149,6 +149,8 @@ smp_call_function_any(const struct cpumask *mask, void (*func)(void *info),
>  	return smp_call_function_single(0, func, info, wait);
>  }
>  
> +static inline const struct cpumask *cpu_sibling_mask(int cpu) { return NULL; }
> +
>  #endif /* !SMP */
>  
That works. Every other use of cpu_sibling_mask() is either in smp code
or surrounded with #ifdef CONFIG_SMP.

Ok, I'll submit another version of the patch with the generic change after 
some more testing.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ