Re: [PATCH 01/13] btrfs: fix missed extent on fsync after dropping extent maps

[Anand Jain <anand.jain@oracle.com>]

On 20/09/2022 18:27, Filipe Manana wrote:
> On Tue, Sep 20, 2022 at 11:19 AM Anand Jain <anand.jain@oracle.com> wrote:
>>
>> On 19/09/2022 22:06, fdmanana@kernel.org wrote:
>>> From: Filipe Manana <fdmanana@suse.com>
>>>
>>> When dropping extent maps for a range, through btrfs_drop_extent_cache(),
>>> if we find an extent map that starts before our target range and/or ends
>>> before the target range, and we are not able to allocate extent maps for
>>> splitting that extent map, then we don't fail and simply remove the entire
>>> extent map from the inode's extent map tree.
>>
>>
>>> +             if (testend && em->start + em->len > start + len)
>>
>>    %len comes from
>>
>>          u64 len = end - start + 1;
>>
>>    IMO >= was correct here; because including %start + %len is already
>>    after the range as in the original code. No?
> 
> No, > is the correct thing to do. It only matters if the extent map's
> range ends after our range.

  Got it.

> Try the math with a simple example, with a start of 0 and a length of
> 4096 (end offset if 4095), and you'll see.

Thanks.


> Thanks.
> 
>>
>>> +                     ends_after_range = true;
>>>                flags = em->flags;
>>>                gen = em->generation;
>>>                if (skip_pinned && test_bit(EXTENT_FLAG_PINNED, &em->flags)) {
>>> -                     if (testend && em->start + em->len >= start + len) {
>>> +                     if (ends_after_range) {
>>>                                free_extent_map(em);
>>>                                write_unlock(&em_tree->lock);
>>>                                break;