Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp1774040rwl; Thu, 5 Jan 2023 19:55:18 -0800 (PST) X-Google-Smtp-Source: AMrXdXtzJnXw/T9Uf6BS2JbIe28OhNoDRNodp+PMt3jTBQhhPSqM3PLWyYf5EF1MjYcuud0CgFhl X-Received: by 2002:a17:907:b684:b0:7c0:a99c:485c with SMTP id vm4-20020a170907b68400b007c0a99c485cmr50715219ejc.68.1672977318746; Thu, 05 Jan 2023 19:55:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672977318; cv=none; d=google.com; s=arc-20160816; b=xIKOyxyn+DpSMC9YDgw/9WX2dBLJ5KK7U3fmfrbGpXa9+zBND58HdJYuVG5/hJNa0t 1i5dD+1j03pFufIQsWTVOtKmEzhP/8Jl1TAQLWLD2ajZCmOInME8FOZnfG9R9z3kzHr9 Wxu9HwBwDKC2mEoloLUhrpTU05BXsOTq3EaGyuuodx7DGoCyUjjxdsVG/L+6PYp/I7As MXtjv1KASOKw1KsmCs0o5l1nncRkLSfYrjII2eP8YYj+yhjAXCjSTzJIfJCNkQ9sr2Uv 7QdhBBRdvLWfht+3+suPX3AnXcjZsnb60YJt8MNZ4eOrke0IJtgmrQLC5eU1QQfqc67f SbpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=L/h5ONn5kfeNXOcPz6IlUqS0OikNDflZib77sRoB5w4=; b=Swl+mkC9sr1xtTCfzwLtGAC/q+FqaGM9ZmdujU+aqyeiGtpLPHroUWf9bYNx3Wmko4 2suqsDzwdRH1t4YksJA5JNbkuwKBLEHOqjfToWuVlQSD2vsacTj3OagUH8zjxk27ASVF bEGZieBwA5ZWUkdD+h2AHzKOseo3QfH48Cg5SK2tLGSWkR9fb1BnX+uN1jwYaOQFZW3L q/6WlsqaEvXO2cx97rBNIwML/KJqsFY0PG2W6wMyAFd19S8286qgWgqG+SbmezJ6QCHS dellDL8qF/8gliwJtmmSE9mNrSwFkCelyN6m/1sd2ZRQMqVc5xVsFkvaMrMmB8JV2QLf S8rQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=htB06lsA; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=yLemHUtZ; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xa8-20020a170906fd8800b007c0ea5a7ca4si33578405ejb.858.2023.01.05.19.54.45; Thu, 05 Jan 2023 19:55:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=htB06lsA; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=yLemHUtZ; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229514AbjAFDs4 (ORCPT + 99 others); Thu, 5 Jan 2023 22:48:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231730AbjAFDsz (ORCPT ); Thu, 5 Jan 2023 22:48:55 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FDB16A0F4 for ; Thu, 5 Jan 2023 19:48:53 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id EFF7577083; Fri, 6 Jan 2023 03:48:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1672976931; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L/h5ONn5kfeNXOcPz6IlUqS0OikNDflZib77sRoB5w4=; b=htB06lsA02J8z+qBu3UPdbBbT2pVmpc/wEIclYVGJJ/vNyjuD/g9WQfshEPI8c9aHDO639 jyl0VydRFOZhg/ITUSxQTOLj6+4ISDyl1LamIqVfhyeb8nUkLqPA7pHX+I2Vh1PCC5EKSm SARhdrU09zotKj89uddqGC97n4GJEgk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1672976931; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L/h5ONn5kfeNXOcPz6IlUqS0OikNDflZib77sRoB5w4=; b=yLemHUtZcYY1SeZAFqUrtFdDU6T8dO1770ZzbO5gchgg2myv0kI5O6MxfEjX6rDbF/I9Ih v7kJjLrVHHBZPTAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 364F8139D2; Fri, 6 Jan 2023 03:48:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id A82oNyGat2PpXgAAMHmgww (envelope-from ); Fri, 06 Jan 2023 03:48:49 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Trond Myklebust" Cc: "Trond Myklebust" , "Anna Schumaker" , "Olga Kornievskaia" , "Linux NFS Mailing List" Subject: Re: [PATCH] NFS: Handle missing attributes in OPEN reply In-reply-to: <46f047159da42dadaca576e0a87a622539609730.camel@kernel.org> References: <167279203612.13974.15063003557908413815@noble.neil.brown.name>, <7a98c3e70bae70c44418ce8ac4b84f387b4ff850.camel@kernel.org>, <167279409373.13974.16504090316814568327@noble.neil.brown.name>, <210f08ae5f0ba47c289293981f490fca848dd2ed.camel@kernel.org>, <167279837032.13974.12155714770736077636@noble.neil.brown.name>, <167295936597.13974.7568769884598065471@noble.neil.brown.name>, <46f047159da42dadaca576e0a87a622539609730.camel@kernel.org> Date: Fri, 06 Jan 2023 14:48:46 +1100 Message-id: <167297692611.13974.5805041718280562542@noble.neil.brown.name> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, 06 Jan 2023, Trond Myklebust wrote: > On Fri, 2023-01-06 at 09:56 +1100, NeilBrown wrote: > > On Wed, 04 Jan 2023, NeilBrown wrote: > > > On Wed, 04 Jan 2023, Trond Myklebust wrote: > > > > On Wed, 2023-01-04 at 12:01 +1100, NeilBrown wrote: > > > > > On Wed, 04 Jan 2023, Trond Myklebust wrote: > > > > > >=20 > > > > > >=20 > > > > > > If the server starts to reply NFS4ERR_STALE to GETATTR > > > > > > requests, > > > > > > why do > > > > > > we care about stateid values? Just mark the inode as stale > > > > > > and drop > > > > > > it > > > > > > on the floor. > > > > >=20 > > > > > We have a valid state from the server - we really shouldn't > > > > > just > > > > > ignore > > > > > it. > > > > >=20 > > > > > Maybe it would be OK to mark the inode stale.=C2=A0 I don't know if > > > > > various > > > > > retry loops abort properly when the inode is stale. > > > >=20 > > > > Yes, they are all supposed to do that. Otherwise we would end up > > > > looping forever in close(), for instance, since the PUTFH, > > > > GETATTR and > > > > CLOSE can all return NFS4ERR_STALE as well. > > >=20 > > > To mark the inode as STALE we still need to find the inode, and > > > that is > > > the key bit missing in the current code.=C2=A0 Once we find the inode, > > > we > > > could mark it stale, but maybe some other error resulted in the > > > missing > > > GETATTR... > > >=20 > > > It might make sense to put the new code in _nfs4_proc_open() after > > > the > > > explicit nfs4_proc_getattr() fails.=C2=A0 We would need to find the > > > inode > > > given only the filehandle.=C2=A0 Is there any easy way to do that? > > >=20 > > > Thanks, > > > NeilBrown > > >=20 > >=20 > > I couldn't see a consistent pattern to follow for when to mark an > > inode > > as stale.=C2=A0 Do this, on top of the previous patch, seem reasonable? > >=20 > > Thanks, > > NeilBrown > >=20 > >=20 > >=20 > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c > > index b441b1d14a50..04497cb42154 100644 > > --- a/fs/nfs/nfs4proc.c > > +++ b/fs/nfs/nfs4proc.c > > @@ -489,6 +489,8 @@ static int nfs4_do_handle_exception(struct > > nfs_server *server, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0case -ESTALE: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (i= node !=3D NULL && S_ISREG(inode->i_mode)) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pnfs_destroy_layout(NFS_I(inode)= ); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (inode) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nfs_set_inode_stale(inode); >=20 > This is normally dealt with in the generic code inside > nfs_revalidate_inode(). There should be no need to duplicate it here. >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0break; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0case -NFS4ERR_DELEG_REVOKED: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0case -NFS4ERR_ADMIN_REVOKED: > > @@ -2713,8 +2715,12 @@ static int _nfs4_proc_open(struct > > nfs4_opendata *data, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0retur= n status; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0} > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!(o_res->f_attr->vali= d & NFS_ATTR_FATTR)) { > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0struct inode *inode =3D nfs4_get_inode_by_stateid( > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&data->o_re= s.stateid, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0data->owner= ); >=20 > There shouldn't be a need to go looking for open descriptors here, > because they will hit ESTALE at some point later anyway. The problem is that they don't hit ESTALE later. Unless we update our stored stateid with the result of the OPEN, we can use the old stateid, and get the corresponding error. The only way to avoid the infinite loop is to either mark the inode as stale, or update the state-id. For either of those we need to find the inode. We don't have fileid so we cannot use iget. We do have file handle and state-id. Maybe you are saying this is a server bug that the client cannot be expect to cope with at all, and that an infinite loop is a valid client response to this particular server behaviour. In that case, I guess no patch is needed. NeilBrown >=20 > If we're going to change anything, I'd rather see us return -EACCES and > -ESTALE from the decode_access() and decode_getfattr() calls in > nfs4_xdr_dec_open() (and only those errors from those two calls!) so > that we can skip the unnecessary getattr call here. >=20 > In fact, the only case that this extra getattr should be trying to > address is the one where the server returns NFS4ERR_DELAY to either the > decode_access() or the decode_getfattr() calls specifically, and where > we therefore don't want to replay the entire open call. >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0nfs4_sequence_free_slot(&o_res->seq_res); > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0nfs4_proc_getattr(server, &o_res->fh, o_res->f_attr, > > NULL); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0nfs4_proc_getattr(server, &o_res->fh, o_res->f_attr, > > inode); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0iput(inode); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0} > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return 0; > > =C2=A0} > > @@ -4335,6 +4341,7 @@ int nfs4_proc_getattr(struct nfs_server > > *server, struct nfs_fh *fhandle, > > =C2=A0{ > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct nfs4_exception exc= eption =3D { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0.interruptible =3D true, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0.inode =3D inode, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int err; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0do { >=20 > --=20 > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@hammerspace.com >=20 >=20 >=20