linux-kernel - Re: [RFC]Page pool buffers stuck in App's socket queue

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: <20250618072845.GB824830@maili.marvell.com>
Date: Wed, 18 Jun 2025 12:58:45 +0530
From: Ratheesh Kannoth <rkannoth@...vell.com>
To: Mina Almasry <almasrymina@...gle.com>
CC: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <linyunsheng@...wei.com>
Subject: Re: [RFC]Page pool buffers stuck in App's socket queue

On 2025-06-18 at 02:30:04, Mina Almasry (almasrymina@...gle.com) wrote:
> >
> > Those packets will never gets processed. And if customer does a interface down/up, page pool
> > warnings will be shown in the console.
> >
>
> Right, I have a few recommendations here:
>
> 1. Check that commit be0096676e23 ("net: page_pool: mute the periodic
> warning for visible page pools") is in your kernel. That mutes
> warnings for visible page_pools.

Thanks. netdevice is not gettting unregistered in octeontx2 driver while interface
is brought down; but page pool is destroyed.

>
> 2. Fix the application to not leave behind these RAW6 socket data.
> Either processing the data incoming in the socket or closing the
> socket itself would be sufficient.

Customer is using opensource ping (from iptutils). They run a
ping to an ipv4 address (ping 192.x.x.x -A &). Here the app opens both
RAW4 and RAW6 sockets. IPv6 router advertisement messages from the network
lands up in this RAW6 socket qeueue. And ping App never dequeue from this RAW6
socket queue. They want to avoid killing and starting the ping APP.
Customer creates  RAW6 socket with other Apps also (third party) and page pool
issues pops up there as well.  Ping App reproduction steps are shared to us;
so quoting the same.

>
> > Customer was asking us for a mechanism to drain these sockets, as they dont want to kill their Apps.
> > The proposal is to have debugfs which shows "pid  last_processed_skb_time  number_of_packets  socket_fd/inode_number"
> > for each raw6/raw4 sockets created in the system. and
> > any write to the debugfs (any specific command) will drain the socket.
> >
> > 1. Could you please comment on the proposal ?
>
> Oh boy. I don't think this would fly at all. The userspace simply
> closing the RAW6 socket would 'fix' the issue, unless I'm missing
> something.
>
> Having a roundabout debugfs entry that does the same thing that
> `close(socket_fd);` would do is going to be a very hard sell upstream.

>
> I think we could also mute the page_pool warning or make it less
> visible. The kernel usually doesn't warn when the userspace is leaking
> data.
>
> We could also do what Yunsheng suggests and actually disconnect the
> pages from the page_pool and let the page_pool clean up, but that may
> be a complicated change.
>
> Honsetly there are a lot of better solutions here than this debugfs file.
Thanks a lot !. Could you suggest some solutions. I will try to work on those.

>
> --
> Thanks,
> Mina