From: Jakub Kicinski <kuba@kernel.org>
To: Dan Carpenter <error27@gmail.com>
Cc: David Ahern <dsahern@kernel.org>, Haoyi Liu <iccccc@hust.edu.cn>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
hust-os-kernel-patches@googlegroups.com, yalongz@hust.edu.cn,
Dongliang Mu <dzm91@hust.edu.cn>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2] net/ipv6: silence 'passing zero to ERR_PTR()' warning
Date: Mon, 17 Apr 2023 19:17:34 -0700 [thread overview]
Message-ID: <20230417191734.78c18a5f@kernel.org> (raw)
In-Reply-To: <11c76aa6-4c19-4f1d-86dd-e94e683dbd64@kili.mountain>
On Fri, 14 Apr 2023 09:32:51 +0300 Dan Carpenter wrote:
> Also it can return NULL.
>
> net/xfrm/xfrm_policy.c
> 3229 dst = dst_orig;
> 3230 }
> 3231 ok:
> 3232 xfrm_pols_put(pols, drop_pols);
> 3233 if (dst && dst->xfrm &&
> ^^^
> "dst" is NULL.
Don't take my word for it, but AFAICT it's impossible to get there with
dst == NULL. I think we can remove this check instead if that's what
makes smatch infer that dst may be NULL.
> 3234 dst->xfrm->props.mode == XFRM_MODE_TUNNEL)
> 3235 dst->flags |= DST_XFRM_TUNNEL;
> 3236 return dst;
> ^^^^^^^^^^^
> 3237
>
> So in the original code what happened here was:
>
> net/ipv6/icmp.c
> 395 dst2 = xfrm_lookup(net, dst2, flowi6_to_flowi(&fl2), sk, XFRM_LOOKUP_ICMP);
> 396 if (!IS_ERR(dst2)) {
>
> xfrm_lookup() returns NULL. NULL is not an error pointer.
>
> 397 dst_release(dst);
> 398 dst = dst2;
>
> We set "dst" to NULL.
>
> 399 } else {
> 400 err = PTR_ERR(dst2);
> 401 if (err == -EPERM) {
> 402 dst_release(dst);
> 403 return dst2;
> 404 } else
> 405 goto relookup_failed;
> 406 }
> 407
> 408 relookup_failed:
> 409 if (dst)
> 410 return dst;
>
> dst is not NULL so we don't return it.
>
> 411 return ERR_PTR(err);
>
> However "err" is not set so we do return NULL and Smatch complains about
> that.
>
> Returning ERR_PTR(0); is not necessarily a bug, however 80% of the time
> in newly introduced code it is a bug. Here, returning NULL is correct.
> So this is a false positive, but the code is just wibbly winding and so
> difficult to read.
>
> 412 }
next prev parent reply other threads:[~2023-04-18 2:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 10:10 [PATCH net-next v2] net/ipv6: silence 'passing zero to ERR_PTR()' warning Haoyi Liu
2023-04-13 22:50 ` Jacob Keller
2023-04-14 0:32 ` David Ahern
2023-04-14 6:32 ` Dan Carpenter
2023-04-18 2:17 ` Jakub Kicinski [this message]
2023-04-18 20:46 ` David Ahern
2023-05-11 14:52 ` 刘浩毅
2023-05-11 15:38 ` Jakub Kicinski
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=20230417191734.78c18a5f@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=dzm91@hust.edu.cn \
--cc=edumazet@google.com \
--cc=error27@gmail.com \
--cc=hust-os-kernel-patches@googlegroups.com \
--cc=iccccc@hust.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yalongz@hust.edu.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.