From patchwork Tue Oct 10 14:49:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Williams X-Patchwork-Id: 9996395 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C86F6601AE for ; Tue, 10 Oct 2017 14:56:00 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B96312862C for ; Tue, 10 Oct 2017 14:56:00 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AE10E28488; Tue, 10 Oct 2017 14:56:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 558A42863C for ; Tue, 10 Oct 2017 14:56:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932183AbdJJOzy (ORCPT ); Tue, 10 Oct 2017 10:55:54 -0400 Received: from mga01.intel.com ([192.55.52.88]:17684 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932245AbdJJOzt (ORCPT ); Tue, 10 Oct 2017 10:55:49 -0400 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2017 07:55:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,505,1500966000"; d="scan'208";a="1229194212" Received: from dwillia2-desk3.jf.intel.com (HELO dwillia2-desk3.amr.corp.intel.com) ([10.54.39.125]) by fmsmga002.fm.intel.com with ESMTP; 10 Oct 2017 07:55:48 -0700 Subject: [PATCH v8 05/14] fs, xfs, iomap: introduce iomap_can_allocate() From: Dan Williams To: linux-nvdimm@lists.01.org Cc: Jan Kara , "Darrick J. Wong" , linux-rdma@vger.kernel.org, linux-api@vger.kernel.org, Dave Chinner , iommu@lists.linux-foundation.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, Jeff Moyer , linux-fsdevel@vger.kernel.org, Ross Zwisler , Christoph Hellwig Date: Tue, 10 Oct 2017 07:49:24 -0700 Message-ID: <150764696413.16882.17741758404259343219.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <150764693502.16882.15848797003793552156.stgit@dwillia2-desk3.amr.corp.intel.com> References: <150764693502.16882.15848797003793552156.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: StGit/0.17.1-9-g687f MIME-Version: 1.0 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In preparation for using FL_LAYOUT leases to allow coordination between the kernel and processes doing userspace flushes / RDMA with DAX mappings, add this helper that can be used to detect when block-map updates are not allowed. This is targeted to be used in an ->iomap_begin() implementation where we may have various filesystem locks held and can not synchronously wait for any FL_LAYOUT leases to be released. In particular an iomap mmap fault handler running under mmap_sem can not unlock that semaphore and wait for these leases to be unlocked. Instead, this signals the lease holder(s) that a break is requested and immediately returns with an error. Cc: Jan Kara Cc: Jeff Moyer Cc: Christoph Hellwig Cc: "Darrick J. Wong" Cc: Ross Zwisler Suggested-by: Dave Chinner Signed-off-by: Dan Williams --- fs/xfs/xfs_iomap.c | 3 +++ fs/xfs/xfs_layout.c | 5 ++++- include/linux/iomap.h | 10 ++++++++++ 3 files changed, 17 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index a1909bc064e9..b3cda11e9515 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -1052,6 +1052,9 @@ xfs_file_iomap_begin( error = -EAGAIN; goto out_unlock; } + error = iomap_can_allocate(inode); + if (error) + goto out_unlock; /* * We cap the maximum length we map here to MAX_WRITEBACK_PAGES * pages to keep the chunks of work done where somewhat symmetric diff --git a/fs/xfs/xfs_layout.c b/fs/xfs/xfs_layout.c index 71d95e1a910a..88c533bf5b7c 100644 --- a/fs/xfs/xfs_layout.c +++ b/fs/xfs/xfs_layout.c @@ -19,7 +19,10 @@ * about exposing unallocated blocks but just want to provide basic * synchronization between a local writer and pNFS clients. mmap writes would * also benefit from this sort of synchronization, but due to the tricky locking - * rules in the page fault path we don't bother. + * rules in the page fault path all we can do is start the lease break + * timeout. See usage of iomap_can_allocate in xfs_file_iomap_begin to + * prevent write-faults from allocating blocks or performing extent + * conversion. */ int xfs_break_layouts( diff --git a/include/linux/iomap.h b/include/linux/iomap.h index f64dc6ce5161..e24b4e81d41a 100644 --- a/include/linux/iomap.h +++ b/include/linux/iomap.h @@ -2,6 +2,7 @@ #define LINUX_IOMAP_H 1 #include +#include struct fiemap_extent_info; struct inode; @@ -88,6 +89,15 @@ loff_t iomap_seek_hole(struct inode *inode, loff_t offset, const struct iomap_ops *ops); loff_t iomap_seek_data(struct inode *inode, loff_t offset, const struct iomap_ops *ops); +/* + * Check if there are any file layout leases preventing block map + * changes and if so start the lease break process, but do not wait for + * it to complete (return -EWOULDBLOCK); + */ +static inline int iomap_can_allocate(struct inode *inode) +{ + return break_layout(inode, false); +} /* * Flags for direct I/O ->end_io: