Re: [PATCH v2] btrfs: fix a possible race window when allocating new extent buffers

[Chris Mason <clm@meta.com>]

On 6/7/24 9:56 AM, David Sterba wrote:
> On Fri, Jun 07, 2024 at 01:57:38PM +0930, Qu Wenruo wrote:
>>
>>
>> 在 2024/6/7 04:57, David Sterba 写道:
>> [...]
>>>
>>> Thanks. I'll pick the patch to branch for the next pull request, the fix has
>>> survived enough testing and we should get it to stable without further delays.
>>> I've edited the subject and changelog a bit, the problem is really the folio
>>> private protection, it is a race window fix but that does not tell much what is
>>> the cause. I've also added the reproducer script from Chris.
>>>
>>
>> Mind to push the updated version to for-next?
> 
> Now updated, otherwise if you need to find it the branch is
> https://github.com/kdave/btrfs-devel/tree/misc-6.10 or it's in the
> linux-next source branch
> https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/log/?h=next-fixes
> 
>> I'd like to restart the test of larger metadata folios.
>> Ironically if we force larger metadata folios (one folio one metadata),
>> the race can also be solved, as now folio lock would kick in to prevent
>> the race.
> 
> Yeah, but this would be an accidental fix. If we didn't understand that
> the bug was in our implementation I'm guessing large folios would be
> blamed and this won't make finding the problem easier. We need to be
> sure that the easy page->folio conversion is solid. You can start
> testing it but the actual switch may take a release or two.

I was going to suggest that we wait a bit as well.  The new code is
holding up well to testing, and we're going to roll it to prod w/our 6.9
kernel, so it'll end up with lots of validation over the next 10 weeks
or so.

I'd definitely start on the large folios now, but also give the code we
have today a chance to soak before making the switch.

-chris