linux-ext4 - Re: generic/224 failures on 4.5

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: <20160315221356.GC23848@thunk.org>
Date:	Tue, 15 Mar 2016 18:13:56 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Whitney <enwlinux@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: generic/224 failures on 4.5 - encrypted test case

On Tue, Mar 15, 2016 at 05:37:27PM -0400, Eric Whitney wrote:
> The test fails relatively rarely - about one in ten trials.  The set of
> reported kernel errors varies considerably from run to run.  The one constant
> is an ENOSPC complaint from ext4_bio_write_page() which appears whether the
> test passes or fails.
>
> [   18.146614] ext4_bio_write_page: ret = -12
>

-12 is not ENOSPC; it's ENOMEM.   (ENOSPC is 28).

So basically we're hitting a case where generic/224 is submitting data
so quickly that we can't handle it fast enough.  I suspect the call
path is that we're inside the jbd2_commit(), and we're calling
journal_submit_data_buffers(), which ends up calling
ext4_writepages(), and this is returning the ENOMEM.  Unfortunately
we're not providing a better message there, and we just return
jbd2_journal_abort() if journal_submit_data_buffers() fails.

I suspect what we need to do is to pass down a flag through
ext4_bio_write_page() and ext4_encrypt() so that in the case where we
are doing a data integrity sync, that we have to use GFP_NOFAIL in our
data allocations in the fs/ext4/crypto.c.

							- 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