linux-ext4 - Re: [PATCH] ext4: fix the deadlock in mpage_da_map_and

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

Message-ID: <20111020234712.GJ17210@thunk.org>
Date:	Thu, 20 Oct 2011 19:47:12 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Kazuya Mio <k-mio@...jp.nec.com>
Cc:	ext4 <linux-ext4@...r.kernel.org>,
	Andreas Dilger <adilger@...ger.ca>
Subject: Re: [PATCH] ext4: fix the deadlock in mpage_da_map_and_submit()

On Thu, Oct 13, 2011 at 04:13:18PM +0900, Kazuya Mio wrote:
> If ext4_jbd2_file_inode() in mpage_da_map_and_submit() fails due to journal
> abort, this function returns to caller without unlocking the page.
> It leads to the deadlock, and the patch fixes this issue by calling
> mpage_da_submit_io().
> 
> Signed-off-by: Kazuya Mio <k-mio@...jp.nec.com>

Applied, thanks.

This is an area where we should really clean things up next merge
window, though.  I'm a little uneasy that we will potentially write
back some blocks even though the journal has been aborted (we do this
in other error paths, so this isn't a criticism of this patch, just of
the current state of affairs).

The problem mpage_da_submit_io() is the only way we have to unlock the
pages.  In the future we should probably have a separate path to
unlock the pages in case of an error.  We might also want to merge
mpage_da_submit_io() and mpage_da_map_and_submit(), and to also clean
up a number of comments which are out of date.  (For example,
mpage_da_submit_io() no longer uses ext4_writepage().)

						- 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