[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120130173311.GE3355@google.com>
Date: Mon, 30 Jan 2012 09:33:11 -0800
From: Tejun Heo <tj@...nel.org>
To: Christoph Lameter <cl@...ux.com>
Cc: Dmitry Antipov <dmitry.antipov@...aro.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 11:22:57AM -0600, Christoph Lameter wrote:
> On Mon, 30 Jan 2012, Tejun Heo wrote:
>
> > 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.
>
> The same is true for the use of NULL pointers.
I'm pretty sure it never gives out NULL for a dynamic allocation. The
base might be mapped to zero but we're guaranteed to have some static
percpu areas there and IIRC the percpu addresses aren't supposed to
wrap.
Also, if ZERO_SIZE_PTR doesn't actually help anything, it is not a
good idea to have it. The only thing it does would be giving wrong
impressions.
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/
Powered by blists - more mailing lists