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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 18 Jan 2008 10:49:00 -0800
From:	Mike Travis <travis@....com>
To:	Andi Kleen <ak@...e.de>
CC:	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
	Christoph Lameter <clameter@....com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] x86: Add debug of invalid per_cpu map accesses

Andi Kleen wrote:
> On Friday 18 January 2008 19:30:16 travis@....com wrote:
>> Provide a means to trap usages of per_cpu map variables before
>> they are setup.  Define CONFIG_DEBUG_PER_CPU_MAPS to activate.
> 
> Are you sure that debug option is generally useful enough
> to merge? It seems very specific to your patchkit, but I'm not
> sure it would be worth carrying forever in the kernel.
> 
> Better would be probably to just unmap those areas anyways.
> 
> -Andi

I thought for a round of testing it'd be worthwhile, particularly
testing randconfig.  The next version of percpu changes are coming
soon and I can remove them then.  Ideally, you are right, it'd
be nice to not have the percpu memory mapped for processors that are
not present.

One thing that comes into play is that (soon) the boot_pda will be
in the per_cpu area and it's maintained for all "possible" cpus as
it keeps track of some info on "off-lined" cpus.  What I was thinking
is that perhaps no memory is allocated (and mapped) until a cpu
becomes not only possible, but probable.  This means that until a
cpu is brought online, or discovered via ACPI, then there is no percpu
area and access to an invalid percpu area causes a kernel fault.

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