linux-ext4 - [PATCH 0/2] ext4: Fix ENOSPC handling for DAX faults

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

Message-Id: <20171213091352.23448-1-jack@suse.cz>
Date:   Wed, 13 Dec 2017 10:13:50 +0100
From:   Jan Kara <jack@...e.cz>
To:     <linux-ext4@...r.kernel.org>
Cc:     Ted Tso <tytso@....edu>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        <linux-fsdevel@...r.kernel.org>, linux-nvdimm@...ts.01.org,
        Jan Kara <jack@...e.cz>
Subject: [PATCH 0/2] ext4: Fix ENOSPC handling for DAX faults

Hello,

these two patches fix handling of ENOSPC during DAX faults. The problem is
that currently running transaction may be holding lots of already freed
blocks which can be reallocated only once the transaction commits. Standard
retry logic in ext4_iomap_end() does not work for DAX page fault handler
since we hold current transaction open in ext4_dax_huge_fault() and thus
retry logic cannot force the running transaction and as a result application
gets SIGBUS due to premature ENOSPC error.

These two patches fix the problem. I'm not too happy about patch 1/2 passing
additional info (error code) from the fault handler but I don't see an
easy better option since we want to also pass back special return values
like VM_FAULT_FALLBACK. Comments are welcome.

								Honza