On Tue, Jun 30, 2020 at 08:45:13PM -0400, Willem de Bruijn wrote:
> On Tue, Jun 30, 2020 at 7:46 PM Martin KaFai Lau wrote:
> >
> > On Tue, Jun 30, 2020 at 07:20:46PM -0400, Willem de Bruijn wrote:
> > > On Tue, Jun 30, 2020 at 6:18 PM Martin KaFai Lau wrote:
> > > >
> > > > When testing a recent
On Tue, Jun 30, 2020 at 7:46 PM Martin KaFai Lau wrote:
>
> On Tue, Jun 30, 2020 at 07:20:46PM -0400, Willem de Bruijn wrote:
> > On Tue, Jun 30, 2020 at 6:18 PM Martin KaFai Lau wrote:
> > >
> > > When testing a recent kernel (5.6 in our case), the skb->mark of the
> > > IPv4 TCP RST pkt does no
On Tue, Jun 30, 2020 at 07:20:46PM -0400, Willem de Bruijn wrote:
> On Tue, Jun 30, 2020 at 6:18 PM Martin KaFai Lau wrote:
> >
> > When testing a recent kernel (5.6 in our case), the skb->mark of the
> > IPv4 TCP RST pkt does not carry the mark from sk->sk_mark. It is
> > discovered by the bpf@t
On Tue, Jun 30, 2020 at 6:18 PM Martin KaFai Lau wrote:
>
> When testing a recent kernel (5.6 in our case), the skb->mark of the
> IPv4 TCP RST pkt does not carry the mark from sk->sk_mark. It is
> discovered by the bpf@tc that depends on skb->mark to work properly.
> The same bpf prog has been w
When testing a recent kernel (5.6 in our case), the skb->mark of the
IPv4 TCP RST pkt does not carry the mark from sk->sk_mark. It is
discovered by the bpf@tc that depends on skb->mark to work properly.
The same bpf prog has been working in the earlier kernel version.
After reverting commit c6af0c