linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Julia Lawall <julia.lawall@lip6.fr>,
	Jason Wang <jasowang@redhat.com>,
	linux-doc@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] CodingStyle: add some more error handling guidelines
Date: Mon, 22 Aug 2016 17:53:02 +0300	[thread overview]
Message-ID: <20160822174355-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20160822081617.386db8cd@lwn.net>

On Mon, Aug 22, 2016 at 08:16:17AM -0600, Jonathan Corbet wrote:
> On Mon, 22 Aug 2016 16:57:46 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> > add some more error handling guidelines") suggests never naming goto
> > labels after the goto location - that is the error that is handled.
> > 
> > But it's actually pretty common and IMHO it's a reasonable style
> > provided each error gets its own label, and each label comes after the
> > matching cleanup:
> > 
> >                 foo = kmalloc(SIZE, GFP_KERNEL);
> >                 if (!foo)
> >                         goto err_foo;
> > 
> >                 foo->bar = kmalloc(SIZE, GFP_KERNEL);
> >                 if (!foo->bar)
> >                         goto err_bar;
> >                 ...
> > 
> >                 kfree(foo->bar);
> >         err_bar:
> > 
> >                 kfree(foo);
> >         err_foo:
> > 
> >                 return ret;
> 
> Hmm, I've never encountered that style, but I've never gone looking for it
> either.  I find it a little confusing to detach a label from the code it
> will run.  Is this really something we want to encourage?  I kind of think
> this one needs some acks before I can consider it.

The point is really naming label for the part of init that failed
(and so needs to be skipped), rather than the part that will run.
Adding empty lines is not the point - does it look better like this?


                foo = kmalloc(SIZE, GFP_KERNEL);
                if (!foo)
                        goto err_foo;

                foo->bar = kmalloc(SIZE, GFP_KERNEL);
                if (!foo->bar)
                        goto err_bar;
                ...

                kfree(foo->bar);
        err_bar:
                kfree(foo);
        err_foo:
                return ret;




I don't know whether there are examples outside code that
I wrote myself, e.g. in vhost_dev_set_owner. I find
that it's helpful since it avoids churn if more
allocations are added.


> > diff --git a/tools/virtio/ringtest/main.h b/tools/virtio/ringtest/main.h
> > index 16917ac..e4d76c3 100644
> > --- a/tools/virtio/ringtest/main.h
> > +++ b/tools/virtio/ringtest/main.h
> > @@ -80,7 +80,9 @@ extern unsigned ring_size;
> >  
> >  /* Is there a portable way to do this? */
> >  #if defined(__x86_64__) || defined(__i386__)
> > -#define cpu_relax() asm ("rep; nop" ::: "memory")
> > +#define cpu_relax() do { \
> > +	asm ("rep; nop" ::: "memory"); \
> > +} while (0)
> >  #else
> >  #define cpu_relax() assert(0)
> >  #endif
> 
> This hunk seems somehow unrelated, either that or I really haven't
> understood the proposal :)
> 
> jon

Ouch, that's unrelated, sorry.

-- 
MST

  reply	other threads:[~2016-08-22 14:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-22 13:57 [PATCH] CodingStyle: add some more error handling guidelines Michael S. Tsirkin
2016-08-22 14:16 ` Jonathan Corbet
2016-08-22 14:53   ` Michael S. Tsirkin [this message]
2016-08-22 18:31     ` Dan Carpenter
2016-08-22 18:39       ` Michael S. Tsirkin
2016-08-22 18:50     ` Dan Carpenter
2016-08-22 19:31       ` Michael S. Tsirkin
2016-08-22 14:23 ` Dan Carpenter
2016-08-23 11:03 ` Bjørn Mork
2016-08-23 11:58   ` Dan Carpenter
2016-08-23 12:46     ` Bjørn Mork
2016-08-23 14:05       ` Dan Carpenter
  -- strict thread matches above, loose matches on Subject: below --
2014-12-02  7:37 [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection Julia Lawall
2014-12-02  8:59 ` [patch] CodingStyle: add some more error handling guidelines Dan Carpenter
2014-12-02  9:09   ` Julia Lawall
2014-12-02 13:56     ` Jonathan Corbet
2014-12-03 12:31   ` SF Markus Elfring
2014-12-03 12:39     ` Arend van Spriel
2014-12-03 12:51       ` SF Markus Elfring
2014-12-03 12:45     ` Dan Carpenter
2014-12-03 12:52       ` Julia Lawall
2014-12-03 13:15         ` Dan Carpenter
2014-12-03 13:00       ` SF Markus Elfring
2014-12-03 13:20         ` Dan Carpenter
2014-12-03 13:24           ` SF Markus Elfring
2014-12-03 14:08             ` Arend van Spriel
2014-12-03 16:00               ` SF Markus Elfring
2014-12-03 19:13                 ` Arend van Spriel
2014-12-03 23:11                   ` SF Markus Elfring

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=20160822174355-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dan.carpenter@oracle.com \
    --cc=jasowang@redhat.com \
    --cc=julia.lawall@lip6.fr \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.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).