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 A7DEC312821; Thu, 29 Jan 2026 22:52:47 +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=1769727170; cv=none; b=kKJ931DHzk2Qtjhj0j5m+M58pYR+zekcb/nvSOLMv3epNKvb9YLdlGDbw1LWtkp4Ppbvak9Epa677intNAtuHSiJGW7/te98RoiO7PM1/ZwJvqNUEaoIXQeJJH0a+mD04VIh7Tb7camqVILHx1ScBTtCuytRKKxE9ts9DNs8ky0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769727170; c=relaxed/simple; bh=a+uuu1UU4KTBHLlqRmYyRypp9XGFjSD6Z3KeUdDHXDw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qsq4Wkxvo8ZViy70tHOYjIkqZ+/GRW7TPqNSpX0dI/QEDxTfC0EZ39eS3PYmuyFPCC1azWMf8GHGv1ucvK5XMdmsShKTyFhqz/9mEmbsj/KMLLJk5ZRvN1vXeKOamcVpdt9zPRVR42MpAHwswY3mx9N4/x3CgKS+ixfXWw5iiv4= 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=Xd3s3aE8; 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="Xd3s3aE8" 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=NzC4ieMh6vmoXuGrRF8AJfVTPzFDIVwsq0W+97NeH6I=; b=Xd3s3aE8lP0Iuf76XmQmTqyylY kyjYtmWz3WE5Wp7qeyPuSNsrn7VnrFKLBLvg1QeejST/l0HFm8A1qmVzFffJgrhLWXrFqbyf6a33e /22zqtNz8ozygjvj4by61/hPWVbdmEB1InvlYHMIf70seSv2TGIK6fBViv/wS7HAbDGRBmDvmj2ZB JntUzR5O2yOGBeO5kVkWDZ996QY77yEhYaT27vlMP0zpBJ3x2kyXvwFS0IvjUmVIU8AbZJaqR0rdb wrNWss8rPX4hfCo90x1Ou0DJDoWZBnnF+jopJxNrM5FqeIqToCi5KntAUvJccM6KN/Cc2/WSy2jpw jyJAcUeA==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1vlauH-00000007wty-0EGP; Thu, 29 Jan 2026 22:54:33 +0000 Date: Thu, 29 Jan 2026 22:54:33 +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: <20260129225433.GU3183987@ZenIV> References: <20251118051604.3868588-1-viro@zeniv.linux.org.uk> <2026012715-mantra-pope-9431@gregkh> <20260128045954.GS3183987@ZenIV> <20260129032335.GT3183987@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: <20260129032335.GT3183987@ZenIV> Sender: Al Viro On Thu, Jan 29, 2026 at 03:23:35AM +0000, Al Viro wrote: > 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? Could you try your reproducer on mainline with the following delta applied? diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 05c6750702b6..6c6d55ba0749 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -646,12 +646,11 @@ static int ffs_ep0_open(struct inode *inode, struct file *file) if (ret < 0) return ret; - ffs_data_opened(ffs); if (ffs->state == FFS_CLOSING) { - ffs_data_closed(ffs); mutex_unlock(&ffs->mutex); return -EBUSY; } + ffs_data_opened(ffs); mutex_unlock(&ffs->mutex); file->private_data = ffs;