The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Qingfang Deng <qingfang.deng@linux.dev>
Cc: Guillaume Nault <gnault@redhat.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Kees Cook <kees@kernel.org>,
	Asim Viladi Oglu Manizada <manizada@pm.me>,
	Eric Woudstra <ericwouds@gmail.com>, Felix Fietkau <nbd@nbd.name>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Mackerras <paulus@ozlabs.org>,
	Michal Ostrowski <mostrows@gmail.com>
Subject: Re: [RFC net-next] pppoe: remove session socket receive support
Date: Sun, 9 Aug 2026 16:58:36 +0200	[thread overview]
Message-ID: <20260809145836.5pqf2rgf574fjlds@pali> (raw)
In-Reply-To: <20260806091626.231225-1-qingfang.deng@linux.dev>

Hello, I would like to point out that "no know open source
userspace implementation" does not have to mean that there cannot be
some closed source or not publicly available. But I agree that
probability is too low.

Anyway, could you describe what is this functionality (which is being
removed) doing? Or how to use it? From the code and description I have
not figure out how it is suppose to be used or for what kind of scenario
or use case can be it hypothetically used.

Would be nice to know what exactly is being removing and what userspace
applications cannot do after applying this change.

On Thursday 06 August 2026 17:16:24 Qingfang Deng wrote:
> No known userspace PPPoE implementation reads from an AF_PPPOX
> socket. In particular, pppd uses the socket only to establish a
> session and obtain a generic PPP channel with PPPIOCGCHAN. Packet I/O
> then uses /dev/ppp.
> 
> Before this change, packets received before PPPIOCGCHAN set
> PPPOX_BOUND were queued on sk_receive_queue. Since no known
> implementation consumed them, they remained there until socket
> destruction and unnecessarily consumed memory.
> 
> Pass every matched session packet directly to ppp_input(). On a
> successful connect, the channel is registered before the socket lock
> is released. Generic PPP can therefore queue early packets until
> userspace attaches /dev/ppp, preserving packets that arrive between
> connect() and PPPIOCGCHAN.
> 
> Replace pppoe_recvmsg() with sock_no_recvmsg(). Like PPTP, omit the
> poll callback because the socket no longer receives packets. Remove
> pppoe_destruct() because the receive queue is no longer used.
> 
> Assisted-by: Codex:GPT-5.6
> Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
> ---
>  drivers/net/ppp/pppoe.c | 50 ++---------------------------------------
>  1 file changed, 2 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> index bf7414b46a26..e3d425943c76 100644
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
> @@ -350,23 +350,9 @@ static int pppoe_rcv_core(struct sock *sk, struct sk_buff *skb)
>  {
>  	struct pppox_sock *po = pppox_sk(sk);
>  
> -	/* Backlog receive. Semantics of backlog rcv preclude any code from
> -	 * executing in lock_sock()/release_sock() bounds; meaning sk->sk_state
> -	 * can't change.
> -	 */
> -
> -	if (sk->sk_state & PPPOX_BOUND) {
> -		ppp_input(&po->chan, skb);
> -	} else {
> -		if (sock_queue_rcv_skb(sk, skb))
> -			goto abort_kfree;
> -	}
> +	ppp_input(&po->chan, skb);
>  
>  	return NET_RX_SUCCESS;
> -
> -abort_kfree:
> -	kfree_skb(skb);
> -	return NET_RX_DROP;
>  }
>  
>  /************************************************************************
> @@ -498,11 +484,6 @@ static struct proto pppoe_sk_proto __read_mostly = {
>  	.obj_size = sizeof(struct pppox_sock),
>  };
>  
> -static void pppoe_destruct(struct sock *sk)
> -{
> -	skb_queue_purge(&sk->sk_receive_queue);
> -}
> -
>  /***********************************************************************
>   *
>   * Initialize a new struct sock.
> @@ -523,7 +504,6 @@ static int pppoe_create(struct net *net, struct socket *sock, int kern)
>  	sock->ops	= &pppoe_ops;
>  
>  	sk->sk_backlog_rcv	= pppoe_rcv_core;
> -	sk->sk_destruct		= pppoe_destruct;
>  	sk->sk_state		= PPPOX_NONE;
>  	sk->sk_type		= SOCK_STREAM;
>  	sk->sk_family		= PF_PPPOX;
> @@ -921,31 +901,6 @@ static const struct ppp_channel_ops pppoe_chan_ops = {
>  	.fill_forward_path = pppoe_fill_forward_path,
>  };
>  
> -static int pppoe_recvmsg(struct socket *sock, struct msghdr *m,
> -			 size_t total_len, int flags)
> -{
> -	struct sock *sk = sock->sk;
> -	struct sk_buff *skb;
> -	int error = 0;
> -
> -	if (sk->sk_state & PPPOX_BOUND)
> -		return -EIO;
> -
> -	skb = skb_recv_datagram(sk, flags, &error);
> -	if (!skb)
> -		return error;
> -
> -	total_len = min_t(size_t, total_len, skb->len);
> -	error = skb_copy_datagram_msg(skb, 0, m, total_len);
> -	if (error == 0) {
> -		consume_skb(skb);
> -		return total_len;
> -	}
> -
> -	kfree_skb(skb);
> -	return error;
> -}
> -
>  #ifdef CONFIG_PROC_FS
>  static int pppoe_seq_show(struct seq_file *seq, void *v)
>  {
> @@ -1046,11 +1001,10 @@ static const struct proto_ops pppoe_ops = {
>  	.socketpair	= sock_no_socketpair,
>  	.accept		= sock_no_accept,
>  	.getname	= pppoe_getname,
> -	.poll		= datagram_poll,
>  	.listen		= sock_no_listen,
>  	.shutdown	= sock_no_shutdown,
>  	.sendmsg	= pppoe_sendmsg,
> -	.recvmsg	= pppoe_recvmsg,
> +	.recvmsg	= sock_no_recvmsg,
>  	.mmap		= sock_no_mmap,
>  	.ioctl		= pppox_ioctl,
>  #ifdef CONFIG_COMPAT
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-08-09 14:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06  9:16 [RFC net-next] pppoe: remove session socket receive support Qingfang Deng
2026-08-09 14:58 ` Pali Rohár [this message]
2026-08-09 16:17   ` Qingfang Deng
2026-08-09 22:59     ` Pali Rohár
2026-08-10  2:28       ` Qingfang Deng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260809145836.5pqf2rgf574fjlds@pali \
    --to=pali@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ericwouds@gmail.com \
    --cc=gnault@redhat.com \
    --cc=kees@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manizada@pm.me \
    --cc=mostrows@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paulus@ozlabs.org \
    --cc=qingfang.deng@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox