From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D45F2C352AA for ; Wed, 2 Oct 2019 13:07:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AB967222C4 for ; Wed, 2 Oct 2019 13:07:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="OcATdm0f" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726852AbfJBNHn (ORCPT ); Wed, 2 Oct 2019 09:07:43 -0400 Received: from mail-oi1-f175.google.com ([209.85.167.175]:36061 "EHLO mail-oi1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726901AbfJBNHk (ORCPT ); Wed, 2 Oct 2019 09:07:40 -0400 Received: by mail-oi1-f175.google.com with SMTP id k20so17574648oih.3 for ; Wed, 02 Oct 2019 06:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=50mE1GFOx2IDL8fOUBOO94SxADHosM9SfQ7pyxbnHTg=; b=OcATdm0fU0HGv1IIhubCuFeqR/P2N37o7xtR/ZD4irFYeHZyY/QMlcxb9A3jVo1gr4 chbxvSvR7VV0Qigg5Ap4In4xkHjYBGjW81DG45OK+R+st0eaUOvKFdRsNtBGfdXXso+G CRT9yAg3GyQINBZ5KBDazaDUYmqZ9vColyWrmK7zf2b7qw3LLSuXB22GA91dRzkb/DN3 hVBuovDyfmx09Yu6vWFC0lVHAXaZdX+8e6xTLeBTs8iVaP9DmUzHXZJ5SuCoYXwZ14L3 3WdQyTtyBcH2b1o1IoJ8dDqWwniK/IYku412BJ6lj3HdaGvf3lcdbJk/pu8WTervpUsH BKcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=50mE1GFOx2IDL8fOUBOO94SxADHosM9SfQ7pyxbnHTg=; b=U532IcywIbK1sPeQbmXYaj/e2VGEDAlsuyTfwzQRCp0HGV7m+yjqVJjpnGqjsHMXFq 6ARONsiw8COhP+wEl0nsac+MXaM18ZgWRYgG3XwZ2glO29GqC2hbJZm7l7dgwPwF5qXi BAxW630hWxz1fD6/cGiaF8OjMQpTHxK3OsO827wxn6X8Jve1E1u/5N03jyJPgi/Ukzx/ NTppxIEhHff6m2TBCbcnlrfr7/HzO1mi3FXDevedSKShPDGfVsNvrmjC9t/8UrBcl7o1 Plh5yXjUiSbW4OggTrWf+A50izEGuQ2cXsTB22jiEtjGz8ekEf7YE4t6Mk0Rf2RCkQHB e5Gg== X-Gm-Message-State: APjAAAXRttbmb6aS3WgjKTcFQNExUAeOZcwm0kasDnq0zr/9j5r8zZQd yudP1plmntNZtT1tFiVk5lSuieKdSvOaLYgTbi33Fg== X-Google-Smtp-Source: APXvYqxGQ01cpMCqhyT0OZic4du6ntHizaukJRygkeedHLWkQjdo8fNGeQWk8deAiGsRuCSgwYPjlJGf+Xhg9J875/c= X-Received: by 2002:aca:eb09:: with SMTP id j9mr2925590oih.105.1570021659582; Wed, 02 Oct 2019 06:07:39 -0700 (PDT) MIME-Version: 1.0 References: <20190923190853.GA3781@iweiny-DESK2.sc.intel.com> <20190923222620.GC16973@dread.disaster.area> <20190925234602.GB12748@iweiny-DESK2.sc.intel.com> <20190930084233.GO16973@dread.disaster.area> <20191001210156.GB5500@iweiny-DESK2.sc.intel.com> In-Reply-To: <20191001210156.GB5500@iweiny-DESK2.sc.intel.com> From: Dan Williams Date: Wed, 2 Oct 2019 06:07:27 -0700 Message-ID: Subject: Re: Lease semantic proposal To: Ira Weiny Cc: Dave Chinner , linux-fsdevel , linux-xfs , linux-ext4 , linux-rdma , Linux Kernel Mailing List , linux-nvdimm , Linux MM , Jeff Layton , Jan Kara , "Theodore Ts'o" , John Hubbard , Jason Gunthorpe , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Tue, Oct 1, 2019 at 2:02 PM Ira Weiny wrote: > > On Mon, Sep 30, 2019 at 06:42:33PM +1000, Dave Chinner wrote: > > On Wed, Sep 25, 2019 at 04:46:03PM -0700, Ira Weiny wrote: > > > On Tue, Sep 24, 2019 at 08:26:20AM +1000, Dave Chinner wrote: > > > > Hence, AFIACT, the above definition of a F_RDLCK|F_LAYOUT lease > > > > doesn't appear to be compatible with the semantics required by > > > > existing users of layout leases. > > > > > > I disagree. Other than the addition of F_UNBREAK, I think this is consistent > > > with what is currently implemented. Also, by exporting all this to user space > > > we can now write tests for it independent of the RDMA pinning. > > > > The current usage of F_RDLCK | F_LAYOUT by the pNFS code allows > > layout changes to occur to the file while the layout lease is held. > > This was not my understanding. I think you guys are talking past each other. F_RDLCK | F_LAYOUT can be broken to allow writes to the file / layout. The new unbreakable case would require explicit SIGKILL as "revocation method of last resort", but that's the new incremental extension being proposed. No changes to the current behavior of F_RDLCK | F_LAYOUT. Dave, the question at hand is whether this new layout lease mode being proposed is going to respond to BREAK_WRITE, or just BREAK_UNMAP. It seems longterm page pinning conflicts really only care about BREAK_UNMAP where pages that were part of the file are being removed from the file. The unbreakable case can tolerate layout changes that keep pinned pages mapped / allocated to the file.