Re: [f2fs-dev] Use of FGP_NOFS in f2fs

On 6/29/26 11:54, Matthew Wilcox wrote:
> [Adding Jan Kara; retaining whole message for context]
> 
> On Mon, Jun 29, 2026 at 09:39:25AM +0800, Chao Yu wrote:
>> On 6/26/26 17:30, Jiucheng Xu wrote:
>>>
>>>
>>> On 6/25/2026 3:17 AM, Matthew Wilcox wrote:
>>>> [ EXTERNAL EMAIL ]
>>>>
>>>> Hi Jiucheng,
>>>>
>>>> I am trying to remove FGP_NOFS from the kernel and the last remaining

Matthew,

What about this two steps proposal?

1. Use memalloc_nofs_save() and memalloc_nofs_restore() to replace FGP_NOFS
or GFP_NOFS, then you can handle FGP_NOFS and GFP_NOFS as you planed.
2. then I can propose another RFC patch to drop memalloc_nofs*. I guess it
needs some time to test since I suspect there may be potential deadlock due
to complicated lock implementation...

Thanks,

>>>> user was added by you last year in commit 2308de27c03d.  I'm trying to
>>>> understand why.  Did you see an actual problem if you do not use it,
>>>> or was it theoretical?  The commit message says "to avoid potential
>>>> deadlock issues", but it's not clear to me whether you know they are
>>>> there, or only think they are there.
>>>>
>>>> I'd really like to understand what the issues are as the normal issues
>>>> which make calling into the filesystem (holding another folio locked,
>>>> holding a mutex relied upon by reclaim) don't seem to be present.
>>>> So if there is something, I'm not sure what it is.
>>> Hi Matthew,
>>>
>>> The FGP_NOFS flag was suggested by Chao and not adding it might lead to deadlock issues.
>>>
>>> @Chao could you explain this for Matthew?
>>
>> Hi Matthew, Jiucheng,
>>
>> IIRC, for normal path from write -> write_begin, it seems fine since there is
>> no f2fs-specified mutex or other folio lock in the path, but I was worried about
>> quota path when I suggested to keep GFP_NOFS flag, as the lock race condition
>> is quite complicated there: f2fs internal lock vs quota system lock vs folio lock...
>>
>> I searched the commits and found this:
>>
>> Commit 02117b8ae9c0 ("f2fs: Set GF_NOFS in read_cache_page_gfp while doing
>> f2fs_quota_read")
>>
>> In this case, f2fs_quota_read() was calling read_mapping_page(), which allowed
>> GFP_FS allocations. This triggered the following deadlock:
>>
>>     Thread 1 (User Open/Write)
>>     - do_sys_open
>>      - vfs_open
>>       - dquot_file_open
>>        - dquot_initialize
>>         - dqget
>>          - dquot_acquire
>>           : locks &dqopt->dqio_mutex (VFS Quota Mutex)
>>           - qtree_read_dquot
>>            - f2fs_quota_read
>>             - read_mapping_page (GFP_KERNEL / allows GFP_FS)
>>              - __alloc_pages_nodemask
>>               - try_to_free_pages (Direct Reclaim)
>>                - prune_icache_sb
>>                 - evict
>>                  - f2fs_evict_inode
>>                   - dquot_drop
>>                    - dqput
>>                     - dquot_commit
>>                      : tries to lock &dqopt->dqio_mutex again
>>                      ==> DEADLOCK (waiting for itself)
>>
>> It may trigger deadlock in f2fs_quota_write() as the same way in f2fs_quota_read()
>> path? let me know if I'm missing anything.
>>
>> Are memalloc_nofs_save() and memalloc_nofs_restore() recommended for such case?
>> any suggestions?
> 
> In general, yes, memalloc_nofs_save() after locking dqio_mutex sounds like
> the right idea to me.  I'd want to familiarise myself more thoroughly
> with the code before making a firm recommendation, and it's probably
> quicker to just ask Jan ;-)



_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel