Re: [PATCH] mm,page_owner: don't remove GFP flags in add_stack_record_to_list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 29, 2024 at 09:59:43AM +0200, Vlastimil Babka wrote:
> On 4/29/24 7:47 AM, Christoph Hellwig wrote:
> > This loses flags like GFP_NOFS and GFP_NOIO that are important to avoid
> > deadlocks as well as GFP_NOLOCKDEP that otherwise generates lockdep false
> > positives.
> 
> GFP_NOFS and GFP_NOIO translate to GFP_KERNEL without __GFP_FS/__GFP_IO so I
> don't see how this patch would have helped with those.
> __GFP_NOLOCKDEP is likely the actual issue and stackdepot solved it like this:
> 
> https://lore.kernel.org/linux-xfs/20240418141133.22950-1-ryabinin.a.a@xxxxxxxxx/
>
> So we could just do the same here.

Yes, it is __GFP_NOLOCKDEP that is the issue here, but
cargo-cult-copying of that stackdepot fix is just whack-a-mole bug
fixing without addressing the technical debt that got us here in the
first place. Has anyone else bothered to look to see if kmemleak has
the same problem?

If anyone bothered to do an audit, they would see that
gfp_kmemleak_mask() handles the reclaim context masks correctly.
Further, it adds NOWARN, NOMEMALLOC and
NORETRY, which means the debug code is silent when it fails, it
doesn't deplete emergency reserves and doesn't bog down retrying
forever when there are sustained low memory situations.

This also points out that the page-owner/stackdepot code that strips
GFP_ZONEMASK is completely redundant. Doing:

	gfp_flags &= GFP_KERNEL|GFP_ATOMIC|__GFP_NOLOCKDEP;

strips everything but __GFP_RECLAIM, __GFP_FS, __GFP_IO,
__GFP_HIGH and __GFP_NOLOCKDEP. This already strips the zonemask
info, so there's no need to do it explicitly.

IOWs, the right way to fix this set of problems is to lift
gfp_kmemleak_mask() to include/linux/gfp.h and then use it across
all these nested allocations that occur behind the public
memory allocation API.

I've got a patchset under test at the moment that does this....

-Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux