Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1717864pxb; Wed, 9 Feb 2022 03:02:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQS9JFrF1n1eYwvIpw+DHjPHxaXQvYlQEyS7ycm4FJedy5KVfpqpa5Y/VbA++t2g6wufJo X-Received: by 2002:a17:902:db0d:: with SMTP id m13mr1500972plx.131.1644404533513; Wed, 09 Feb 2022 03:02:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644404533; cv=none; d=google.com; s=arc-20160816; b=ltUw+jMWe4M855japbATbRMcdgXP+8EB0Tm2x4dVZ4Zl+cqElq8MtD2+qzv83zPuLk 8KH/4sT6BDfuzquOU5/uFb/HV5fvsPKkVSzQbgWhbuucuOsUcW3lof2t0AD358LbXq+Y gGyHlCHanadSRmmBmW07N6IG/QhUf+TJFd1sK81Esw0VT66b1pokJDZS+nNq/EcsIu/m teLNmrMWvN4FMmXHxS5SxJo6FWcjYlQ2M4cXxstMkxkaOXFDpv42+9Jsgv4psd/So52j y4gdOo8f2qkx2x1U4glOhZLtq1nDtZbN8XVJDqYXkx90IzNi/DGnRa+XfpISkG4O8XMr 31iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=OxaT3iVFpzPOzVqF8h2OGSZaHeUMrbWluhnEbYZKs54=; b=scVdPLkL4do4SZk3luOeO9b37OCy4YQrfAGOd6t+0ho/vgQAmZaNbfe0w+/Acb4dKb BsplSLJ8LXS7NmPMzUrZ6oWCMmQ2rIe09Sl79u5Wf3VMg4LJXddDMPJvz+g3z0xwT13S eXAqKCLvL76Q3Ukx7Cxg6+ah3saeUBJsVJ+KTGoH/zhAaEzuGOEf/4xaZpWiVYP1pNYS k2uYlOs0Q9laERwRemudFyZx3MBAnU7hJhgquVIpNZTmri3abZR0ikGvHGFWcXCy3JTG Q0R5d0wPjb+vbTAFM1DM6whXYynqyV7yLy9f09HUTYgKQ0krtfSvVHf+aU+7u7Owlys8 bPGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NM9m2wmn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id k185si8775619pgd.234.2022.02.09.03.02.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 03:02:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NM9m2wmn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 453BEE04FEF8; Wed, 9 Feb 2022 01:30:52 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1388342AbiBGLne (ORCPT + 99 others); Mon, 7 Feb 2022 06:43:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1385685AbiBGLcG (ORCPT ); Mon, 7 Feb 2022 06:32:06 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B851BC0401D6; Mon, 7 Feb 2022 03:32:02 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 262C560B5B; Mon, 7 Feb 2022 11:32:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAB6EC004E1; Mon, 7 Feb 2022 11:32:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1644233521; bh=4W2tn002ITYK63bmP9hov/JOOeTD9dndTF/zgZV7jQ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NM9m2wmnnxuUSyF583pm1Uesbo0P054JKu+deh+Z4qCwlM9JNPxHrn6L4tMsoWi1B gpPbdephUtgqh+O/L687oJKVk1FBxJzn/eM7FU8twefmNX+cpkw67lW94ISuaUlbnl k1xcqtSPEAeoF5+nsakjnHLatG6D4UaRreuoIWj8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, ron minnich , ng@0x80.stream, Dominique Martinet Subject: [PATCH 5.16 021/126] Revert "fs/9p: search open fids first" Date: Mon, 7 Feb 2022 12:05:52 +0100 Message-Id: <20220207103804.797485286@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220207103804.053675072@linuxfoundation.org> References: <20220207103804.053675072@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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-kernel@vger.kernel.org From: Dominique Martinet commit 22e424feb6658c5d6789e45121830357809c59cb upstream. This reverts commit 478ba09edc1f2f2ee27180a06150cb2d1a686f9c. That commit was meant as a fix for setattrs with by fd (e.g. ftruncate) to use an open fid instead of the first fid it found on lookup. The proper fix for that is to use the fid associated with the open file struct, available in iattr->ia_file for such operations, and was actually done just before in 66246641609b ("9p: retrieve fid from file when file instance exist.") As such, this commit is no longer required. Furthermore, changing lookup to return open fids first had unwanted side effects, as it turns out the protocol forbids the use of open fids for further walks (e.g. clone_fid) and we broke mounts for some servers enforcing this rule. Note this only reverts to the old working behaviour, but it's still possible for lookup to return open fids if dentry->d_fsdata is not set, so more work is needed to make sure we respect this rule in the future, for example by adding a flag to the lookup functions to only match certain fid open modes depending on caller requirements. Link: https://lkml.kernel.org/r/20220130130651.712293-1-asmadeus@codewreck.org Fixes: 478ba09edc1f ("fs/9p: search open fids first") Cc: stable@vger.kernel.org # v5.11+ Reported-by: ron minnich Reported-by: ng@0x80.stream Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman --- fs/9p/fid.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/fs/9p/fid.c +++ b/fs/9p/fid.c @@ -96,12 +96,8 @@ static struct p9_fid *v9fs_fid_find(stru dentry, dentry, from_kuid(&init_user_ns, uid), any); ret = NULL; - - if (d_inode(dentry)) - ret = v9fs_fid_find_inode(d_inode(dentry), uid); - /* we'll recheck under lock if there's anything to look in */ - if (!ret && dentry->d_fsdata) { + if (dentry->d_fsdata) { struct hlist_head *h = (struct hlist_head *)&dentry->d_fsdata; spin_lock(&dentry->d_lock); @@ -113,6 +109,9 @@ static struct p9_fid *v9fs_fid_find(stru } } spin_unlock(&dentry->d_lock); + } else { + if (dentry->d_inode) + ret = v9fs_fid_find_inode(dentry->d_inode, uid); } return ret;