linux-kernel - Re: cpumask: fix compat getaffinity

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: <201005142209.14473.rusty@rustcorp.com.au>
Date:	Fri, 14 May 2010 22:09:13 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Milton Miller <miltonm@....com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, anton@...ba.org
Subject: Re: cpumask: fix compat getaffinity

On Wed, 12 May 2010 06:00:45 pm Milton Miller wrote:
> 
> At least for parsing, we need to allocate and parse NR_CPUS until
> all places like arch/powerpc/platforms/pseries/xics.c that compare a
> user-supplied mask to CPUMASK_ALL are eliminated.

Good point.  Anton will want to fix those anyway for CONFIG_CPUMASK_OFFSTACK,
too, but that's the reason the parsing uses nr_cpumask_bits.

> > Would it make sense to use my initial patch for -stable, which reverts
> > the ABI back to before the change that caused the problem, but apply
> > the correct fix (changing the ABI throughout) for future releases?
> 
> This would definitly be the conservative fix.

Instead of changing back to NR_CPUS which will break libnuma for
CPUMASK_OFFSTACK, how about changing it to nr_cpumask_bits and having an
explicit comment above it:

	/* libnuma assumes we match scnprintf for /sys/.../node/node*/cpumap */

Thanks,
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/