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]
Message-Id: <200911252203.28343.rusty@rustcorp.com.au>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ