NACK: [SRU][F:linux-bluefield][PATCH 0/8] Fix fragmentation support for TC connection tracking

Maor Dickman maord at nvidia.com
Mon Aug 30 14:32:09 UTC 2021


Will do.

> -----Original Message-----
> From: Tim Gardner <tim.gardner at canonical.com>
> Sent: Monday, August 30, 2021 2:43 PM
> To: Maor Dickman <maord at nvidia.com>; Bodong Wang
> <bodong at nvidia.com>; kernel-team at lists.ubuntu.com
> Cc: Majd Dibbiny <majd at nvidia.com>
> Subject: Re: NACK: [SRU][F:linux-bluefield][PATCH 0/8] Fix fragmentation
> support for TC connection tracking
> 
> External email: Use caution opening links or attachments
> 
> 
> So, you're going to send a v2 of this patch set with correct 'backported'
> descriptions in patches [1] and [2], right ?
> 
> rtg
> 
> On 8/30/21 5:15 AM, Maor Dickman wrote:
> > Linux-bluefield branch contains two patches [1][2] which cause a
> > conflict when I tried to cherry-pick the patch and forced me to do small
> modification.
> >
> > Patch [1] was submitted to upstream after this patch ("Fix
> > fragmentation support for TC connection tracking")
> >
> > Patch [2] is wrong so I revert it in later patch.
> >
> > [1] 7a73ed569d90 net/sched: act_ct: Fix skb double-free in
> > tcf_ct_handle_fragments() error flow [2] f797fab7280c net/sched:
> > act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow
> >
> >> -----Original Message-----
> >> From: Tim Gardner <tim.gardner at canonical.com>
> >> Sent: Tuesday, August 24, 2021 2:47 PM
> >> To: Bodong Wang <bodong at nvidia.com>; kernel-team at lists.ubuntu.com
> >> Cc: Maor Dickman <maord at nvidia.com>; Majd Dibbiny
> <majd at nvidia.com>
> >> Subject: NACK: [SRU][F:linux-bluefield][PATCH 0/8] Fix fragmentation
> >> support for TC connection tracking
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> While these patches do apply correctly, PATCH 1/8 is not a cherry-pick.
> >> Even if you did the revert first ("Revert "net/sched: act_ct: Fix skb
> >> double- free in tcf_ct_handle_fragments() error flow"), its still not
> >> a clean cherry-pick though it is a simpler backport.
> >>
> >> rtg
> >>
> >> On 8/23/21 4:36 PM, Bodong Wang wrote:
> >>> When using OVS with tc to offload connection tracking flows, sending
> >>> udp/icmp fragmented traffic will cause call trace with NULL dereference.
> >>>
> >>> This series contains 7 patches from upstream which fix act_ct
> >>> handling of fragmented packets. And revert a patch which is covered
> >>> by the 7 upstream patches.
> >>>
> >>> Davide Caratti (1):
> >>>     net/sched: act_ct: fix wild memory access when clearing
> >>> fragments
> >>>
> >>> Maor Dickman (1):
> >>>     Revert "net/sched: act_ct: Fix skb double-free in
> >>>       tcf_ct_handle_fragments() error flow"
> >>>
> >>> wenxu (6):
> >>>     net/sched: act_ct: fix restore the qdisc_skb_cb after defrag
> >>>     net/sched: act_ct: fix miss set mru for ovs after defrag in act_ct
> >>>     net/sched: fix miss init the mru in qdisc_skb_cb
> >>>     net/sched: act_mirred: refactor the handle of xmit
> >>>     net/sched: sch_frag: add generic packet fragment support.
> >>>     ipv6: add ipv6_fragment hook in ipv6_stub
> >>>
> >>>    include/linux/skbuff.h    |   1 +
> >>>    include/net/act_api.h     |   6 ++
> >>>    include/net/ipv6_stubs.h  |   2 +
> >>>    include/net/sch_generic.h |   8 +--
> >>>    net/core/dev.c            |   2 +
> >>>    net/ipv6/addrconf_core.c  |   8 +++
> >>>    net/ipv6/af_inet6.c       |   1 +
> >>>    net/openvswitch/flow.c    |   1 +
> >>>    net/sched/Makefile        |   1 +
> >>>    net/sched/act_api.c       |  16 +++++
> >>>    net/sched/act_ct.c        |  29 +++++++--
> >>>    net/sched/act_mirred.c    |  21 +++++--
> >>>    net/sched/cls_api.c       |   1 +
> >>>    net/sched/sch_frag.c      | 150
> >> ++++++++++++++++++++++++++++++++++++++++++++++
> >>>    14 files changed, 231 insertions(+), 16 deletions(-)
> >>>    create mode 100644 net/sched/sch_frag.c
> >>>
> >>
> >> --
> >> -----------
> >> Tim Gardner
> >> Canonical, Inc
> 
> --
> -----------
> Tim Gardner
> Canonical, Inc


More information about the kernel-team mailing list