linux-kernel - Re: [PATCH net-next v3] ppp: enable TX scatter-gather

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: <CALW65jZVB=+Q89Q7CjfngUyski1F5dCfbdGZdxe3no76Stv0_A@mail.gmail.com>
Date: Wed, 28 Jan 2026 17:19:54 +0800
From: Qingfang Deng <dqfext@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, linux-ppp@...r.kernel.org, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCH net-next v3] ppp: enable TX scatter-gather

On Wed, Jan 28, 2026 at 5:05 PM Paolo Abeni <pabeni@...hat.com> wrote:
> > On Tue, Jan 27, 2026 at 8:34 PM Paolo Abeni <pabeni@...hat.com> wrote:
> >> I spent a little time trying to understanding the logic here and I think
> >> that enabling features depending on IFF_NO_QUEUE is fragile at best.
> >>
> >> It looks like that the IFF_NO_QUEUE bit is an inconsistent state for
> >> multilink devices using different type of channels.
> >> Moreover the user-space could attaching a qdisc to the ppp device after
> >> channel initialization.
> >>
> >> Instead you could always expose the features and linearize as needed
> >> when transmitting on !direct_xmit channel; no need to touch the
> >> individual channel implementation, you could do such check before
> >> calling the ops->start_xmit() calls (possibly creating a new
> >> wrapper/helper for that).
> >
> > Attaching a new qdisc won't clear the IFF_NO_QUEUE bit. (The flag
> > means the interface _can_ run without a qdisc).
>
> Correct.
>
> > As for multilink devices, one is not supposed to bundle channels with
> > inconsistent direct_xmit (for example, mix ppp_synctty with pptp) and
> > expect better results. But as the driver does not reject that, I may
> > add a skb_linearize() to ppp_mp_explode(), or add a check for
> > SC_MULTILINK flag in ppp_fix_features().
> >
> > What do you think?
>
> AFAICS nothing prevent the user-space from creating multiple channels
> with different type even without SC_MULTILINK, so ppp_fix_features()
> should likely check the whole channel list.
>
> Also packets could be being transmitted after channel creation and
> before the features are updated, so ppp_start_xmit could observe
> transient mismatching features and skb layout.
>
> It's not a matter of bad performances: if skb is not linear and the
> channel start_xmit assumes linear layout bad things will happen. I think
> that even with a correct ppp_fix_features() you will need to check for
> linearization in the datapath (as an unlikely condition).

Fair enough. I'll send v4 with your proposed changes.

Regards,
Qingfang