Skip to contentSkip to conversation

xfrm: Assign the inner mode output function to the dst

DISCUSSION Dan Carpenter 2 participants 2 messages Oct 28, 2011 – Oct 29, 2011 Kernel janitors

lore
Share & tools
lore
#0 lore raw

[ Hi. Smatch is complaining about a really old patch here. Sorry
for that. I will fix it to detect better which warnings are new but I saw that there was some work done in this function recently so I decided to send this email anyway. --dan ]

Hello Steffen Klassert,

This is a semi-automatic email about new static checker warnings.

The patch 43a4dea4c9d4: "xfrm: Assign the inner mode output function to the dst entry" from May 9, 2011, leads to the following Smatch complaint:

net/ipv6/xfrm6_output.c +154 __xfrm6_output()
error: we previously assumed 'x' could be null (see line 149)

net/ipv6/xfrm6_output.c
148
149 if ((x && x->props.mode = XFRM_MODE_TUNNEL) &&

                     ^

Check.

150 ((skb->len > mtu && !skb_is_gso(skb)) ||
151 dst_allfrag(skb_dst(skb)))) {
152 return ip6_fragment(skb, x->outer_mode->afinfo->output_finish);
153 }

   154		return x->outer_mode->afinfo->output_finish(skb);
                       ^^^

New dereference.

155 }
156

regards,
dan carpenter

#1 lore raw

Hi.

Quoted 13 lines · Dan Carpenter

[ Hi. Smatch is complaining about a really old patch here. Sorry
for that. I will fix it to detect better which warnings are new but I saw that there was some work done in this function recently so I decided to send this email anyway. --dan ]

Hello Steffen Klassert,

This is a semi-automatic email about new static checker warnings.

The patch 43a4dea4c9d4: "xfrm: Assign the inner mode output function to the dst entry" from May 9, 2011, leads to the following Smatch complaint:

Quoted 7 lines

net/ipv6/xfrm6_output.c +154 __xfrm6_output()
error: we previously assumed 'x' could be null (see line 149)

net/ipv6/xfrm6_output.c
148
149 if ((x && x->props.mode = XFRM_MODE_TUNNEL) &&

                     ^

x can't be null here. It would be a bug if __xfrm6_output() is called without a xfrm_state attached to the skb. I think we can just remove this null check.