netdev - Re: [PATCH net v2 2/3] taprio: Allow users not to specify "flags" when changing schedules

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+h21hoDDULPuhkEDCby0RBs+3r0angFVvyvazvedRTdWX_UYQ@mail.gmail.com>
Date:   Wed, 29 Jan 2020 13:24:30 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        netdev <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Po Liu <po.liu@....com>
Subject: Re: [PATCH net v2 2/3] taprio: Allow users not to specify "flags"
 when changing schedules

Hi David,

On Wed, 29 Jan 2020 at 12:14, David Miller <davem@...emloft.net> wrote:
>
> From: Vinicius Costa Gomes <vinicius.gomes@...el.com>
> Date: Tue, 28 Jan 2020 15:52:26 -0800
>
> > When any offload mode is enabled, users had to specify the
> > "flags" parameter when adding a new "admin" schedule.
> >
> > This fix allows that parameter to be omitted when adding a new
> > schedule.
> >
> > This will make that we have one source of truth for 'flags'.
> >
> > Fixes: 4cfd5779bd6e ("taprio: Add support for txtime-assist mode")
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@...el.com>
> > Acked-by: Vladimir Oltean <vladimir.oltean@....com>
>
> This will visibly change behavior for a feature in a released
> kernel (v5.3 and later) and it means that newer tools will do
> things that don't work in older kernels.
>
> I think your opportunity to adjust these semantics, has therefore,
> long passed.
>
> Sorry.

This is where the kernel-userspace policy escapes me a little bit.
How is this different from having a bug that would cause the "flags"
field to e.g. be ignored? Would the kernel policy make it impossible
for that bug to be fixed?
At some point, the 5.3 kernel will go EOL. When would be a good time
to make the "flags" optional on "tc qdisc replace", without concerns
about different behavior across versions?

Regards,
-Vladimir