linux-kernel - Re: [RFC PATCH net-next v2] ppp: use IFF_NO

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: <87a5aaxcns.fsf@toke.dk>
Date: Tue, 25 Feb 2025 16:32:55 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Qingfang Deng <dqfext@...il.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>, Michal Ostrowski <mostrows@...thlink.net>, James
 Chapman <jchapman@...alix.com>, Simon Horman <horms@...nel.org>,
 linux-ppp@...r.kernel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next v2] ppp: use IFF_NO_QUEUE in virtual
 interfaces

Qingfang Deng <dqfext@...il.com> writes:

> For PPPoE, PPTP, and PPPoL2TP, the start_xmit() function directly
> forwards packets to the underlying network stack and never returns
> anything other than 1. So these interfaces do not require a qdisc,
> and the IFF_NO_QUEUE flag should be set.
>
> Introduces a direct_xmit flag in struct ppp_channel to indicate when
> IFF_NO_QUEUE should be applied. The flag is set in ppp_connect_channel()
> for relevant protocols.
>
> Signed-off-by: Qingfang Deng <dqfext@...il.com>
> ---
> RFC v1 -> v2: Conditionally set the flag for relevant protocols.
>
> I'm not sure if ppp_connect_channel can be invoked while the device
> is still up. As a qdisc is attached in dev_activate() called by
> dev_open(), setting the IFF_NO_QUEUE flag on a running device will have
> no effect.

No idea either. I don't think there's anything on the kernel side
preventing it, but it would make the most sense if the interface isn't
brought up before the underlying transport is established?

Anyway, assuming this is the case, I think this approach is better, so:

Reviewed-by: Toke Høiland-Jørgensen <toke@...hat.com>