linux-kernel - Re: [PULL] cpumask: finally make them variable size w/ CPUMASK

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: <87fwb8dgkn.fsf@rustcorp.com.au>
Date:	Thu, 10 May 2012 09:59:12 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>, anton@...ba.org,
	Arnd Bergmann <arnd@...db.de>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mike Travis <travis@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PULL] cpumask: finally make them variable size w/ CPUMASK_OFFSTACK.

On Wed, 9 May 2012 10:44:53 +0200, Ingo Molnar <mingo@...nel.org> wrote:
> 
> * Rusty Russell <rusty@...tcorp.com.au> wrote:
> 
> > Hi Ingo,
> > 
> >         I finally rebased this on top of your tip tree, and tested it
> > locally.  Some more old-style cpumask usages have crept in, but it's a
> > fairly simple series.
> 
> Cool! Most of it looks pretty sane. I have a question about the 
> gist of the series:
> 
> > commit 898eb73305e2277be91b931c5a75484f8c87ae36
> > Author: Rusty Russell <rusty@...tcorp.com.au>
> > Date:   Wed May 9 15:01:15 2012 +0930
> > 
> >     cpumask: remove struct cpumask definition when CONFIG_CPUMASK_OFFSTACK=y
> >     
> >     We're about to change CONFIG_CPUMASK_OFFSTACK so it only allocate
> >     nr_cpu_ids bits for all cpumasks.  We need to make sure that when
> >     CONFIG_CPUMASK_OFFSTACK is set:
> >     
> >     1) Noone uses the old bitmap ops, which use NR_CPUS bits (use cpumask_*)
> >     2) Noone uses assignment of struct cpumask (use cpumask_copy)
> >     3) Noone passes a struct cpumask (pass a pointer)
> >     4) Noone declares them on the stack (use cpumask_var_t)
> >     
> >     So we finally remove the definition of struct cpumask when
> >     CONFIG_CPUMASK_OFFSTACK=y.  This means that these usages will hit a compile
> >     error the moment that config option is turned on.
> >     
> >     Note that it also means you can't declare a static cpumask.  You
> >     should avoid this anyway (use cpumask_var_t), but there's a
> >     deliberately-ugly workaround for special cases, using DECLARE_BITMAP()
> >     and to_cpumask().
> >     
> >     Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
> >     Cc: Arnd Bergmann <arnd@...db.de>
> >     Cc: anton@...ba.org
> >     Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> >     Cc: Mike Travis <travis@....com>
> 
> Is there any good reason to not remove it altogether, regardless 
> of whether the OFFSTACK config is set? I mean, triggering build 
> failures for a relatively rarely turned on config option is 
> asking for constant maintenance trouble.

Mainly because I didn't want to disturb the archs which don't care at
all about large cpumasks.  After all, putting a struct cpumask on the
stack is pretty convenient.

But we could add a new arch config which removes it, and set it from
x86.

Cheers,
Rusty.
--
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/