On 5/31/24 5:01 PM, Gabriel Krisman Bertazi wrote: > Jens Axboe <axboe@xxxxxxxxx> writes: > >> On 5/31/24 3:12 PM, Gabriel Krisman Bertazi wrote: >>> move_addr_to_kernel can fail, like if the user provides a bad sockaddr >>> pointer. In this case where the failure happens on ->prep() we don't >>> have a chance to clean the request later, so handle it here. >> >> Hmm, that should still get freed in the cleanup path? It'll eventually >> go on the compl_reqs list, and it has REQ_F_ASYNC_DATA set. Yes it'll >> be slower than the recycling it, but that should not matter as it's >> an erred request. > > Hm right. I actually managed to reproduce some kind of memory > exhaustion yesterday that I thought was fixed by this patch. But I see > your point and I'm failing to trigger it today. > > Please disregard this patch. I'll look further to figure out what I did > there. Maybe enable KMEMLEAK? It's pretty handy for testing. If there is a leak there, you should be able to reliably get info by doing: # ./reproducer (should be easy, just bogus addr) # echo scan > /sys/kernel/debug/kmemleak # sleep 5 # echo scan > /sys/kernel/debug/kmemleak -- Jens Axboe
