From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8AEA4CCD19A for ; Tue, 18 Nov 2025 05:17:22 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4d9Xs45F66z2xnh; Tue, 18 Nov 2025 16:16:24 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip="2a03:a000:7:0:5054:ff:fe1c:15ff" ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1763442983; cv=none; b=gh7QA/ejWlXm9livN9w8/DkBjb9mRky8iw0Et8scMUi2k87gsALFZJPKVK+85yZVKzwevPBn8Wjxqck0GO0VfLYwd6MiA4XeUtfwVgUABp5SKpg5Xs82Cd+JguN7cljX2vdtrfuJL//1kDmiwUBNWDgqeEBImaM7ovPkrTRa2w0DDXtZbTVxoZo2NTR/JHddZ7ZbyPWCuLuz1PLhUi4WDRJRCfp+8EqpwJTWGJyRMmcJLV4tLahttjV5Glzz0V9YgLgC+42T07Tw6uSBSFsWr/QfpoNOsvD9nTkweoxduGOJalA+yS08FGVfNyvk4MN/yFgN8FX9W4Tcyc/b+U5Lqw== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1763442983; c=relaxed/relaxed; bh=vEaGjhrzoRqqbrs71dNJ6HrGl1f3Qp25lPEbTwESe/A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lNE4hnplKbwu3jhf6yHzlFyZxYRbX93YrM45DxcWUDeNmAMfWA6ltsAXYtpEz7COkxHGPjVO5vHE7gRd3GnS5tdu2bKrE0nuuuF3dpC8z0smZR4jfIiAPk0P4sXUZ+p+dW70Y8RHH1OmHYA1qZXTtQnWeK81uDdL1B8UFWfPU4tvj6xqXDRM83MoCbXaXb9TQG/p9UPk7Y8wmwTNf/n1FtEJYFYMGAPH3rgEhgvPIIwiHyNMCocXqVu5LCUrgOtnwaJhXGMWQevehQERevmBh/c3i7utKEeYj3xzSL9ecJza/EYJu1I8pTulc7NI3nrAY4cymK7trA4hmxPuiHgGpg== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; dkim=pass (2048-bit key; unprotected) header.d=linux.org.uk header.i=@linux.org.uk header.a=rsa-sha256 header.s=zeniv-20220401 header.b=jVHHtkle; dkim-atps=neutral; spf=none (client-ip=2a03:a000:7:0:5054:ff:fe1c:15ff; helo=zeniv.linux.org.uk; envelope-from=viro@ftp.linux.org.uk; receiver=lists.ozlabs.org) smtp.mailfrom=ftp.linux.org.uk Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=linux.org.uk header.i=@linux.org.uk header.a=rsa-sha256 header.s=zeniv-20220401 header.b=jVHHtkle; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=ftp.linux.org.uk (client-ip=2a03:a000:7:0:5054:ff:fe1c:15ff; helo=zeniv.linux.org.uk; envelope-from=viro@ftp.linux.org.uk; receiver=lists.ozlabs.org) Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4d9Xry2DVtz30Tc for ; Tue, 18 Nov 2025 16:16:17 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=vEaGjhrzoRqqbrs71dNJ6HrGl1f3Qp25lPEbTwESe/A=; b=jVHHtklen2k+/O6FtBxrGXYHsu B+ny9v20XP6xtEfoYk0NPqCupcKyoARuorYPrezPT4o+4zEzbFkfpT4nuTWhhWAxVHnG9QAuo55kF FGvWizwnkqSk1YOyW03kY0taLGCy8rxi9f5/y7JT7RaSZy8Vd/fqVMhJzcMVWCJC8wMIwYSipy3uE +KH5tzbWzTOiC7VspSMCoCeIhxPO5ZOT6LeNmNP6hB2MI2Nxv0BmgZJOP16bOkgp0KmUbdnw2EmvE tYUmLb5X3k+3lhxcYmGgfmfVbjSjjNjko/4uQfQK5hHmFbbVYMYBe1U+xQuGcB/ZBnJe8m0F/pPFP uTRaK5Jg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vLE4W-0000000GETE-464y; Tue, 18 Nov 2025 05:16:09 +0000 From: Al Viro To: linux-fsdevel@vger.kernel.org Cc: 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, gregkh@linuxfoundation.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 Subject: [PATCH v4 36/54] functionfs: don't abuse ffs_data_closed() on fs shutdown Date: Tue, 18 Nov 2025 05:15:45 +0000 Message-ID: <20251118051604.3868588-37-viro@zeniv.linux.org.uk> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20251118051604.3868588-1-viro@zeniv.linux.org.uk> References: <20251118051604.3868588-1-viro@zeniv.linux.org.uk> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: Al Viro ffs_data_closed() has a seriously confusing logics in it: in addition to the normal "decrement a counter and do some work if it hits zero" there's "... and if it has somehow become negative, do that" bit. It's not a race, despite smelling rather fishy. What really happens is that in addition to "call that on close of files there, to match the increments of counter on opens" there's one call in ->kill_sb(). Counter starts at 0 and never goes negative over the lifetime of filesystem (or we have much worse problems everywhere - ->release() call of some file somehow unpaired with successful ->open() of the same). At the filesystem shutdown it will be 0 or, again, we have much worse problems - filesystem instance destroyed with files on it still open. In other words, at that call and at that call alone the decrement would go from 0 to -1, hitting that chunk (and not hitting the "if it hits 0" part). So that check is a weirdly spelled "called from ffs_kill_sb()". Just expand the call in the latter and kill the misplaced chunk in ffs_data_closed(). Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro --- drivers/usb/gadget/function/f_fs.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 47cfbe41fdff..43926aca8a40 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -2071,12 +2071,18 @@ static int ffs_fs_init_fs_context(struct fs_context *fc) return 0; } +static void ffs_data_reset(struct ffs_data *ffs); + static void ffs_fs_kill_sb(struct super_block *sb) { kill_litter_super(sb); - if (sb->s_fs_info) - ffs_data_closed(sb->s_fs_info); + if (sb->s_fs_info) { + struct ffs_data *ffs = sb->s_fs_info; + ffs->state = FFS_CLOSING; + ffs_data_reset(ffs); + ffs_data_put(ffs); + } } static struct file_system_type ffs_fs_type = { @@ -2114,7 +2120,6 @@ static void functionfs_cleanup(void) /* ffs_data and ffs_function construction and destruction code **************/ static void ffs_data_clear(struct ffs_data *ffs); -static void ffs_data_reset(struct ffs_data *ffs); static void ffs_data_get(struct ffs_data *ffs) { @@ -2171,11 +2176,6 @@ static void ffs_data_closed(struct ffs_data *ffs) ffs_data_reset(ffs); } } - if (atomic_read(&ffs->opened) < 0) { - ffs->state = FFS_CLOSING; - ffs_data_reset(ffs); - } - ffs_data_put(ffs); } -- 2.47.3