Re: Xen NIC driver have page_pool memory leaks

[Jesper Dangaard Brouer <hawk@kernel.org>]

On 25/03/2024 13.33, Paul Durrant wrote:
> On 25/03/2024 12:21, Jesper Dangaard Brouer wrote:
>> Hi Arthur,
>>
>> (Answer inlined below, which is custom on this mailing list)
>>
>> On 23/03/2024 14.23, Arthur Borsboom wrote:
>>> Hi Jesper,
>>>
>>> After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
>>> Linux are dumping kernel traces.
>>> It seems to be indirectly caused by the page pool memory leak
>>> mechanism, which is probably a good thing.
>>>
>>> I have created a bug report, but there is no response.
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=218618
>>>
>>> I am uncertain where and to whom I need to report this page leak.
>>> Can you help me get this issue fixed?
>>
>> I'm the page_pool maintainer, but as you say yourself in comment 2 then
>> since dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks") this
>> indicated there is a problem in the xen_netfront driver, which was
>> previously not visible.
>>
>> Cc'ing the "XEN NETWORK BACKEND DRIVER" maintainers, as this is a driver
>> bug.  What confuses me it that I cannot find any modules named
>> "xen_netfront" in the upstream tree.
>>
> 
> You should have tried '-' rather than '_' :-)
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c
> 

Looking at this driver, I think it is missing a call to 
skb_mark_for_recycle().

I'll will submit at patch for this, with details for stable maintainers.

As I think it dates back to v5.9 via commit 6c5aa6fc4def ("xen
networking: add basic XDP support for xen-netfront"). I think this
commit is missing a call to page_pool_release_page()
between v5.9 to v5.14, after which is should have used
skb_mark_for_recycle().

Since v6.6 the call page_pool_release_page() were removed (in
535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and
remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
'net-page_pool-remove-page_pool_release_page'")).

This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool:
catch page_pool memory leaks").

--Jesper