In message: Re: [linux-yocto][v5.10/standard/base][PATCH] ipv6: Fix stats
accounting in ip6_pkt_drop
on 06/04/2022 He Zhe wrote:
>
>
> On 4/6/22 20:07, Paul Gortmaker wrote:
> > [[linux-yocto][v5.10/standard/base][PATCH] ipv6: Fix stats accounting in
> > ip6_pkt_drop] On 06/04/2022 (Wed 15:54) He Zhe wrote:
> >
> >> VRF devices are the loopbacks for VRFs, and a loopback can not be
> >> assigned to a VRF. Accordingly, the condition in ip6_pkt_drop should
> >> be '||' not '&&'.
> >>
> >> Fixes: 1d3fd8a10bed ("vrf: Use orig netdev to count Ip6InNoRoutes and a
> >> fresh route lookup when sending dest unreach")
> >> Reported-by: Pudak, Filip <[email protected]>
> >> Reported-by: Xiao, Jiguang <[email protected]>
> >> Signed-off-by: David Ahern <[email protected]>
> >> Link: https://lore.kernel.org/r/[email protected]
> >> Signed-off-by: Paolo Abeni <[email protected]>
> >>
> >> Link:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=1158f79f82d4
> > As this is in "net" (and not "net-next") it will go to mainline in a
> > few days[1], and the LF stable team will grab it via the Fixes tag and
> > backport it automatically (since it is a trivial change).
> >
> > What I'm getting at here, is that expiditing this (and any other fix that
> > matches this same criteria) is a make-work project for yourself and for
> > Bruce. Unless it is has a priority (like a 0-day CVE) then there is no
> > point trying to accelerate it vs. just waiting the few extra days for
> > the normal "hands-free" process feed to take place on its own.
> >
> > And then it will have [comit abcd upstream] on it as well, indicating
> > clearly that it was a mainline commit and not something that maybe
> > died on a mailing list thread and went no further.
>
> We have customer experiencing network statistics error due to this bug and it
> may also be the case for other Yocto users. Fixing this earlier may be more
> important for them vs developers waiting and feeling hands-free. Anyway, this
> patch is here up to maintainer's choice and convenience.
I do see this in the 5.18-rc2 pull request for networking, so indeed
it will be in master shortly. The -stable cycle hasn't been quite as
regular this past little while, so I've gone ahead and merged this, as
it won't cause issues when I do get it via -stable.
But Paul's advice is good. If there's a patch we are cherry picking
from a mainline destined source, then it is worth making sure that
-stable will also pick it, and then mention briefly about why
grabbing it earlier is useful ... or if it isn't going to -stable,
why it won't be arriving via that flow.
Bruce
>
> Thanks,
> Zhe
>
> >
> > Thanks,
> > Paul.
> >
> > [1]
> > https://docs.kernel.org/process/maintainer-netdev.html#how-do-the-changes-posted-to-netdev-make-their-way-into-linux
> > --
> >
> >> Signed-off-by: He Zhe <[email protected]>
> >> ---
> >> 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 352e645c546e..776b1b58c5dc 100644
> >> --- a/net/ipv6/route.c
> >> +++ b/net/ipv6/route.c
> >> @@ -4398,7 +4398,7 @@ static int ip6_pkt_drop(struct sk_buff *skb, u8
> >> code, int ipstats_mib_noroutes)
> >> struct inet6_dev *idev;
> >> int type;
> >>
> >> - if (netif_is_l3_master(skb->dev) &&
> >> + if (netif_is_l3_master(skb->dev) ||
> >> dst->dev == net->loopback_dev)
> >> idev = __in6_dev_get_safely(dev_get_by_index_rcu(net,
> >> IP6CB(skb)->iif));
> >> else
> >> --
> >> 2.17.1
> >>
> >>
> >>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11140):
https://lists.yoctoproject.org/g/linux-yocto/message/11140
Mute This Topic: https://lists.yoctoproject.org/mt/90285003/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
