linux-ext4 - Re: jbd2_clear_buffer_revoked

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Oct 2018 13:49:34 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Andreas Dilger <adilger.kernel@...ger.ca>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: jbd2_clear_buffer_revoked_flags() takes a long time

On Wed, Oct 10, 2018 at 04:43:27PM +0300, Adrian Hunter wrote:
> Hi
> 
> I have a case on a v4.14 kernel where the EXT4 journal commit disables
> preemption for 30ms due to jbd2_clear_buffer_revoked_flags().  That in turn
> disables preemption on other CPUs as they come to spin waiting for the same
> lock.  The side-effect of that is that it periodically blocks high priority
> tasks from running.
> 
> I see jbd2_clear_buffer_revoked_flags() iterating 32768 times calling
> __find_get_block().
> 
> Is there any way to make jbd2_clear_buffer_revoked_flags() take less time,
> or move its work out from under write_lock(&journal->j_state_lock)?

Hmm.... I'd have to look a bit more carefully and then run some tests,
but I *think* we can drop the j_state_lock at the beginning of JBD2
commit phase 1, and then grab it again right before we set
commit_transaction->t_state to T_FLUSH.

That should be safe because while the transaction state is T_LOCKED,
we can't start any new handles, so there can't be any new blocks added
to the revoke table.

Can you give that a try and see whether that solves your priority
inversion problem?

Cheers,

						- Ted