linux-ext4 - Re: [PATCH 1/4] ext4: Fix deadlock during page writeback

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:	Fri, 1 Jul 2016 17:26:34 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	linux-ext4@...r.kernel.org, Eryu Guan <eguan@...hat.com>,
	stable@...r.kernel.org
Subject: Re: [PATCH 1/4] ext4: Fix deadlock during page writeback

On Fri, Jul 01, 2016 at 07:40:41PM +0200, Jan Kara wrote:
> 
> So we are waiting for transaction commit to finish with unsubmitted pages
> that already have PageWriteback set (and also potentially other pages that
> are locked and we didn't prepare them for writing because the block mapping
> we got was too short). Now JBD2 goes on trying to do the transaction
> commit:

Ah, I see, so this is only an issue in those cases where the handle is
synchronous.  Is this the only case where there is a concern?  (e.g.,
could we test handle->h_sync and stop the handle early if h_sync
is not set?)  This would put the uninit->init conversion into
potentially a separate transaction, but that should be OK.

The reason why I'm pushing so hard here is that long running handles
is a major contributor to ext4 haveing poor CPU scalability numbers,
since we can end up having lots of threads waiting on the last
transaction to complete.  So keeping transactions small and fast is a
big deal.

							- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html