Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2146452ybv; Fri, 21 Feb 2020 09:45:09 -0800 (PST) X-Google-Smtp-Source: APXvYqzN0gnA27/+bfEgtLYzKPSPBL+UqjODfG6N9Rzru107VCGXc00ILOzCmvtRV6u5jtgBLevZ X-Received: by 2002:a9d:600e:: with SMTP id h14mr28020141otj.113.1582307109483; Fri, 21 Feb 2020 09:45:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582307109; cv=none; d=google.com; s=arc-20160816; b=N0iSgCh9e/tinHEzuZnz/iiRQGrXs9eGDMyiTII5DhenQoHPBsyBbMo7if0pBQH+go vYJh6Q4bl2ppY+R03Zm1sTfoxuABH8jeAdFRzipCP137NXaFO941OJ4toQbK6dEV10lY g+qCBuopONIN6EIXzyt4Hu4/C6t/HL6OTJGrhImHQVVp38EzCILCqud4VZFr4/3omyWd is5dq6mLkwbyFtfqww2T93NP+XFDkeHrScfquQo7H9rMmKdzGEr8ziPIGLJvxSKdfy2F Tpd1CktS30SmsWQku7qy8IqpprSGi+jkyYjQBjl5ZyI/dO/WyGOqqaJ6ObP/mkGkiAHR rveA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=nCOPnw56feilTj5kswGB7h1xV0/iVTaMmd3MxsqM5/g=; b=NtHhGE4PYFCmR5RPtWuoK47pD4q7mHKk2V1McrncKzTkQOOwbuI6i7HDEwX0O1NRcN 3otvUXor/ubhVqh0X/i5TnPH5p+Ka/V/xgABUxOKg7xNvOq6zWC3MHavAfGHtGLg/C1Y dphzWpCl5P00XAvDPDETOnSEMTRFBTFvFtGSK/BL9696sJXIDIYOBHJMXRPsLtI2kvN7 A9bgLR+UFzL8/OchnbSYI+8dLow3877zFysSTsIZotXOj17cPPsHnF0ZTPRFYIFiOAIZ eLRmaftK70STUvIHKOHnJG4ToSzl7nLqmXPs1thUTGEgssCH5ULWPGZYhJUjDln4WUOu eOIg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5si1696871ote.187.2020.02.21.09.44.56; Fri, 21 Feb 2020 09:45:09 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728426AbgBURox (ORCPT + 99 others); Fri, 21 Feb 2020 12:44:53 -0500 Received: from verein.lst.de ([213.95.11.211]:56731 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725947AbgBURow (ORCPT ); Fri, 21 Feb 2020 12:44:52 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id BAE0A68BFE; Fri, 21 Feb 2020 18:44:49 +0100 (CET) Date: Fri, 21 Feb 2020 18:44:49 +0100 From: Christoph Hellwig To: ira.weiny@intel.com Cc: linux-kernel@vger.kernel.org, Alexander Viro , "Darrick J. Wong" , Dan Williams , Dave Chinner , Christoph Hellwig , "Theodore Y. Ts'o" , Jan Kara , linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH V4 07/13] fs: Add locking for a dynamic address space operations state Message-ID: <20200221174449.GB11378@lst.de> References: <20200221004134.30599-1-ira.weiny@intel.com> <20200221004134.30599-8-ira.weiny@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200221004134.30599-8-ira.weiny@intel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 20, 2020 at 04:41:28PM -0800, ira.weiny@intel.com wrote: > From: Ira Weiny > > DAX requires special address space operations (aops). Changing DAX > state therefore requires changing those aops. > > However, many functions require aops to remain consistent through a deep > call stack. > > Define a vfs level inode rwsem to protect aops throughout call stacks > which require them. > > Finally, define calls to be used in subsequent patches when aops usage > needs to be quiesced by the file system. I am very much against this. There is a reason why we don't support changes of ops vectors at runtime anywhere else, because it is horribly complicated and impossible to get right. IFF we ever want to change the DAX vs non-DAX mode (which I'm still not sold on) the right way is to just add a few simple conditionals and merge the aops, which is much easier to reason about, and less costly in overall overhead.