net/ipv6/route.c:2332:39: warning: incorrect type in assignment (different base types)
net/ipv6/route.c:2332:39:    expected unsigned int [usertype] flow_label
net/ipv6/route.c:2332:39:    got restricted __be32

Fixes: 23aebdacb05d ("ipv6: Compute multipath hash for ICMP errors from offending packet")
Suggested-by: Eric Dumazet <edumazet@google.com>
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
---
 net/ipv6/route.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b132feae3393..1fdae8d71339 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2329,7 +2329,7 @@ static void ip6_multipath_l3_keys(const struct sk_buff *skb,
 	} else {
 		keys->addrs.v6addrs.src = key_iph->saddr;
 		keys->addrs.v6addrs.dst = key_iph->daddr;
-		keys->tags.flow_label = ip6_flowlabel(key_iph);
+		keys->tags.flow_label = (__force u32)ip6_flowlabel(key_iph);
 		keys->basic.ip_proto = key_iph->nexthdr;
 	}
 }
-- 
2.34.1

On Wed, Nov 22, 2023 at 03:19:24PM +0800, Kunwu Chan wrote:
> net/ipv6/route.c:2332:39: warning: incorrect type in assignment (different base types)
> net/ipv6/route.c:2332:39:    expected unsigned int [usertype] flow_label
> net/ipv6/route.c:2332:39:    got restricted __be32

Can you expain why you think the __force cast is the correct thing to do
here?

Hi Christoph,
Thanks for your reply.
I also can't guarantee that it's the right thing to do. Just wanted to 
dispel this warning. If you have any better way, please let me know.


On 2023/11/22 15:23, Christoph Hellwig wrote:
> On Wed, Nov 22, 2023 at 03:19:24PM +0800, Kunwu Chan wrote:
>> net/ipv6/route.c:2332:39: warning: incorrect type in assignment (different base types)
>> net/ipv6/route.c:2332:39:    expected unsigned int [usertype] flow_label
>> net/ipv6/route.c:2332:39:    got restricted __be32
> 
> Can you expain why you think the __force cast is the correct thing to do
> here?

On Wed, Nov 22, 2023 at 05:04:49PM +0800, Kunwu Chan wrote:
> Hi Christoph,
> Thanks for your reply.
> I also can't guarantee that it's the right thing to do. Just wanted to
> dispel this warning. If you have any better way, please let me know.

The most likely reason is that it needs an endianess conversion.  I
don't know the answer either, but actually spending a few minutes
trying to understand the code should allow you to find it out quickly.

Removing a warning for it's own sake when you don't understand it is
never a good idea.

On 11/22/23 1:06 AM, Christoph Hellwig wrote:
> On Wed, Nov 22, 2023 at 05:04:49PM +0800, Kunwu Chan wrote:
>> Hi Christoph,
>> Thanks for your reply.
>> I also can't guarantee that it's the right thing to do. Just wanted to
>> dispel this warning. If you have any better way, please let me know.
> 
> The most likely reason is that it needs an endianess conversion.  I
> don't know the answer either, but actually spending a few minutes
> trying to understand the code should allow you to find it out quickly.
> 
> Removing a warning for it's own sake when you don't understand it is
> never a good idea.
> 

We should be able to set flow_label to __be32 in flow_dissector_key_tags
(and remove a couple ntohl).

Tom: any reason not to do that?