On Thu, Jan 04, 2024 at 09:17:16PM +0000, Matthew Wilcox wrote: > This is primarily a _FILESYSTEM_ track topic. All the work has already > been done on the MM side; the FS people need to do their part. It could > be a joint session, but I'm not sure there's much for the MM people > to say. > > There are situations where we need to allocate memory, but cannot call > into the filesystem to free memory. Generally this is because we're > holding a lock or we've started a transaction, and attempting to write > out dirty folios to reclaim memory would result in a deadlock. > > The old way to solve this problem is to specify GFP_NOFS when allocating > memory. This conveys little information about what is being protected > against, and so it is hard to know when it might be safe to remove. > It's also a reflex -- many filesystem authors use GFP_NOFS by default > even when they could use GFP_KERNEL because there's no risk of deadlock. Another thing that needs to be considered: GFP_NOFS has been used to avoid lockdep false positives due to GFP_KERNEL allocations also being used as scoped GFP_NOFS allocations via different call chains. That is, if a code path does a GFP_KERNEL allocation by default, lockdep will track this as a "reclaim allowed" allocation context. If that same code is then executed from a scoped NOFS context (e.g. inside a transaction context), then lockdep will see it as a "no reclaim allowed" allocation context. The problem then arises when the next GFP_KERNEL allocation occurs, the code enters direct reclaim, grabs a filesystem lock and lockdep then throws out a warning that filesystem locks are being taken in an allocation context that doesn't allow reclaim to take filesystem locks. These are typically false positives. Prior to __GFP_NOLOCKDEP existing, we used GFP_NOFS unconditionally in these shared context paths to avoid lockdep from seeing a GFP_KERNEL allocation context from this allocation path. Now that we are getting rid of GFP_NOFS and replacing these instances with GFP_KERNEL and scoped constraints, we're removing the anti-lockdep false positive mechanism. IOWs, we have to replace GFP_NOFS with GFP_KERNEL | __GFP_NOLOCKDEP in these cases to prevent false positive reclaim vs lock inversion detections. There's at least a dozen of these cases in XFS and we generally know where they are, but this will likely be an ongoing issue for filesystems as we switch over to using scoped memory allocation contexts. I'm not sure there's a good solution to this. However, we need to make sure people are aware that GFP_NOFS will need to be converted to GFP_KERNEL | __GFP_NOLOCKDEP for allocations that can occur in mixed contexts. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
