mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Kent Overstreet <koverstreet@google.com>,
	linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
	Christoph Lameter <cl@linux-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()
Date: Wed, 19 Jun 2013 19:23:12 -0700	[thread overview]
Message-ID: <20130620022312.GA26127@htj.dyndns.org> (raw)
In-Reply-To: <878v25mwag.fsf@rustcorp.com.au>

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

      reply	other threads:[~2013-06-20  2:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-13  3:52 Tejun Heo
2013-06-13  3:52 ` [PATCH percpu/for-3.11 2/2] percpu-refcount: implement percpu_ref_cancel_init() Tejun Heo
2013-06-13  3:56   ` Kent Overstreet
2013-06-13  3:58     ` Tejun Heo
2013-06-13  4:00       ` Kent Overstreet
2013-06-13 18:09         ` Tejun Heo
2013-06-19  2:55 ` [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() Rusty Russell
2013-06-19  8:21   ` Tejun Heo
2013-06-20  0:59     ` Rusty Russell
2013-06-20  2:23       ` Tejun Heo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130620022312.GA26127@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=cl@linux-foundation.org \
    --cc=koverstreet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®