kernel/drivers/net/ppp/pppoe.c, branch linux-6.18.y

pppoe: drop sock reference counting on fast path

2025-08-29T20:39:54Z

Now that PPPoE sockets are freed via RCU (SOCK_RCU_FREE), it is no longer necessary to take a reference count when looking up sockets on the receive path. Readers are protected by RCU, so the socket memory remains valid until after a grace period. Convert fast-path lookups to avoid refcounting: - Replace get_item() and sk_receive_skb() in pppoe_rcv() with __get_item() and __sk_receive_skb(). - Rework get_item_by_addr() into __get_item_by_addr() (no refcount and move RCU lock into pppoe_ioctl) - Remove unnecessary sock_put() calls. This avoids cacheline bouncing from atomic reference counting and improves performance on the receive fast path. Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250828012018.15922-2-dqfext@gmail.com Signed-off-by: Jakub Kicinski

pppoe: remove rwlock usage

2025-08-29T20:39:53Z

Like ppp_generic.c, convert the PPPoE socket hash table to use RCU for lookups and a spinlock for updates. This removes rwlock usage and allows lockless readers on the fast path. - Mark hash table and list pointers as __rcu. - Use spin_lock() to protect writers. - Readers use rcu_dereference() under rcu_read_lock(). All known callers of get_item() already hold the RCU read lock, so no additional locking is needed. - get_item() now uses refcount_inc_not_zero() instead of sock_hold() to safely take a reference. This prevents crashes if a socket is already in the process of being freed (sk_refcnt == 0). - Set SOCK_RCU_FREE to defer socket freeing until after an RCU grace period. - Move skb_queue_purge() into sk_destruct callback to ensure purge happens after an RCU grace period. Signed-off-by: Qingfang Deng Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250828012018.15922-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski

pppoe: drop PACKET_OTHERHOST before skb_share_check()

2025-06-24T23:37:02Z

Align with ip_rcv() by dropping PACKET_OTHERHOST packets before calling skb_share_check(). This avoids unnecessary skb processing for packets that will be discarded anyway. Signed-off-by: Qingfang Deng Acked-by: Guillaume Nault Link: https://patch.msgid.link/20250623033431.408810-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski

ppp: use IFF_NO_QUEUE in virtual interfaces

2025-03-05T01:11:17Z

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. While at it, remove the usused latency member from struct ppp_channel. Signed-off-by: Qingfang Deng Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250301135517.695809-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski

pppoe: Fix memory leak in pppoe_sendmsg()

2024-02-15T15:50:32Z

syzbot reports a memory leak in pppoe_sendmsg [1]. The problem is in the pppoe_recvmsg() function that handles errors in the wrong order. For the skb_recv_datagram() function, check the pointer to skb for NULL first, and then check the 'error' variable, because the skb_recv_datagram() function can set 'error' to -EAGAIN in a loop but return a correct pointer to socket buffer after a number of attempts, though 'error' remains set to -EAGAIN. skb_recv_datagram __skb_recv_datagram // Loop. if (err == -EAGAIN) then // go to the next loop iteration __skb_try_recv_datagram // if (skb != NULL) then return 'skb' // else if a signal is received then // return -EAGAIN Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. Link: https://syzkaller.appspot.com/bug?extid=6bdfd184eac7709e5cc9 [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+6bdfd184eac7709e5cc9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6bdfd184eac7709e5cc9 Signed-off-by: Gavrilov Ilia Reviewed-by: Guillaume Nault Link: https://lore.kernel.org/r/20240214085814.3894917-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Jakub Kicinski

net: implement lockless SO_PRIORITY

2023-10-01T18:09:54Z

This is a followup of 8bf43be799d4 ("net: annotate data-races around sk->sk_priority"). sk->sk_priority can be read and written without holding the socket lock. Signed-off-by: Eric Dumazet Reviewed-by: Wenjia Zhang Signed-off-by: David S. Miller

net: ppp: Remove unnecessary (void*) conversions

2023-07-19T02:00:47Z

No need cast (void*) to (struct sock *). Signed-off-by: Wu Yunchuan Reviewed-by: Guillaume Nault Link: https://lore.kernel.org/r/20230717031115.54432-1-yunchuan@nfschina.com Signed-off-by: Jakub Kicinski

net/pppoe: make number of hash bits configurable

2023-05-17T12:03:45Z

When running large numbers of pppoe connections, a bucket size of 16 may be too small and 256 may be more appropriate. This sacrifices some RAM but should result in faster processing of incoming PPPoE frames. On our systems we run upwards of 150 PPPoE connections at any point in time, and we suspect we're starting to see the effects of this small number of buckets. The legal values according to pppoe.c is anything that when 8 is divided by that results in a modulo of 0, ie, 1, 2, 4 and 8. The size of the per-underlying-interface structure is: sizeof(rwlock_t) + sizeof(pppox_sock*) * PPPOE_HASH_SIZE. Assuming a 64-bit pointer this will result in just over a 2KiB structure for PPPOE_HASH_BITS=8, which will likely result in a 4KiB allocation, which for us at least is acceptable. Not sure what the minimum allocation size is, and thus if values of 1 and 2 truly make sense. Default results in historic sizing and behaviour. Signed-off-by: Jaco Kroon Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2022-05-19T18:23:59Z

drivers/net/ethernet/mellanox/mlx5/core/main.c b33886971dbc ("net/mlx5: Initialize flow steering during driver probe") 40379a0084c2 ("net/mlx5_fpga: Drop INNOVA TLS support") f2b41b32cde8 ("net/mlx5: Remove ipsec_ops function table") https://lore.kernel.org/all/20220519040345.6yrjromcdistu7vh@sx1/ 16d42d313350 ("net/mlx5: Drain fw_reset when removing device") 8324a02c342a ("net/mlx5: Add exit route when waiting for FW") https://lore.kernel.org/all/20220519114119.060ce014@canb.auug.org.au/ tools/testing/selftests/net/mptcp/mptcp_join.sh e274f7154008 ("selftests: mptcp: add subflow limits test-cases") b6e074e171bc ("selftests: mptcp: add infinite map testcase") 5ac1d2d63451 ("selftests: mptcp: Add tests for userspace PM type") https://lore.kernel.org/all/20220516111918.366d747f@canb.auug.org.au/ net/mptcp/options.c ba2c89e0ea74 ("mptcp: fix checksum byte order") 1e39e5a32ad7 ("mptcp: infinite mapping sending") ea66758c1795 ("tcp: allow MPTCP to update the announced window") https://lore.kernel.org/all/20220519115146.751c3a37@canb.auug.org.au/ net/mptcp/pm.c 95d686517884 ("mptcp: fix subflow accounting on close") 4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs") https://lore.kernel.org/all/20220516111435.72f35dca@canb.auug.org.au/ net/mptcp/subflow.c ae66fb2ba6c3 ("mptcp: Do TCP fallback on early DSS checksum failure") 0348c690ed37 ("mptcp: add the fallback check") f8d4bcacff3b ("mptcp: infinite mapping receiving") https://lore.kernel.org/all/20220519115837.380bb8d4@canb.auug.org.au/ Signed-off-by: Jakub Kicinski

net: fix dev_fill_forward_path with pppoe + bridge

2022-05-16T10:58:55Z

When calling dev_fill_forward_path on a pppoe device, the provided destination address is invalid. In order for the bridge fdb lookup to succeed, the pppoe code needs to update ctx->daddr to the correct value. Fix this by storing the address inside struct net_device_path_ctx Fixes: f6efc675c9dd ("net: ppp: resolve forwarding path for bridge pppoe devices") Signed-off-by: Felix Fietkau Signed-off-by: Pablo Neira Ayuso