Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp955091pxk; Thu, 17 Sep 2020 23:00:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzHJXYN+XWSouXW71rwXRsrY1fMt5Fg8OZgkDv6UziMNns+K94E+f6iE4jDPK9j3n+6yGhL X-Received: by 2002:a17:906:441:: with SMTP id e1mr11197278eja.396.1600408855200; Thu, 17 Sep 2020 23:00:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600408855; cv=none; d=google.com; s=arc-20160816; b=KebWlJX8SKD4Mqs+zE2+TdMDz+/9ZZ8EIzizT6XeWRM9YXFxGqmntllADFXqydeb/J tB/h0khwGYRKHVRKSijvdy6UsN2AAuYGmyIYwdnPPMkEaknMRv1E+RAoeV9ur3MEnmz1 M58npobODL6OWTHksysGTfP1DkHxH0ELaMeZ0ODxXS4MJoxXjb99V9J9lLhwsvrdPBsP RNbyECOn5xWF0hbQMhzCFXhQXXYqjibIe6hfsfsDRvPSTyNnD05x/YC/seVXavuFfxvm YGIT/bOr6bASOueyetQP0zoPYhpIAGO4DJi7oB4UWB2kkoBoFdwvZBT02SElwhCxeUuF CmYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=P9fY6byayfuxyKCLSm6xqBSHHq4ia1kjqvHSYTQPD60=; b=FeJActaqD+UPZVUXpjOACk/z0n6q0NRqnx3BcM6t0bYt2hleQmdwe1csLx4q8nVTG4 h9pDOrWEq6b30Y7lPyhyAjxXKlIeh6AJHczkjPwJ85qaORKTyn1M8qa5KzADbd4I6owV F38Mf75l/JoClxYvLeNwzkvrNuNuyfzAEtVmUwVmJ1SXBwxXaH6ncxv2VjC+Lb4YYpPw hY92jTIrh4K43M5LVdXngGiqu0jbONkzIqQSjXqgkE1OpFDMZeZq4pAFKMNT8Gsxlyta Z7dfHIDdV9Ka7Uhl/Po6SNTcQi7mO0s2rbKQPJ3JLLOiOn0RLd5SWzol5c+zL0nWgiU2 yZ1g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e4si1302978edq.182.2020.09.17.23.00.32; Thu, 17 Sep 2020 23:00:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726659AbgIRF7j (ORCPT + 99 others); Fri, 18 Sep 2020 01:59:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725886AbgIRF7i (ORCPT ); Fri, 18 Sep 2020 01:59:38 -0400 Received: from nautica.notk.org (ipv6.notk.org [IPv6:2001:41d0:1:7a93::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91853C06174A; Thu, 17 Sep 2020 22:59:38 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 1001) id 5EAEFC01B; Fri, 18 Sep 2020 07:59:34 +0200 (CEST) Date: Fri, 18 Sep 2020 07:59:19 +0200 From: Dominique Martinet To: "Matthew Wilcox (Oracle)" Cc: linux-fsdevel@vger.kernel.org, linux-cifs@vger.kernel.org, Richard Weinberger , ecryptfs@vger.kernel.org, linux-um@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-mtd@lists.infradead.org, v9fs-developer@lists.sourceforge.net, ceph-devel@vger.kernel.org, linux-afs@lists.infradead.org Subject: Re: [V9fs-developer] [PATCH 02/13] 9p: Tell the VFS that readpage was synchronous Message-ID: <20200918055919.GA30929@nautica> References: <20200917151050.5363-1-willy@infradead.org> <20200917151050.5363-3-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200917151050.5363-3-willy@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Matthew Wilcox (Oracle) wrote on Thu, Sep 17, 2020: > diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c > index cce9ace651a2..506ca0ba2ec7 100644 > --- a/fs/9p/vfs_addr.c > +++ b/fs/9p/vfs_addr.c > @@ -280,6 +280,10 @@ static int v9fs_write_begin(struct file *filp, struct address_space *mapping, > goto out; > > retval = v9fs_fid_readpage(v9inode->writeback_fid, page); > + if (retval == AOP_UPDATED_PAGE) { > + retval = 0; > + goto out; > + } FWIW this is a change of behaviour; for some reason the code used to loop back to grab_cache_page_write_begin() and bail out on PageUptodate() I suppose; some sort of race check? The whole pattern is a bit weird to me and 9p has no guarantee on concurrent writes to a file with cache enabled (except that it will corrupt something), so this part is fine with me. What I'm curious about is the page used to be both unlocked and put, but now isn't either and the return value hasn't changed for the caller to make a difference on write_begin / I don't see any code change in the vfs to handle that. What did I miss? (FWIW at least cifs in the series has the same pattern change; didn't check all of them) Thanks, -- Dominique