linux-kernel - Re: [PATCH 5/5] x86: Add debug of invalid per

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]

Message-ID: <4790F49C.3050002@sgi.com>
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/