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 99F1720C001; Thu, 30 Oct 2025 06:22:18 +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=1761805340; cv=none; b=FBAzSIJ7cbUmN/G8DcPbhYiixvR8E1eQgCmx84eWbzi+bKIwiMjmBrtjhnb0/M8jt5G5Sgy7rj4jQy4KbhR7+w2P+vROXB+8tWnNfHnsmcPcAWSjWa5dJaLNu1rSQo3Gsf3N/HubaPt2mSqzGDO1RVh9xNVoirj1cdJSMVgqDVg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761805340; c=relaxed/simple; bh=H7w9rChCeFQhpDhI5O6avDItW2h4+IeSwyuf+KYa2S0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qGBfzcsCurJdgKuevnhw+wq6XDohBiFkX/COj9nyroxbQwxtgUuMHGSjm/ep0JTPfSIL17VHD+v3RqAvQDTYnLGZhQ6fUrX0LmRPfIqhrGC6nVd20grm2232Ka70XgA1w12WEUjfWhoFAFgN83j9xsA3KKvq3LiaenRKTWnm6Dw= 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=WnkiTq6p; 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="WnkiTq6p" 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=azjiGcIYmmF6n03ei+Xo/vEfAhUKiS2vQVDPHjb0ew4=; b=WnkiTq6pz7Uq+OV+DsiIUevN2v i4+1c+tR3Dcm17P/LaJSarjfL1Ugsvl96B4DrMx4AF+Lf2EbLJPA9Z219Zt8heh32e+kriF1tpzK/ ic5t92bpfL26TrynBB3H1Dkiv2CaNMiGj2l5UcXxTdzm8P4TAiTSWeMuVHy6aYs+KxZ0qOiCGuGZu x+LN+vLHwa5HFUMGcsuHAUi8LRqGYkE75CwT+/qIMNR+qnqmzzQu3rDFK4NQq8wt6Ajt1teqJvyUD BMeKZDuHoqipMl6gzKBGBP2AbBjRKNHiqqwA2AWP7rI6OkYdM838pXi+YMpM/1Fotug43yVl9A53g TxKypknw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vEM34-00000008yCG-1FE4; Thu, 30 Oct 2025 06:22:14 +0000 Date: Thu, 30 Oct 2025 06:22:14 +0000 From: Al Viro To: NeilBrown Cc: Christian Brauner , Amir Goldstein , Jan Kara , linux-fsdevel@vger.kernel.org, Jeff Layton , Chris Mason , David Sterba , David Howells , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Tyler Hicks , Miklos Szeredi , Chuck Lever , Olga Kornievskaia , Dai Ngo , Namjae Jeon , Steve French , Sergey Senozhatsky , Carlos Maiolino , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Ondrej Mosnacek , Mateusz Guzik , Lorenzo Stoakes , Stefan Berger , "Darrick J. Wong" , linux-kernel@vger.kernel.org, netfs@lists.linux.dev, ecryptfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-cifs@vger.kernel.org, linux-xfs@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Subject: Re: [PATCH v4 11/14] Add start_renaming_two_dentries() Message-ID: <20251030062214.GW2441659@ZenIV> References: <20251029234353.1321957-1-neilb@ownmail.net> <20251029234353.1321957-12-neilb@ownmail.net> Precedence: bulk X-Mailing-List: netfs@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251029234353.1321957-12-neilb@ownmail.net> Sender: Al Viro On Thu, Oct 30, 2025 at 10:31:11AM +1100, NeilBrown wrote: > +++ b/fs/debugfs/inode.c Why does debugfs_change_name() need any of that horror? Seriously, WTF? This is strictly a name change on a filesystem that never, ever moves anything from one directory to another. IMO struct renamedata is a fucking eyesore, but that aside, this: > @@ -539,22 +540,30 @@ static int sel_make_policy_nodes(struct selinux_fs_info *fsi, > if (ret) > goto out; > > - lock_rename(tmp_parent, fsi->sb->s_root); > + rd.old_parent = tmp_parent; > + rd.new_parent = fsi->sb->s_root; > > /* booleans */ > - d_exchange(tmp_bool_dir, fsi->bool_dir); > + ret = start_renaming_two_dentries(&rd, tmp_bool_dir, fsi->bool_dir); > + if (!ret) { > + d_exchange(tmp_bool_dir, fsi->bool_dir); > > - swap(fsi->bool_num, bool_num); > - swap(fsi->bool_pending_names, bool_names); > - swap(fsi->bool_pending_values, bool_values); > + swap(fsi->bool_num, bool_num); > + swap(fsi->bool_pending_names, bool_names); > + swap(fsi->bool_pending_values, bool_values); > > - fsi->bool_dir = tmp_bool_dir; > + fsi->bool_dir = tmp_bool_dir; > + end_renaming(&rd); > + } > > /* classes */ > - d_exchange(tmp_class_dir, fsi->class_dir); > - fsi->class_dir = tmp_class_dir; > + ret = start_renaming_two_dentries(&rd, tmp_class_dir, fsi->class_dir); > + if (ret == 0) { > + d_exchange(tmp_class_dir, fsi->class_dir); > + fsi->class_dir = tmp_class_dir; > > - unlock_rename(tmp_parent, fsi->sb->s_root); > + end_renaming(&rd); > + } > > out: > sel_remove_old_bool_data(bool_num, bool_names, bool_values); is very interesting - suddenly you get two non-overlapping scopes instead of one. Why is that OK?