public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: liubaolin <liubaolin12138@163.com>
To: Jan Kara <jack@suse.cz>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca, zhangshida@kylinos.cn,
	longzhi@sangfor.com.cn, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, Baolin Liu <liubaolin@kylinos.cn>
Subject: Re: [PATCH v1] ext4: fix a assertion failure due to ungranted bh dirting
Date: Fri, 11 Oct 2024 14:18:01 +0800	[thread overview]
Message-ID: <2635f3f9-86e1-4d09-ad40-4e02ac4447c5@163.com> (raw)
In-Reply-To: <20241010092923.r53povuflevzhxrw@quack3>

> Greetings,
> This problem is reproduced by our customer using their own testing tool “run_bug”.
> When I consulted with a client, the testing tool “run_bug” used a variety of background programs to benchmark 
> (including memory pressure, cpu pressure, file cycle manipulation, fsstress Stress testing tool, postmark program,and so on).
> The recurrence probability is relatively low.
> 
> In response to your query, in ext4_block_write_begin, the new state will be clear before get block, 
> and the bh that failed get_block will not be set to new.
> However, when the page size is greater than the block size, a page will contain multiple bh. 
> bh->b_this_page is a circular list for managing all bh on the same page.
> After get_block jumps out of the for loop, then bh->b_this_page is not processed by clear new in the for loop.
> So after calling ext4_journalled_zero_new_buffers,
> The ext4_journalled_zero_new_buffers function will determine all bh of the same page and call write_end_fn if they are in new state,
> get_block returns err's bh->b_this_page and circular list other unhandled bh if the state was previously set to new.
> Because bh not get access, the corresponding transaction is not placed in jh->b_transaction, resulting in a crash.
> 
> Therefore, the patch processing method I submit is to make unprocessed bh determines if it is in new state and get access.
> There is another way to handle the remaining bh clear_buffer_new that is not processed.
> I personally recommend get access this way, the impact is small. 
> Please guide the two processing methods, which one do you recommend?



在 2024/10/10 17:29, Jan Kara 写道:
> On Thu 10-10-24 10:58:55, Baolin Liu wrote:
>> From: Baolin Liu <liubaolin@kylinos.cn>
>>
>> Since the merge of commit 3910b513fcdf ("ext4: persist the new uptodate
>> buffers in ext4_journalled_zero_new_buffers"), a new assertion failure
>> occurred under a old kernel(ext3, data=journal, pagesize=64k) with
>> corresponding ported patches:
> ...
>> which was caused by bh dirting without calling
>> do_journal_get_write_access().
>>
>> In the loop for all bhs of a page in ext4_block_write_begin(),
>> when a err occurred, it will jump out of loop.
>> But that will leaves some bhs being processed and some not,
>> which will lead to the asserion failure in calling write_end_fn().
> 
> Thanks for the patch but I don't understand one thing here: For
> ext4_journalled_zero_new_buffers() to call write_end_fn() the buffer must
> have buffer_new flag set. That flag can get set only by ext4_get_block()
> function when it succeeds in which case we also call
> do_journal_get_write_access(). So how is it possible that buffer_new was
> set on a buffer on which we didn't call do_journal_get_write_access()? This
> indicates there may be some deeper problem hidden. How exactly did you
> trigger this problem?
> 
> 								Honza
> 
>>
>> To fixed that, get write access for the rest unprocessed bhs, just
>> as what write_end_fn do.
>>
>> Fixes: 3910b513fcdf ("ext4: persist the new uptodate buffers in ext4_journalled_zero_new_buffers")
>> Reported-and-tested-by: Zhi Long <longzhi@sangfor.com.cn>
>> Suggested-by: Shida Zhang <zhangshida@kylinos.cn>
>> Signed-off-by: Baolin Liu <liubaolin@kylinos.cn>
>> ---
>>   fs/ext4/inode.c | 17 ++++++++++++++++-
>>   1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>> index 54bdd4884fe6..a72f951288e4 100644
>> --- a/fs/ext4/inode.c
>> +++ b/fs/ext4/inode.c
>> @@ -1102,9 +1102,24 @@ int ext4_block_write_begin(handle_t *handle, struct folio *folio,
>>   			err = -EIO;
>>   	}
>>   	if (unlikely(err)) {
>> -		if (should_journal_data)
>> +		if (should_journal_data) {
>> +			if (bh != head || !block_start) {
>> +				do {
>> +					block_end = block_start + bh->b_size;
>> +
>> +					if (buffer_new(bh))
>> +						if (block_end > from && block_start < to)
>> +							do_journal_get_write_access(handle,
>> +										    inode, bh);
>> +
>> +					block_start = block_end;
>> +					bh = bh->b_this_page;
>> +				} while (bh != head);
>> +			}
>> +
>>   			ext4_journalled_zero_new_buffers(handle, inode, folio,
>>   							 from, to);
>> +		}
>>   		else
>>   			folio_zero_new_buffers(folio, from, to);
>>   	} else if (fscrypt_inode_uses_fs_layer_crypto(inode)) {
>> -- 
>> 2.39.2
>>


  reply	other threads:[~2024-10-11  6:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10  2:58 [PATCH v1] ext4: fix a assertion failure due to ungranted bh dirting Baolin Liu
2024-10-10  9:29 ` Jan Kara
2024-10-11  6:18   ` liubaolin [this message]
2024-10-16  2:42     ` liubaolin
     [not found]   ` <5dc22111.4718.19279c3f3b7.Coremail.liubaolin12138@163.com>
2024-10-16 10:33     ` Jan Kara
2024-10-16 13:38       ` liubaolin
2024-10-18  1:48         ` liubaolin
2024-10-18  9:14           ` Jan Kara
2024-10-18 11:34             ` liubaolin
2024-10-18 11:57               ` liubaolin
2024-10-18 12:37               ` Jan Kara
2024-10-18 13:45                 ` liubaolin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2635f3f9-86e1-4d09-ad40-4e02ac4447c5@163.com \
    --to=liubaolin12138@163.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liubaolin@kylinos.cn \
    --cc=longzhi@sangfor.com.cn \
    --cc=tytso@mit.edu \
    --cc=zhangshida@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox