netdev - Re: [PATCH net-next] net_sched: restore "mpu xxx" handling

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: <20220112081520.23e99283@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Wed, 12 Jan 2022 08:15:20 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Kevin Bracey <kevin@...cey.fi>
Cc:     <netdev@...r.kernel.org>, Eric Dumazet <edumazet@...gle.com>,
        Jiri Pirko <jiri@...nulli.us>, Vimalkumar <j.vimal@...il.com>
Subject: Re: [PATCH net-next] net_sched: restore "mpu xxx" handling

On Wed, 12 Jan 2022 09:02:59 +0200 Kevin Bracey wrote:
> On 12/01/2022 08:36, Kevin Bracey wrote:
> >
> > Indeed, There has never been any kernel handling of tc_ratespec::mpu - 
> > the kernel merely stored the value.
> >
> > The overhead had been similarly passed to the kernel but not 
> > originally acted on. Linklayer had to be added to tc_ratespec.   
> 
> Ah, I need to correct myself there. The overhead was originally acted on 
> in qdisc_l2t. htb_l2t forgot to incorporate it.
> 
> So:
> 
>   * overhead - always passed via tc_ratespec, handled by kernel. HTB
>     temporarily ignored it.
>   * linklayer - not originally passed via tc_ratespec, but incorporated
>     in table. HTB temporarily lost functionality when it stopped using
>     table. Later passed via ratespec, or inferred from table analysis
>     for old iproute2.
>   * mpu - always passed via tc_ratespec, but ignored by kernel.
>     Incorporated in table. HTB lost functionality when it stopped using
>     table.
> 
> ("always" meaning "since iproute2 first had the parameter").
> 
> So this is a tad different from the other two - those were making the 
> kernel act on something it previously acted on. This makes it act on 
> something it's always been given, but never acted on. But it restores 
> iproute2+kernel system functionality with no userspace change.

I see, thanks for the explanation! I think it's worth adding this
analysis to the commit message, please repost.