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 AB9C935293C; Thu, 29 Jan 2026 03:21:50 +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=1769656914; cv=none; b=itfCAgUc0UDa/g6N/c4aAecMtPvcWbxKdVMD7hGNgJ1iUVJAfeM7uoZ24I1fqJjMy5yfF3TR0i7BUdswstRX4xQn9VoVUIE618F7+f7yQOpor3zy53RCywd6STAt8qxtj84CsK0uOw38MgsbkM/F9NGl3MGOvSb4D34Nh0gNA/k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769656914; c=relaxed/simple; bh=h2+N60GFIxy4GfrJ4czr9PMcmHEhojycurGHNf+1bLY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=be7oPxAUucRSbbe0UpK+GntJN6FuSqY24fC2OdqCJFITUXf1hwZHM0GCe/T0yxYKbVOsaFA0flHRoX3enE09FbLDCzIC6eLaxABIRD/qVuH0WPYI1sVNWOt1u5W9Nbizu/vK4eB15hc+XC1Xb7HG/oyZq0OI0NaqEoag3At88v8= 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=eifTeQz9; 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="eifTeQz9" 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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=BGsU9GobbaGgoU5iMsb2Tj/ECBvPozp242GaUSp9zUU=; b=eifTeQz9MUGgKqDQsKzmHBzB2j +CtwHru4Xvc8D5sL9AdjDiqJWwNUFLA4+enSb3HA8EGGjQ/KpTmT7gakB7E0zhfXtSQ15zpP5lBBg e6odg/oBWcZoX5HZCZc2eYHerpWACeqgAgw7ymX0/SYyrZbo9XVT/WadmSYd1IjR3qee35vapbO3p gJkrrQD+C4GjLabtBWnvoQ+eYIrU3CzT0XUAwBsyq/vYVwiKdr0hgb0eOuEsdsjQ5NMnVRQwtSI9G c+nAwH3W7Gnm3mac+MbhcepOrQ8lFKBi3dX17MkNJavZ/NQqs1fFtM/bhJVq1XDSm3DzyYjCgs6Ro NcMMDueg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1vlId5-0000000HVLd-0y2U; Thu, 29 Jan 2026 03:23:35 +0000 Date: Thu, 29 Jan 2026 03:23:35 +0000 From: Al Viro To: Samuel Wu Cc: Greg KH , linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org, brauner@kernel.org, jack@suse.cz, raven@themaw.net, miklos@szeredi.hu, neil@brown.name, a.hindborg@kernel.org, linux-mm@kvack.org, linux-efi@vger.kernel.org, ocfs2-devel@lists.linux.dev, kees@kernel.org, rostedt@goodmis.org, linux-usb@vger.kernel.org, paul@paul-moore.com, casey@schaufler-ca.com, linuxppc-dev@lists.ozlabs.org, john.johansen@canonical.com, selinux@vger.kernel.org, borntraeger@linux.ibm.com, bpf@vger.kernel.org, clm@meta.com, android-kernel-team Subject: Re: [PATCH v4 00/54] tree-in-dcache stuff Message-ID: <20260129032335.GT3183987@ZenIV> References: <20251118051604.3868588-1-viro@zeniv.linux.org.uk> <2026012715-mantra-pope-9431@gregkh> <20260128045954.GS3183987@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Al Viro On Wed, Jan 28, 2026 at 04:58:57PM -0800, Samuel Wu wrote: > On Tue, Jan 27, 2026 at 8:58 PM Al Viro wrote: > > > Very interesting... Does 1544775687f0 (parent of e5bf5ee26663) > > demonstrate that behaviour? > > Reverting only 1544775687f0 (functionfs: need to cancel ->reset_work > in ->kill_sb()) does not fix the issue. With 6.19-rc7 as baseline, the > simplest working recipe at the moment is with 6ca67378d0e7, > c7747fafaba0, and e5bf5ee26663 reverted. Sorry, I hadn't been clear enough: if you do git switch --detach 1544775687f0 and build the resulting tree, does the breakage reproduce? What I want to do is to split e5bf5ee26663 into smaller steps and see which one introduces the breakage, but the starting point would be verify that there's no breakage prior to that. PS: v6.19-rc7 contains fc45aee66223 ("get rid of kill_litter_super()"), and reverting 6ca67378d0e7 ("convert functionfs") would reintroduce the call of that function in ffs_fs_kill_sb(), so the resulting tree won't even build on any configs with functionfs enabledd; are you sure that you'd been testing v6.19-rc7 + reverts of just these 3 commits?