Netdev List
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Antony Antony <antony@phenome.org>
Cc: Antony Antony <antony.antony@secunet.com>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	devel@linux-ipsec.org, Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages
Date: Wed, 31 Jan 2024 22:48:02 +0300	[thread overview]
Message-ID: <c973a8fc-2baa-49e8-9c8f-fd63ef348f92@moroto.mountain> (raw)
In-Reply-To: <Zbqhy8U-o2uL2_us@Antony2201.local>

On Wed, Jan 31, 2024 at 08:38:51PM +0100, Antony Antony wrote:
> HI Dan,
> 
> Thanks for reporting the warning.
> 
> On Tue, Jan 30, 2024 at 01:36:28PM +0300, Dan Carpenter wrote:
> > 
> > Hello Antony Antony,
> > 
> > The patch 63b21caba17e: "xfrm: introduce forwarding of ICMP Error
> > messages" from Jan 19, 2024 (linux-next), leads to the following
> > Smatch static checker warning:
> > 
> > 	net/xfrm/xfrm_policy.c:3708 __xfrm_policy_check()
> > 	error: testing array offset 'dir' after use.
> 
> > 
> > net/xfrm/xfrm_policy.c
> >   3689  
> >   3690          pol = NULL;
> >   3691          sk = sk_to_full_sk(sk);
> >   3692          if (sk && sk->sk_policy[dir]) {
> >                             ^^^^^^^^^^^^^^^^
> > If dir is XFRM_POLICY_FWD (2) then it is one element beyond the end of
> > the ->sk_policy[] array.
> 
> Yes, that's correct. However, for this patch, it's necessary that sk != NULL 
> at the same time. As far as I know, there isn't any code that would call dir 
> = XFRM_POLICY_FWD with sk != NULL. What am I missing? Did Smatch give any 
> hints for such a code path?
> 

I wondered if that might be the case.  The truth is that this sort of
dependency is too compicated for any static analysis tools that
currently exist.  Smatch tries to track the relationship between
"dir" and "sk" as they are passed in, but it will look the relationship
information when we re-assign sk.  "sk = sk_to_full_sk(sk);".

So what we do in this case, is we just ignore the warning and if anyone
has questions about it they will look up this conversation on
lore.kernel.org to find the explanation.

No need to worry about trying to silence the checker...

regards,
dan carpenter


  reply	other threads:[~2024-01-31 19:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YTXGGiMzsda6mcm2@AntonyAntony.local>
2021-12-19  0:28 ` [RFC PATCH ipsec-next] xfrm: add forwarding ICMP error message Antony Antony
2023-10-26 14:45   ` [PATCH ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-10-26 19:41     ` kernel test robot
2024-01-30 10:36     ` Dan Carpenter
2024-01-31 19:38       ` Antony Antony
2024-01-31 19:48         ` Dan Carpenter [this message]
2024-01-31 19:50           ` Dan Carpenter
2023-10-26 14:45   ` [PATCH ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-10-27  8:16   ` [PATCH v2 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-11-17  9:13     ` Steffen Klassert
2023-11-25 22:48       ` [devel-ipsec] " Antony Antony
2023-10-27  8:16   ` [PATCH v2 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-10-27 13:30     ` [devel-ipsec] " Michael Richardson
2023-10-29 10:26       ` Antony Antony
2023-10-31  7:59         ` Michael Richardson
2023-11-17  9:21     ` Steffen Klassert
2023-11-25 23:15       ` [devel-ipsec] " Antony Antony
2023-12-19 20:29   ` [PATCH v3 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-12-19 20:30   ` [PATCH v3 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-12-21 13:12   ` [PATCH v4 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-12-21 13:12   ` [PATCH v4 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-12-22  7:23     ` Steffen Klassert
2023-12-22 12:56       ` Antony Antony
2023-12-22 12:57   ` [PATCH v5 ipsec-next] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2024-01-04  9:39     ` Steffen Klassert
2024-01-19 11:27   ` [PATCH v6 " Antony Antony
2024-01-26  9:11     ` Steffen Klassert

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=c973a8fc-2baa-49e8-9c8f-fd63ef348f92@moroto.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=antony.antony@secunet.com \
    --cc=antony@phenome.org \
    --cc=davem@davemloft.net \
    --cc=devel@linux-ipsec.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    /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