linux-kernel - Re: [PATCH 3/6] cpumask: truncate task_struct.cpus_allowed for CONFIG_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] [day] [month] [year] [list]

Date:	Wed, 25 Nov 2009 22:03:28 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, Mike Travis <travis@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 3/6] cpumask: truncate task_struct.cpus_allowed for CONFIG_CPUMASK_OFFSTACK

On Tue, 24 Nov 2009 09:44:40 am Ingo Molnar wrote:
> There's also the problem of cache footprint - we really want to freedom 
> to place the masks (which are not off-stack in the regular case) 
> anywhere in task struct - and task-struct is huge, so cache placement 
> matters.

My initial patch changed it to always be a const cpumask *, with it
pointing to the standard all or single-cpu masks in the normal cases: it
only got its own allocated if we changed it to something unusual.

It was more invasive though, and really needs to be thought about separately.
I'd want to measure how often it is accessed, for example.

> Is the ptr deref really a big problem for off-stack?

I don't think so; slightly suboptimal codegen but it'll still just point to
the end of the struct.

> Changing all users isnt a problem as long as it still looks like a clean 
> data structure with clean usage.

We're still supposed to use a wrapper to avoid a flag day.  It's gratuitous
if we're going to do this, but that's modern kernel life AFAICT.

> Those end-of-struct tricks we play with cpumasks make me really a bit uneasy.

Fair enough.

I don't know when I'll get more cycles on this.  A few more months I expect.

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/