Re: Long delay in freeing skbs

[Tony Battersby <tonyb@cybernetics.com>]

On 3/9/26 17:07, Eric Dumazet wrote:
> On Mon, Mar 9, 2026 at 10:00 PM Tony Battersby <tonyb@cybernetics.com> wrote:
>> I have some out-of-tree code that was broken by commit e20dfbad8aab
>> ("net: fix napi_consume_skb() with alien skbs") in kernel 6.19.  I
>> retested with 7.0-rc3 with the same results.  I'm not sure if the change
>> in behavior that I am seeing is expected or if it is a bug, so I thought
>> I would ask.  Omitting irrelevant details, my kernel code does the
>> following:
>>
>> 1) allocate a buffer
>> 2) perform some network I/O using the buffer (cmd over iscsi_tcp)
>> 3) wait for the I/O to complete
>> 4) wait for the buffer page refcounts to drop back to their values for
>> idle I/O
>> 5) reuse the buffer for more I/O
>>
>> Step 4 is necessary in this case due to some of those irrelevant details
>> that I omitted, and that is where it trips up.  Commit e20dfbad8aab
>> seems to keep the page refcounts elevated long after the I/O has
>> completed (hours or longer), presumably because the deferred skb free
>> isn't happening for a long time.  So:
>>
>> 1) Is this long delay expected, or is this a bug?
>>
>> 2) If the delay is expected, is there a way for me to force the network
>> system to process the deferred skb frees on request?  e.g. write to a
>> file in /sys, or call a kernel function to flush the deferred frees?
>>
>> Worst case is that I can redesign my code to kfree() the buffer if it is
>> busy and allocate a new one, and let the old buffer be freed
>> asynchronously when the skb is freed at some indeterminate time in the
>> future.
>>
>> Thanks,
>> Tony Battersby
>
> If you are using zero copy, please look at:
>
> Maybe you should make sure your code is compatible with it.
>
> commit 0943404b1f3b178e1e54386dadcbf4f2729c7762
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Mon Feb 16 19:36:53 2026 +0000
>
>     net: do not delay zero-copy skbs in skb_attempt_defer_free()
>
>     After the blamed commit, TCP tx zero copy notifications could be
>     arbitrarily delayed and cause regressions in applications waiting
>     for them.
>
The I/O is being sent by a userspace program via the SCSI generic driver
(drivers/scsi/sg.c) over iSCSI (drivers/scsi/iscsi_tcp.c).  I don't see
any mention of zero copy in iscsi_tcp.c.

Tony