From: Jakub Kicinski <kuba@kernel.org>
To: David Lamparter <equinox@diac24.net>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
David Ahern <dsahern@kernel.org>
Subject: Re: [PATCH net-next v5] net: ip6mr: add RTM_GETROUTE netlink op
Date: Sat, 9 Jul 2022 12:23:20 -0700 [thread overview]
Message-ID: <20220709122320.7ecc9621@kernel.org> (raw)
In-Reply-To: <Ysl4TPkTNW+6JPj4@eidolon.nox.tf>
On Sat, 9 Jul 2022 14:45:00 +0200 David Lamparter wrote:
> > > + err = ip6mr_rtm_valid_getroute_req(in_skb, nlh, tb, extack);
> > > + if (err < 0)
> > > + goto errout;
> >
> > Can we:
> >
> > return err;
> >
> > ? I don't know where the preference for jumping to the return statement
> > came from, old compilers? someone's "gut feeling"?
>
> If I were forced to find a justification, I'd say having a central
> sequence of exit helps avoiding mistakes when some other resource
> acquisition is added later. Easy to add a cleanup call to an existing
> cleanup block - easy to overlook a "return err;" that needs to be
> changed to "goto errout;".
That only works if the label's name is meaningless, if the label is
named after what it points to you have to rename the label and all the
jumps anyway. Can as well replace returns with a goto.
> But I have absolutely no stake in this at all, I'll happily edit it to
> whatever the consensus is. This is just what the IPv4 code looks like
> after being adapted for IPv6.
Ah, I looked around other getroute implementations but not specifically
ipmr. I'd rather refactor ipmr.c as well than keep its strangeness.
The fact that we jump to the error path which tries to free the skb
without ever allocating the skb feels particularly off.
prev parent reply other threads:[~2022-07-09 19:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 9:33 [PATCH net-next v5] net: ip6mr: add RTM_GETROUTE netlink op David Lamparter
2022-07-09 3:29 ` Jakub Kicinski
2022-07-09 12:45 ` David Lamparter
2022-07-09 19:23 ` Jakub Kicinski [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=20220709122320.7ecc9621@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=equinox@diac24.net \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.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).