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: <alpine.DEB.2.00.1201301206080.28693@router.home>
Date:	Mon, 30 Jan 2012 12:12:18 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Tejun Heo <tj@...nel.org>
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, 30 Jan 2012, Tejun Heo wrote:

> Hello,
>
> On Mon, Jan 30, 2012 at 11:58:52AM -0600, Christoph Lameter wrote:
> > > No, NULL is never gonna be a valid return from any allocator including
> > > percpu.  Percpu allocator doesn't and will never do so.
> >
> > How do you prevent the percpu allocator from returning NULL? I thought the
> > per cpu offsets can wrap around?
>
> I thought it didn't.  I rememer thinking about this and determining
> that NULL can't be allocated for dynamic addresses.  Maybe I'm
> imagining things.  Anyways, if it can return NULL for valid
> allocation, it is a bug and should be fixed.

I dont see anything that would hinder an arbitrary value to be returned.
NULL is also used for the failure case. Definitely a bug.

> > > I'm saying we don't have this for ZERO_SIZE_PTR in any meaningful way
> > > at this point.  If somebody wants to implement it properly, please
> > > feel free to, but simply applying ZERO_SIZE_PTR without other changes
> > > doesn't make any sense.
> >
> > We have no clean notion of how a percpu pointer needs to be handled. Both
> > ways of handling things have drawbacks.
>
> We don't have returned addr >= PAGE_SIZE guarantee yet but I'm fairly
> sure that's the only acceptable direction if we want any improvement
> in this area.

The ZERO_SIZE_PTR patch would not make the situation that much worse.

If the per cpu allocator happens to return NULL for a valid allocation
then this allocation cannot be freed anymore since the free function
checks for NULL. Most callers check the result for NULL though and will
fail in other ways at a higher level. Such an allocation can only happen
once and from hen on some memory is wasted.

If the per cpu allocator just happens to return ZERO_SIZE_PTR for a valid
allocation then this value is going to be passed to other per cpu
functions. However, the size is 0 so no actual read or write should ever
take place.

On free its not going to be freed since the free function checks for
ZERO_SIZE_PTR. So we have a situation almost the same as for NULL pointer.
--
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/