netdev - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250617083842.GA417272@maili.marvell.com>
Date: Tue, 17 Jun 2025 14:08:42 +0530
From: Ratheesh Kannoth <rkannoth@...vell.com>
To: Yunsheng Lin <linyunsheng@...wei.com>
CC: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>
Subject: Re: [RFC]Page pool buffers stuck in App's socket queue

On 2025-06-17 at 12:03:41, Yunsheng Lin (linyunsheng@...wei.com) wrote:
> > 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 ?
>
> I would say the above is kind of working around the problem.
> It would be good to fix the Apps or fix the page_pool.
>
> > 2. Could you suggest a better way ?
>
> For fixing the page_pool part, I would be suggesting to keep track
> of all the inflight pages and detach those pages from page_pool when
> page_pool_destroy() is called, the tracking part was [1], unfortunately
> the maintainers seemed to choose an easy way instead of a long term
> direction, see [2].
>
> 1. https://lore.kernel.org/all/20250307092356.638242-1-linyunsheng@huawei.com/
> 2. https://lore.kernel.org/all/20250409-page-pool-track-dma-v9-0-6a9ef2e0cba8@redhat.com/

i think, both issues are different. Above links, fixes late DMA unmap issue. In my case,
buffers do not return at all. So some entity should purge those socket queues which are not getting
processed. App modification would be difficult as customer may use opensource Apps/third party apps.

Buffers are stuck in socket queue. And we need to free them. Page pool infra tracking socket queue and
process information would be an over kill ? And packets in socket queue of a process, being freed from page pool wont
work well. (That app could be killed later, causing skbs to be freed. or we dont know whether App processing socket queue
is slow).

I was thinking of extending /proc/net/raw and /proc/net/raw6 OR creating similar proc entries; which
can show "pid and timestamp of first skb in the queue" etc. And a .proc_write() function to purge a
specifc socket queue. Using these, customer can decide which queue is stuck and purge manualy (thru some script) after
netdevice down/up.