From: Jan Kara Subject: [PATCH 0/2 v3] ext4: Fix ENOSPC handling for DAX faults Date: Wed, 3 Jan 2018 11:08:42 +0100 Message-ID: <20180103100844.12787-1-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jan Kara , linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ted Tso Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" List-Id: linux-ext4.vger.kernel.org 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. Ted, can you please merge these patches through your tree? Ext4 is the part that is touched by these patches the most. Changes since v2: * Added Reviewed-by tags Changes since v1: * Made error passed back from dax_iomap_fault() explicitely be only the error from ->iomap_begin() Comments are welcome. Honza