Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3890165imu; Mon, 10 Dec 2018 09:23:01 -0800 (PST) X-Google-Smtp-Source: AFSGD/UeDqcXxsrYSCrpWeN/Xat7Kq0ecP/Eronz9zXEW2iYrjF3ihTInfRjlinLjJPD2H0nWS5W X-Received: by 2002:a62:ae12:: with SMTP id q18mr13171310pff.126.1544462581067; Mon, 10 Dec 2018 09:23:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544462581; cv=none; d=google.com; s=arc-20160816; b=cX+ZHJKiV2nvfpF6sov08Fdl2cEv2+tDe1CZ88TrTwBIyFxlqugcXEoBCj6sALNvzC ezdP4OovS5QdZcdCd8EVGuUJm2JE4NqHuX+ZtshwAKUS4xMgsevXNycp9D6ObuhdSSQ9 KCMRidxv5j0LHGE8s9/BZVxXP/BztlEXbTAkgq0eshdgnuttZc/AHqLKln7bG4y1swqn 4i+WefB5HVruHwYXpNv1FDtrLidtDqOOweeJWMldkviVKgf6AvnILUhcqdNzoykPj+RI giyFWRH7f1x3mg06d5P+S0bof4ymjTLy2havCtOaasOdMoidprwDjW1bOkGzMg0yWoAe E5xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=M7ekDa43j/OQUCZKF6hNYAM2eh0TvU9a3K94EhOJFW0=; b=B/Rfgas7N5no3cDRBDgDmqS8E1+9Bm+FbXXBGuWVcQEwD1f6xSnNGgCMvVnW7PsH2X EnNl2eMYFxMCx8/LDgkwB+OyHH6Rb9QOUSUzhEzDThQJJOfAHBPvo3lRKnx8wGvDwDvr 21BwpyLoMXmaoxpt/DSomzjBRdxEho1Zo74Y3Bc/H7ZpcT+055hnU+9mXR+n3nvLe42u 3Zud0okSBoJ1DI2zWQuts0Y6Z9QvEvzMKcocB7dh/0czaFsKmxwl3ErJdOXfmiwdu+lK KSugQHI0QQ0FbVqi45eMADRb7kwfzBQs7BfaLoCW77ga7/LCTBOcqdncZ8qZWRq1VQpI Ty8Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g7si10426417plt.212.2018.12.10.09.22.46; Mon, 10 Dec 2018 09:23:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729153AbeLJRT4 (ORCPT + 99 others); Mon, 10 Dec 2018 12:19:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45110 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728399AbeLJRNf (ORCPT ); Mon, 10 Dec 2018 12:13:35 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C0E76368E7; Mon, 10 Dec 2018 17:13:35 +0000 (UTC) Received: from horse.redhat.com (unknown [10.18.25.234]) by smtp.corp.redhat.com (Postfix) with ESMTP id 78520600D6; Mon, 10 Dec 2018 17:13:35 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id AE534224277; Mon, 10 Dec 2018 12:13:30 -0500 (EST) From: Vivek Goyal To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: vgoyal@redhat.com, miklos@szeredi.hu, stefanha@redhat.com, dgilbert@redhat.com, sweil@redhat.com, swhiteho@redhat.com Subject: [PATCH 43/52] fuse: Take inode lock for dax inode truncation Date: Mon, 10 Dec 2018 12:13:09 -0500 Message-Id: <20181210171318.16998-44-vgoyal@redhat.com> In-Reply-To: <20181210171318.16998-1-vgoyal@redhat.com> References: <20181210171318.16998-1-vgoyal@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 10 Dec 2018 17:13:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a file is opened with O_TRUNC, we need to make sure that any other DAX operation is not in progress. DAX expects i_size to be stable. In fuse_iomap_begin() we check for i_size at multiple places and we expect i_size to not change. Another problem is, if we setup a mapping in fuse_iomap_begin(), and file gets truncated and dax read/write happens, KVM currently hangs. It tries to fault in a page which does not exist on host (file got truncated). It probably requries fixing in KVM. So for now, take inode lock. Once KVM is fixed, we might have to have a look at it again. Signed-off-by: Vivek Goyal --- fs/fuse/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fuse/file.c b/fs/fuse/file.c index d0942ce0a6c3..cb28cf26a6e7 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -406,7 +406,7 @@ int fuse_open_common(struct inode *inode, struct file *file, bool isdir) int err; bool lock_inode = (file->f_flags & O_TRUNC) && fc->atomic_o_trunc && - fc->writeback_cache; + (fc->writeback_cache || IS_DAX(inode)); err = generic_file_open(inode, file); if (err) -- 2.13.6