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  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]
Date:   Thu, 10 Jan 2019 18:35:07 +0100
From:   Jan Kara <>
To:     姜迎 <>
Cc:     Jan Kara <>, "" <>,
        "" <>,
        "" <>,
        "" <>
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.

Jan Kara <>

Powered by blists - more mailing lists