netdev - Re: [PATCH] net-ipv6: changes to ->tclass (via IPV6_TCLASS) should sk_dst

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANP3RGcYE8w=izZUg-+5q0kCodgFpXUfV9ZVDSgr6bz0hy5jPg@mail.gmail.com>
Date:   Wed, 24 Nov 2021 20:47:26 -0800
From:   Maciej Żenczykowski <zenczykowski@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Linux Network Development Mailing List <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [PATCH] net-ipv6: changes to ->tclass (via IPV6_TCLASS) should sk_dst_reset()

On Wed, Nov 24, 2021 at 7:01 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 23 Nov 2021 14:32:08 -0800 Maciej Żenczykowski wrote:
> > From: Maciej Żenczykowski <maze@...gle.com>
> >
> > This is to match ipv4 behaviour, see __ip_sock_set_tos()
> > implementation.
> >
> > Technically for ipv6 this might not be required because normally we
> > do not allow tclass to influence routing, yet the cli tooling does
> > support it:
> >
> > lpk11:~# ip -6 rule add pref 5 tos 45 lookup 5
> > lpk11:~# ip -6 rule
> > 5:      from all tos 0x45 lookup 5
> >
> > and in general dscp/tclass based routing does make sense.
> >
> > We already have cases where dscp can affect vlan priority and/or
> > transmit queue (especially on wifi).
> >
> > So let's just make things match.  Easier to reason about and no harm.
> >
> > Cc: Eric Dumazet <edumazet@...gle.com>
> > Cc: Neal Cardwell <ncardwell@...gle.com>
> > Signed-off-by: Maciej Żenczykowski <maze@...gle.com>
>
> Please send related patches as a series. There are dependencies here
> which prevent the build bot from doing its job (plus it's less work
> for me since I apply by series :)).

Ah, sorry, while the patches were stacked on each other, they're kind
of orthogonal to each other,
and neither one actually depends on the other (outside of their being
a conflict because of touching nearby code).
That's why I sent them out separately.

Additionally, I've also noticed that often the first patch out of two
won't be merged if there's disagreement on the second, even though the
first might be entirely acceptable.