All of lore.kernel.org
 help / color / mirror / Atom feed
From: yangerkun <yangerkun@huawei.com>
To: Mauricio Oliveira <mauricio.oliveira@canonical.com>
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
	Jan Kara <jack@suse.cz>, <linux-ext4@vger.kernel.org>,
	"zhangyi (F)" <yi.zhang@huawei.com>, Hou Tao <houtao1@huawei.com>,
	<zhangxiaoxu5@huawei.com>, Ye Bin <yebin10@huawei.com>,
	<hejie3@huawei.com>
Subject: Re: [Bug report] journal data mode trigger panic in jbd2_journal_commit_transaction
Date: Fri, 20 Nov 2020 11:03:06 +0800	[thread overview]
Message-ID: <14879a89-b6d2-e142-2ea3-23fbb041444b@huawei.com> (raw)
In-Reply-To: <17d7ecde-5fda-cd03-6fef-e7b8250489f9@huawei.com>



在 2020/11/20 10:54, yangerkun 写道:
> 
> 
> 在 2020/11/19 21:12, Mauricio Oliveira 写道:
>> On Thu, Nov 19, 2020 at 1:25 AM yangerkun <yangerkun@huawei.com> wrote:
>>>
>>>
>>>
>>> 在 2020/11/16 21:50, Mauricio Oliveira 写道:
>>>> Hi Kun,
>>>>
>>>> On Sat, Nov 14, 2020 at 5:18 AM yangerkun <yangerkun@huawei.com> wrote:
>>>>> While using ext4 with data=journal(3.10 kernel), we meet a problem 
>>>>> that
>>>>> we think may never happend...
>>>> [...]
>>>>
>>>> Could you please confirm you mean 5.10-rc* kernel instead of 3.10?
>>>> (It seems so as you mention a recent commit below.)  Thanks!
>>>>
>>>>> For now, what I have seen that can dirty buffer directly is
>>>>> ext4_page_mkwrite(64a9f1449950 ("ext4: data=journal: fixes for
>>>>> ext4_page_mkwrite()")), and runing ext4_punch_hole with keep_size
>>>>> /ext4_page_mkwrite parallel can trigger above warning easily.
>>>> [...]
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> Sorry for the long delay reply... And thanks a lot for your advise! The
>>> bug trigger with a very low probability. So won't trigger with 5.10 can
>>> not prove no bug exist in 5.10.
>>>
>>
>> No worries, and thanks for following up.
>> So I understand that the bug report was indeed on 3.10, and 5.10-rcN
>> is not yet confirmed.
>>
>>> Google a lot and notice that someone before has report the same bug[1].
>>> '3b136499e906 ("ext4: fix data corruption in data=journal mode")' seems
>>> fix the problem. I will try to understand this, and give a analysis
>>> about how to reproduce it!
>>
>> Cool, thanks!
>>
>>> Thanks,
>>> Kun.
>>
>>
>>
> Hi,
> 
> The follow step can reproduce the bug[1] reported before easily. And the 
> bug we meet seems same. Following patch will fix the bug.
> 
> 3b136499e906 ext4: fix data corruption in data=journal mode
> b90197b65518 ext4: use private version of page_zero_new_buffers() for 
> data=journal mode
> 
> 
> 1. mkfs.ext4
> 2. touch $tofile(ino == 12)
> 3. touch $fromfile(ino == 13) and write 4k to fromfile and sync
> 
> mmap $fromfile 4k
> and write 4k
> to $tofile
> 
> ...
> generic_perform_write
>   ext4_write_begin
>    ext4_journal_start
>    (trans 1)
>   if (ino == 12) sleep for 30s
>   ...                           truncate $fromfile
>                                 to 0
>   copied=0,bytes=4k
>   ext4_journalled_write_end
>    page_zero_new_buffers
>     mark_buffer_dirty
>    write_end_fn
>     ...
>     __jbd2_journal_file_buffer
>      test_clear_buffer_dirty
>      __jbd2_journal_temp_unlink_buffer
            this will mark buffer dirty again!
>    ext4_journal_stop
>    (trans 1)
>                                                   trans1 commit
>                                                   ...
>    ext4_truncate_failed_write
>     ...
>     journal_unmap_buffer
>      set_buffer_freed
>                                                   forget list
>                                                    ...
>                                                    clear_buffer_jbddirty
>                                                    ...
>                                                    J_ASSERT_BH(bh,
>                                                    !buffer_dirty(bh))
>                                                    ^^^^^^^^^^^^^^^^^
>                                                    trigger the bug...
> 
> 
> 
> [1]. https://www.spinics.net/lists/linux-ext4/msg56447.html
> 
> Thanks,
> Kun.
> .

  reply	other threads:[~2020-11-20  3:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-14  8:18 [Bug report] journal data mode trigger panic in jbd2_journal_commit_transaction yangerkun
2020-11-16 13:50 ` Mauricio Oliveira
2020-11-19  4:25   ` yangerkun
2020-11-19 13:12     ` Mauricio Oliveira
2020-11-20  2:54       ` yangerkun
2020-11-20  3:03         ` yangerkun [this message]
2020-11-20 13:14         ` Mauricio Oliveira

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=14879a89-b6d2-e142-2ea3-23fbb041444b@huawei.com \
    --to=yangerkun@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=hejie3@huawei.com \
    --cc=houtao1@huawei.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mauricio.oliveira@canonical.com \
    --cc=tytso@mit.edu \
    --cc=yebin10@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=zhangxiaoxu5@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.