linux-kernel - Re: [PATCH percpu/for-3.11 1/2] percpu-refcount: add __must_check to percpu_ref_init() and don't use ACCESS_ONCE() in percpu_ref_kill

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] [day] [month] [year] [list]

Message-ID: <20130620022312.GA26127@htj.dyndns.org>
Date:	Wed, 19 Jun 2013 19:23:12 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Kent Overstreet <koverstreet@...gle.com>,
	linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [PATCH percpu/for-3.11 1/2] percpu-refcount: add __must_check to
 percpu_ref_init() and don't use ACCESS_ONCE() in percpu_ref_kill_rcu()

Hello,

On Thu, Jun 20, 2013 at 10:29:51AM +0930, Rusty Russell wrote:
> Now seems to get abused by lazy coders who blame users for their own
> broken APIs.  And Ubuntu, who turn it on by default in their gcc when
> optimizing.  Yeah, it's a sore point :)

How is the API broken?  It is a function which either succeeds or
fails and, if it fails during boot, like any other allocation failures
during boot, the boot fails.  It's not different from kmalloc()
returning NULL on failure.

>         	if (system(command))
>         		doesnt_matter();

It *does* matter.

> Sorry, I was unclear.  If you fail the percpu allocation, you have a
> counter which is always in atomic mode.
> 
> This saves everyone a headache.  init doesn't fail, no poorly-tested
> failure paths, no whining Rusty.

How does that save a headache?  It *should* fail if allocation fails.
Having untraceable persistent slow down after heavy memory pressure is
no fun to track down.  If you're worried about not being able to
detect bugs in error path, the right thing to do would be inducing
allocation failures regularly so that those paths can be tested, which
we already do.

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/