From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B34C79F2; Sat, 5 Jul 2025 00:25:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751675142; cv=none; b=pf8OR0V1QnRe8oWQGLleTLCWqTj9mr3J5+T8jipzqYoGlAkUcYqQe0ILBJwndEQBlodIoD6CHieyXXr5Su5JttqVenbqEACK2FS41Oll/rRpEPCNIVQvHPDCqcXhdGtxE6uZe++3qw36QBRDK82SVWhRhTikBmVafPDVTnBhlVI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751675142; c=relaxed/simple; bh=BeQeTfmyYnm2mOzsi53634ox7T6k5A28RilZNxYG6lo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MekupcZh5ZaPDodzkYg1GrekcOEv5ABMUb312EYc/zdOHN6yD0ydjeLzMDvjcRScTQCdiCuQ2z78J2oHFXXERHTnQ8kJro5WUQdzPPhGdz6k5+Ffu4b5JElE2CRdVxgefvFmQAAdm8E5nA52ilrykkurbWDtpaoC1rB09B9zhgY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=rir315Ua; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="rir315Ua" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=XwhfMgFq3ICeCByvEN6EISqFtxiGdSUTFXxixMwtQCs=; b=rir315UajBgbPeDrAOAOJfKkJ7 y+C4vyqiJWdGmy+lxxnZr90QpWrbrff7kRU0cJ/yKNiIJx7vfd5vF3OFzxQH45pq8XssJcldqQLbk JSbxHR6YssgyCrtMgEDGAFugN5L82G9qfaR6A8haClZTE6DbbrusMd7ghNTnJLzI/SHrWXcLnbNL8 QBgZjET8shnJztCRFuPdroohVDTlbYNbMXlMG9z2Vct+wIqbOJDTQywQHE57+I0oZI+W/OLIDWSav tmxpRm5AF+CLxLGgiRnFCAof5jpuABsz3w19dD6R1PVa18Pfw6ZMAPCsohY5xbllN8AnRy1gT5rLQ ogw2rf5w==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uXqim-0000000GAip-46EE; Sat, 05 Jul 2025 00:25:37 +0000 Date: Sat, 5 Jul 2025 01:25:36 +0100 From: Al Viro To: Tingmao Wang Cc: Eric Van Hensbergen , Dominique Martinet , Latchesar Ionkov , Christian Schoenebeck , v9fs@lists.linux.dev, =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , =?iso-8859-1?Q?G=FCnther?= Noack , linux-security-module@vger.kernel.org, Jan Kara , Amir Goldstein , Matthew Bobrowski , linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 1/6] fs/9p: Add ability to identify inode by path for .L Message-ID: <20250705002536.GW1880847@ZenIV> References: Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro On Sun, Apr 06, 2025 at 09:43:02PM +0100, Tingmao Wang wrote: > +bool ino_path_compare(struct v9fs_ino_path *ino_path, > + struct dentry *dentry) > +{ > + struct dentry *curr = dentry; > + struct qstr *curr_name; > + struct name_snapshot *compare; > + ssize_t i; > + > + lockdep_assert_held_read(&v9fs_dentry2v9ses(dentry)->rename_sem); > + > + rcu_read_lock(); > + for (i = ino_path->nr_components - 1; i >= 0; i--) { > + if (curr->d_parent == curr) { > + /* We're supposed to have more components to walk */ > + rcu_read_unlock(); > + return false; > + } > + curr_name = &curr->d_name; > + compare = &ino_path->names[i]; > + /* > + * We can't use hash_len because it is salted with the parent > + * dentry pointer. We could make this faster by pre-computing our > + * own hashlen for compare and ino_path outside, probably. > + */ > + if (curr_name->len != compare->name.len) { > + rcu_read_unlock(); > + return false; > + } > + if (strncmp(curr_name->name, compare->name.name, > + curr_name->len) != 0) { ... without any kind of protection for curr_name. Incidentally, what about rename()? Not a cross-directory one, just one that changes the name of a subdirectory within the same parent?