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 C749033555F for ; Fri, 23 Jan 2026 00:35:13 +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=1769128523; cv=none; b=aQvCFy/IuEJmER29jZFu0YSKWtOewzEXocZ9ZM2LxypETjugVpQI6ladxP1C1TLBC+2Dvq83PF4VTWO8MhKnkrCkymqM2cFvGhE5OUZlx+akQ5GDoCMnm2Sm0P/caByrm7P/DRjp6ZXNqB1/cvv8AeV/3UsOs3onjP4aXesp71c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769128523; c=relaxed/simple; bh=eP61JBRIVRbFbol+02mYcO07gAQGmMkyJf5+xCYd2JA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=d4DAfpy9fHeNcGUsVvitt21FBWD4rkgLiOwch5/+G89Ue2CVUnIrGiDQjpj8NsoxQZPp7fyk6k7oLHIAgHWLOkjMrrfzNxv1Izy2qAx+s3+qVxmbHO5KUoSg/krTJzXvyy5/Pr0vkM+nNcPBFxJ6dxhHF2vlq36BRhShtKSFvuc= 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=ZMxdkN8I; 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="ZMxdkN8I" 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=0tOYeDoU4/E4b6+1OEKEKixKU2p+ACg3Gd9swuYqwKg=; b=ZMxdkN8IGaHUarQ5OnSH6m1hYU Uifc6ntFmoEF3NU4FqehHVoy3W0g9L5KDPxhddXuPYV8jHkv76GsrLdRxfmcceEzsIHcpEefD/pWw fYs+UJMViIToTq2+LTiY5UqAnL37VWOWy61XqVPwth3F78VmokEVnzRlyy4Xbhhnhs2WxvPAz7sMm 0zDW6ziCk29I90h/TPSkm12SCwmTmbvQ4BhJ7Y1iL+gHsWsjIWsFlMIeCgdpknCDcyYG4kg+be+Gh 2El/vZU5DzS6QWphI+VZa8VDjxiI5kn5vp43/AUIjlJga91oVyEca+nW50H3AmBOt/S9oL2RkltYx auSzaDzQ==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1vj5AR-0000000GBas-48m2; Fri, 23 Jan 2026 00:36:52 +0000 Date: Fri, 23 Jan 2026 00:36:51 +0000 From: Al Viro To: Linus Torvalds Cc: linux-fsdevel@vger.kernel.org, Christian Brauner , Jan Kara , Nikolay Borisov , Max Kellermann Subject: Re: [PATCH][RFC] get rid of busy-wait in shrink_dcache_tree() Message-ID: <20260123003651.GH3183987@ZenIV> References: <20260122202025.GG3183987@ZenIV> 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 Thu, Jan 22, 2026 at 04:19:56PM -0800, Linus Torvalds wrote: > On Thu, 22 Jan 2026 at 12:18, Al Viro wrote: > > > > +static inline void d_add_waiter(struct dentry *dentry, struct select_data *p) > > +{ > > + struct select_data *v = (void *)dentry->d_u.d_alias.next; > > + init_completion(&p->completion); > > + p->next = v; > > + dentry->d_u.d_alias.next = (void *)p; > > +} > > I tend to not love it when I see new users of completions - I've seen > too many mis-uses - but this does seem to be a good use-case for them. > > That said, I absolutely abhor your cast. Christ - that 'd_u' is > *already* a union, exactly because that thing gets used for different > things - just add a new union member, instead of mis-using an existing > union member that then requires you to cast the data to a different > form. > > Yes, you had an explanation for why you used d_alias.next, but please > make that explanation be in the union itself, not in the commit > message of something that mis-uses the union. Please? > > That way there's no need for a cast, and you can name that new union > member something that also clarifies things on a source level > ("eviction_completion" or whatever). > > Or am I missing something? In practice it doesn't really matter, but we don't want to initialize that field to NULL - no good place for doing that. Sure, the entire d_alias has been subject to hlist_del_init() or INIT_HLIST_NODE(), so any pointer field unioned with it will end up being NULL without any assignments to it, but... ugh. "We have a union of two-pointer struct, a pointer and some other stuff; we'd set both members of that struct member to NULL and count upon the pointer member of union having been zeroed by that" leaves a bad taste.