Re: [PATCH] btrfs: reorganize error handling in btrfs_tree_mod_log_insert_key

[Qu Wenruo <wqu@suse.com>]

在 2025/9/29 18:02, Filipe Manana 写道:
> On Mon, Sep 29, 2025 at 9:29 AM Sun YangKai <sunk67188@gmail.com> wrote:
>>
>>>> -   ret = tree_mod_log_insert(eb->fs_info, tm);
>>>> -out_unlock:
>>>> +   /* Deal with allocation error. */
>>>> +   if (tm)
>>>> +           ret = tree_mod_log_insert(eb->fs_info, tm);
>>>
>>> Sorry, I don't think this is really that better.
>>>
>>> In fact I'm wondering why we don't delay the allocation after
>>> tree_mod_dont_log()?
>>
>> That's what I want to do at first. However, after looking further into
>> tree_mod_dont_log(), I found that it trys to get the tree_mod_log_lock. I'm
>> not sure if it's better or worse to do the allocation things after getting the
>> lock.
> 
> You can't do a GFP_NOFS allocation after acquiring a rw lock... The
> only allocation that can be done is a GFP_ATOMIC in that context, and
> we want to avoid them.

You're both right. Forgot it's a rwlock.

There is no better solution, I guess it's the best solution for now.

Reviewed-by: Qu Wenruo <wqu@suse.com>

Thanks,
Qu
> 
>>
>>>
>>> That would be way more straightforward.
>>>
>>> Thanks,
>>> Qu
>>>
>>>> +   else
>>>> +           ret = -ENOMEM;
>>>> +
>>>>
>>
>> Thanks,
>> Sun YangKai
>>
>>
>>
>>
>>