[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d93e69d0-8145-40ac-8afc-f1e8ccbe2052@huaweicloud.com>
Date: Tue, 6 May 2025 10:25:06 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: Jan Kara <jack@...e.cz>, Matthew Wilcox <willy@...radead.org>
Cc: Liebes Wang <wanghaichi0403@...il.com>, ojaswin@...ux.ibm.com,
Theodore Ts'o <tytso@....edu>, linux-fsdevel@...r.kernel.org,
syzkaller@...glegroups.com, Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: kernel BUG in zero_user_segments
On 2025/5/1 19:19, Jan Kara wrote:
> On Wed 30-04-25 04:14:32, Matthew Wilcox wrote:
>> On Tue, Apr 29, 2025 at 03:55:18PM +0800, Zhang Yi wrote:
>>> After debugging, I found that this problem is caused by punching a hole
>>> with an offset variable larger than max_end on a corrupted ext4 inode,
>>> whose i_size is larger than maxbyte. It will result in a negative length
>>> in the truncate_inode_partial_folio(), which will trigger this problem.
>>
>> It seems to me like we're asking for trouble when we allow an inode with
>> an i_size larger than max_end to be instantiated. There are probably
>> other places which assume it is smaller than max_end. We should probably
>> decline to create the bad inode in the first place?
>
> Indeed somewhat less quirky fix could be to make ext4_max_bitmap_size()
> return one block smaller limit. Something like:
>
> /* Compute how many blocks we can address by block tree */
> res += ppb;
> res += ppb * ppb;
> res += ((loff_t)ppb) * ppb * ppb;
> + /*
> + * Hole punching assumes it can map the block past end of hole to
> + * tree offsets
> + */
> + res -= 1;
> /* Compute how many metadata blocks are needed */
> meta_blocks = 1;
> meta_blocks += 1 + ppb;
>
> The slight caveat is that in theory there could be filesystems out there
> with so large files and then we'd stop allowing access to such files. But I
> guess the chances are so low that it's probably worth trying.
>
Hmm, I suppose this approach could pose some risks to our legacy products,
and it makes me feel uneasy. Personally, I am more inclined toward the
current solution, unless we decide to fix the ext4_ind_remove_space()
directly. :)
Thanks,
Yi.
Powered by blists - more mailing lists