linux-kernel - Re: [PATCH 1/3] percpu: use ZERO_SIZE_PTR / ZERO_OR_NULL

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: <20120130171919.GC3355@google.com>
Date:	Mon, 30 Jan 2012 09:19:19 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Dmitry Antipov <dmitry.antipov@...aro.org>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, patches@...aro.org,
	linaro-dev@...ts.linaro.org
Subject: Re: [PATCH 1/3] percpu: use ZERO_SIZE_PTR / ZERO_OR_NULL_PTR

On Mon, Jan 30, 2012 at 09:15:58AM -0800, Tejun Heo wrote:
> Percpu pointers are in a different address space and using
> ZERO_SIZE_PTR directly will trigger sparse address space warning.
> Also, I'm not entirely sure whether 16 is guaranteed to be unused in
> percpu address space (maybe it is but I don't think we have anything
> enforcing that).

Another thing is that percpu address dereferencing always goes through
rather unintuitive translation and 1. we can't (or rather currently
don't) guarantee that fault will occur for any address 2. even if it
does, the faulting address wouldn't be anything easily
distinguishible.  So, unless the above shortcomings is resolved, I
don't really see much point of using ZERO_SIZE_PTR for percpu
allocator.

Thanks.

-- 
tejun
--
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/