linux-ext4 - Re: 答复: [PATCH] jbd2: adjust location of journal->j_list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20190110173507.GD28450@quack2.suse.cz>
Date:   Thu, 10 Jan 2019 18:35:07 +0100
From:   Jan Kara <jack@...e.cz>
To:     姜迎 <jiangying13@...tuan.com>
Cc:     Jan Kara <jack@...e.cz>, "tytso@....edu" <tytso@....edu>,
        "jack@...e.com" <jack@...e.com>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 答复: [PATCH] jbd2: adjust
 location of journal->j_list_lock

On Thu 10-01-19 03:31:14, 姜迎 wrote:
> Hum, why do you think the patch below changes anything for the assertion
> failure you mention above? The code that gets additionally covered by
> j_list_lock is just handling of journal head frozen & b_committed_data
> buffers...
> 
> ==>Because kernel panic on  J_ASSERT_JH(jh, jh->b_transaction == NULL).
> 
> please see the following analysis, thanks.  jh->b_transaction is set NULL
> between  J_ASSERT_JH(jh,jh-->b_transaction == commit_transaction ) and
> __jbd2_journal_remove_checkpoint.
> 
> [X]
> 
> With which kernel version did you see the assertion failure?
> 
> ==> I found this issue on kernel-3.10. But I see that the latest kernel
> version also has this problem, but it is seldom reproduce. Can you help
> to check ?

Ah, ok. But the problem really is that __journal_remove_checkpoint() should
not drop the last jh reference (and thus we should never get to
__journal_remove_journal_head() with the assertion J_ASSERT_JH(jh,
jh->b_transaction == NULL)). The committing transaction holds
reference to the journal_head until __jbd2_journal_refile_buffer() either
moves the reference to the next transaction or drops it. So what you
observe rather seems like some bug in reference counting of journal
heads and your patch isn't going to help.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR