linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Tejun Heo <tj@kernel.org>
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: Thu, 20 Jun 2013 10:29:51 +0930	[thread overview]
Message-ID: <878v25mwag.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130619082123.GD30681@mtj.dyndns.org>

Tejun Heo <tj@kernel.org> writes:
> On Wed, Jun 19, 2013 at 12:25:14PM +0930, Rusty Russell wrote:
>> But it's quite OK to ignore OOM errors in builtin init functions.
>
> I think it'd be cleaner to let those use cases use BUG_ON() around it.
> We really want most users to be checking its return value.

Yeah, but it's an admission of API design failure.

__attribute__((warn_unused_result)) is a bad implementation of a poorly
conceived idea.  It was originally designed to catch realloc misuse,
which is presumably why casting to (void) doesn't suppress it.
Protecting realloc properly would mean the GCC understanding that the
pointer arg handed to realloc was no longer valid which would catch many
more cases, but compilers are hard, so we got the hacky attribute.

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 :)

So I end up writing code like this (to quote from ccan):

        /* Gcc's warn_unused_result is fascist bullshit. */
        #define doesnt_matter()
...
        	if (system(command))
        		doesnt_matter();

>> It would be neatest to have it fail into slow mode, of course, but it's
>> probably not worth the pain.
>
> percpu allocation is always GFP_KERNEL, so it can't get any slower
> without deadlocking.

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.

Rant over,
Rusty.

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

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-13  3:52 [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() 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 [this message]
2013-06-20  2:23       ` Tejun Heo

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=878v25mwag.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=cl@linux-foundation.org \
    --cc=koverstreet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).