Re: [PATCH v3 4/5] btrfs: change the timing for qgroup reserved space for ordered extents to fix reserved space leak

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2020/6/16 下午11:17, David Sterba wrote:
> On Wed, Jun 10, 2020 at 09:04:43AM +0800, Qu Wenruo wrote:
>> [BUG]
>> The following simple workload from fsstress can lead to qgroup reserved
>> data space leakage:
>>   0/0: creat f0 x:0 0 0
>>   0/0: creat add id=0,parent=-1
>>   0/1: write f0[259 1 0 0 0 0] [600030,27288] 0
>>   0/4: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 64 627318] return 25, fallback to stat()
>>   0/4: dwrite f0[259 1 0 0 64 627318] [610304,106496] 0
>>
>> This would cause btrfs qgroup to leak 20480 bytes for data reserved
>> space.
>> If btrfs qgroup limit is enabled, such leakage can lead to unexpected
>> early EDQUOT and unusable space.
>>
>> [CAUSE]
>> When doing direct IO, kernel will try to writeback existing buffered
>> page cache, then invalidate them:
>>   iomap_dio_rw()
>>   |- filemap_write_and_wait_range();
>>   |- invalidate_inode_pages2_range();
> 
> As the dio-iomap got reverted, can you please update the changelog and
> review if the changes are still valid? The whole patchset is in
> misc-next so I'll update the changelog in place if needed, or replace
> the whole patchset. Thanks.
> 
After reviewing the reverted code, the change is still valid here.
As the filemap_write_and_wait_range() and
invalidate_inode_pages2_range() are still in generic_file_direct_write()
call.

And without the timing change patches, the safenet can still detect the
leakage, and my existing seeds reproduce the same problem.
So we still need the series.

For the changelog update, I'll send out the v4 patches, but the
changelog modification is pretty small.
I guess only the first and this patch needs some small modification.
(the first for some words change, while for this, only the function name
needs to be modified)

Thanks,
Qu

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux