On Mon, 17 Apr 2023 20:42:39 +0200 Lorenzo Bianconi wrote: > > Is drgn available for your target? You could try to scan the pages on > > the system and see if you can find what's still pointing to the page > > pool (assuming they are indeed leaked and not returned to the page > > allocator without releasing :() > > I will test it but since setting sysctl_skb_defer_max to 0 fixes the issue, > I think the pages are still properly linked to the pool, they are just not > returned to it. I proved it using the other patch I posted [0] where I can see > the counter of returned pages incrementing from time to time (in a very long > time slot..). If it's that then I'm with Eric. There are many ways to keep the pages in use, no point working around one of them and not the rest :( > Unrelated to this issue, but debugging it I think a found a page_pool leak in > skb_condense() [1] where we can reallocate the skb data using kmalloc for a > page_pool recycled skb. I don't see a problem having pp_recycle = 1 and head in slab is legal. pp_recycle just means that *if* a page is from the page pool we own the recycling reference. A page from slab will not be treated as a PP page cause it doesn't have pp_magic set to the correct pattern.
