From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id CE95C8015C for ; Mon, 21 Sep 2026 15:11:03 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 68LF9hEW007135; Mon, 21 Sep 2026 18:09:43 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68LF9hEW007135 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="ca9Nft9Q" Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 68LF9f5R007131 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Mon, 21 Sep 2026 18:09:41 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68LF9f5R007131 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-4870a0fe60fso1596024f8f.2 for ; Mon, 21 Sep 2026 08:09:41 -0700 (PDT) X-Forwarded-Encrypted: i=2; AKwUvBxFj/pox8yoPkgfAyUN/7youO7Bmg5AlCBJ0H6bLR9OVkKmjwnKq9+D0tfKWV4ltStZSZCzew==@openvz.org X-Gm-Message-State: AFuF++mjq7mkGFNmjcHyesPi/3qwV0HtUzy/DvAbru8zlEt4IODQQqU3 4QrcKBO7FcGliRHKfmYRDkzWjE7FqBrU1z/ptS2GcmnTa3zkR7Q3RtWfbGHzJ9FXqERbQ5x7jUW A8N5ftfimeGY0fcntqvm1UOF9ThVJUVBjA8PCPzKuoMKX6naVwdA/hQ== X-Gm-Gg: AYBFou11XXOjj+J/tuarn5nMinnTILNpm4i6Y8FDjR4pEzTNKCPEDFV4Q3CSvTFxLVi r5hc9g6SIbN0a+vEh4zIZxOLde88QSugbuMDlFbS/UQmrH8hfGiyftECf/lOMlHxSHyq0yWDLVx 02/cCGy6baMUwZWqvHt55TNnsvf+rK/pwJuHl64tVmuqTJtH6SUA6hLmphUWs1ZkJp5WqO2orpA OwNhCjRaHgxY8UXXaSjz5iyws/0/xGg3SI6uj2lBxHAnWLFFe45hqhDP1zfzfK1yqZ13cNy91tW IzDEnuyXgdnczkMwTnx5J9k7syoE8qdyCj027Z6uiMZXlIwSHyEvhxgfimNlrlqzMuiFayKIY/k ekS5pCr3V1uzDiWAQ X-Received: by 2002:a05:6000:2201:b0:487:725:8204 with SMTP id ffacd0b85a97d-4871e36bf42mr16017912f8f.44.1790003381301; Mon, 21 Sep 2026 08:09:41 -0700 (PDT) X-Received: by 2002:a05:6000:2201:b0:487:725:8204 with SMTP id ffacd0b85a97d-4871e36bf42mr16017866f8f.44.1790003380792; Mon, 21 Sep 2026 08:09:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1790003380; cv=none; d=google.com; s=arc-20260327; b=Sd7pGkRdgBun+o48NhvbXlneEo81ZX+CGHiu1F5afRWd0E67bxsVDRgAgxVpHhhffy KgP3opkgXYFHrUw0CSXDegGvLXTfZd5N+OyU82E12P7loS71doQFRNaqNy5tfbzIsLw3 Du7BuyV///YODRPe6Dd9zc0TdIJ3CfNSY9Ba3f5hgyItbTZjqk/HnW1Ii3lMY3ZEBeGG PQGWRDA6dCvUO9Jz28/K15PpeDEqDu5plHqdzXfnWkm8bULY39tYymWchxxyccJxDrpB t+KksWVEDGViHi05Q1BqnE8WIl6Nz0v6YFIKrJ7q7ODAtOaxMOZuixuSWrJrNCzMiOYx dsDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=message-id:date:references:in-reply-to:cc:to:from:subject :content-transfer-encoding:mime-version:dkim-signature; bh=mkHLGMr3Nj/Ei+4sE1Us8N4TKH8zAsFu67dMbJmlXxs=; fh=puM6OxU5KZDBHIwZjPtszZsZlhBrC1PmVvuThr6+lTo=; b=Amd9k5Ba6XMN4gyuYz2jKBr0UtGJXg+WgZBaxt5cxMsMmBgjXRsldhx05ZORypg/RE Cw37FzGMGjJb1QcxGQTNTv3FoGlGy3/h1+K7s+KQgmLEcY4Gz7y0+XG5kaEQj+Poo5lf j+FiQlSaQpzyG2farNzvoc3TRA5pYzJLMi5mNvdknf0Ik/aLqRn0UauI0PfjO8G3ZIfu H/1pbRzqb1hZ5HkOotN0y8lSqhE5fN9lBItgWf/rv0QkP5mIJJPH9ueEZ5g34n6iP0yT rMv+f5X/nRAQmof9AHJxb05aguIm5RszUNmLAknOaGpCT9lHuEU0zZ4+4poivrWJTklw J+tw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=ca9Nft9Q; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-487245a9e5bsi14777940f8f.358.2026.09.21.08.09.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 08:09:40 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=ca9Nft9Q; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Message-Id:Date:From:Subject:Content-Type: MIME-Version; bh=mkHLGMr3Nj/Ei+4sE1Us8N4TKH8zAsFu67dMbJmlXxs=; b=ca9Nft9Q1aB3 /q0HIVR3yVR6NaZjhNAzLhZpoQlgyySCnPKTrbY/VM/lxwZfM+OXoQX6/uPYn6Nb09Slk/kn78RYo hqlxSigfx9Uuluk6NLFvyPc77BpQeV3JbO6x7pxH59w5y5nHkBF3TnoMibDG7GNwFoBXa+BjY+0lR yfxcjSokyzhMuZbQeruQ4W2CbmtEThiov0tYDyiwn0LY0rIXP3ngNh4Q3nIJsXI7oE8mwrKvPQ7vG 0wwA/jWtZL05rmbEASd1+RM/5WAMosSlYV3s3TSmcin1qD+9ZtGCM/3XeU7q1sVWW2lt9o4YW4Mo9 OzQ9jtvMeEHAyJwVaPSLgw==; Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=f0.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1x8fbO-003Nf6-0g; Mon, 21 Sep 2026 17:09:31 +0200 MIME-Version: 1.0 From: Konstantin Khorenko To: Liu Kui In-Reply-To: <20260918-vstor-145614-writectr-v1-1-588a9eff3aa3@virtuozzo.com> References: <20260918-vstor-145614-writectr-v1-1-588a9eff3aa3@virtuozzo.com> Date: Mon, 21 Sep 2026 17:09:36 +0200 Message-Id: <179000337661.2953935.5887806686603853170.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5107; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=oh8c/kGUpaDVlP5HTUOV+lyeXR+7Mo3+N6pcgSwrNyk=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBqsUizeIRWq7/e1QASGKmj9orWGNpMuItA2SSet 4x5Zwo8kxaJAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCarFIswAKCRBRlgpH+WFc Kp61D/97tVM6p4k10eAPLzTm7BaP3kWuFQE31yzgDe4azgdT3cTM1aWX7S4A14s8MwZ/7B/3RyQ 5PJ+lfTrS5tT+oMBnwTPc+Xz8nng9viUUbJ9B1OA0GOllxKL4wzCoXX0KhGFatflh4wgjnSy8mV olNXBji8I178VNBgZjOPnvxUYMHOh5gIbFN7LnsZahEsgCk09MwNgZi9pMYO/TKtlmHxueCaIW6 Y7r6yVTWlG7WPy+6tYXZe0QLntpSiypjyR1HapssYUg1iiMj/PctH4s6Z/OKKfFWC0mnBNyRhtD S7R0f8GFksidT2acMZHOcgZpgwuG+v1BVnIdpEu21WrFP9JnPmf1tD2OFKbneHvRhLYCdXi6pVt tmjtTy0KNTH3pkcS1pitNhasZiVOrpmW1Ocfi/IEw5ZIgmzBVJwgrSpwfvQQr9HkVdi33BmyqY+ hLFYz7KVbckxbwmqJxaQhdFlb88cnjyAxeSuCuStXN4Ni+5QIM9ihVoTuhLMXqpkHm6pNu1Tn4H oU7r3bkwaw9O5qma9XJlxU/GI7aOBthpVqSvHk267yQh2lktq+nGXwzsKwXOWoer82DBNx3StWT JcYJBNWf5jPH67Vvndr4WPJGxaklQij73OQf4mZ9siHvGudTv0i+TKUJ7Rrec8cp7Z179+UkaGZ NVUqC2yvSReGArA== X-Developer-Key: i=khorenko@virtuozzo.com; a=openpgp; fpr=560F6DC83DC5D3D063BD082C51960A47F9615C2A X-OZ-Fwd: true Cc: devel@openvz.org, azaitsev@virtuozzo.com Subject: Re: [Devel] [PATCH hci-8.0] fs/fuse: fix writectr imbalance when failing writeback of invalidated file X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org > The shoot-on-sight path in fuse_writepages_send() for files being > invalidated violates the writectr protocol: the increment is not > gated on writectr >=0, and the matching decrement lives in a separate > fi->lock critical section. A concurrent fuse_set_nowrite() and > fuse_release_nowrite() pair lands in that window observes writectr == > FUSE_NOWRITE + 1 and triggers BUG_ON(fi->writectr != FUSE_NOWRITE) in > __fuse_release_nowrite(): > > kernel BUG at fs/fuse/dir.c:1842! > RIP: fuse_release_nowrite+0x45/0x50 [fuse] > fuse_release+0xd0/0x300 [fuse] > __fput+0xe1/0x2a0 > __x64_sys_close+0x3c/0x80 > > Fix it by always routing writeback through fi->queued_writes so the > writectr gating applies, and failing requests on invalidated files > in fuse_send_writepage() instead, where the existing out_free path > keeps the writectr increment and decrement balanced within a single > fi->lock critical section. Note that if a NOWRITE section is active, > queue the request instead of failing it immediately is harmless for > the file invalidation operation. > > https://virtuozzo.atlassian.net/browse/VSTOR-145614 The ungated fi->writectr++ under FUSE_S_FAIL_IMMEDIATELY was added to fuse_writepages_send() by 2d23aac3630e, so: Fixes: 2d23aac3630e ("fuse: fix writeback/release race") ? > > Signed-off-by: Liu Kui > > diff --git a/fs/fuse/file.c b/fs/fuse/file.c > index c96a631b95292..180f60fc539a5 100644 > --- a/fs/fuse/file.c > +++ b/fs/fuse/file.c > @@ -2237,6 +2237,11 @@ __acquires(fi->lock) > int err; > > fi->writectr++; > + if (fuse_file_fail_immediately(wpa->ia.ff)) { > + /* File is under invalidation: fail request without sending */ > + mapping_set_error(wpa->inode->i_mapping, -EIO); > + goto out_free; > + } [Severity: Medium] Does the out_free path drop the fuse_file references held by the auxiliary requests on a close_wait mount? Every wpa created in fuse_writepages_fill() takes its own reference: fs/fuse/file.c:fuse_writepages_fill() { ... wpa = fuse_writepage_args_setup(folio, data->ff); ... fuse_file_get(wpa->ia.ff); ... } and when fuse_writepage_add() finds the page already under writeback the new wpa is chained onto old_wpa->next and keeps that reference. The two release points are split by fc->close_wait: fs/fuse/file.c:fuse_writepage_finish() { ... if (wpa->ia.ff && fc->close_wait) __fuse_file_put(wpa->ia.ff); ... } fs/fuse/file.c:fuse_writepage_free() { ... if (wpa->ia.ff && !fc->close_wait) fuse_file_put(wpa->ia.ff, false); ... } The out_free path this change now jumps to calls fuse_writepage_finish() for the primary only. The auxiliary requests get fuse_writepage_finish_stat() and fuse_writepage_free(): fs/fuse/file.c:fuse_send_writepage() { ... out_free: fi->writectr--; rb_erase(&wpa->writepages_entry, &fi->writepages); fuse_writepage_finish(wpa); spin_unlock(&fi->lock); /* After rb_erase() aux request list is private */ for (aux = wpa->next; aux; aux = next) { next = aux->next; aux->next = NULL; fuse_writepage_finish_stat(aux->inode, aux->ia.ap.pages[0]); fuse_writepage_free(aux); } ... } With fc->close_wait set, neither call puts aux->ia.ff, so each auxiliary request leaves one reference on the fuse_file behind. Before this change a request for a FUSE_S_FAIL_IMMEDIATELY file never sat in fi->queued_writes, so an auxiliary request could only attach to a primary that was already in flight, and that primary was completed through fuse_writepage_end(), which resends each aux with fuse_send_writepage() and so ends up in fuse_writepage_finish() for it. Now the request waits in fi->queued_writes while fuse_set_nowrite() is active (truncate, fsync, or open with truncate on another file). If the page is redirtied in that window, which fuse_writepage_need_send() documents as possible for a direct read into an mmapped page, the next writeback pass chains an aux onto the queued primary. When __fuse_release_nowrite() finally sends it, this new check takes out_free and the aux references are lost. On a close_wait mount that reference is what fuse_release() waits for: fs/fuse/file.c:fuse_release() { ... if (fc->close_wait) wait_event(fi->page_waitq, refcount_read(&ff->count) == 1); ... } There is no timeout and nothing else drops the count, so close() on that file would never return. The same gap already exists for the "Got truncated off completely" and broken-connection exits of out_free, so this is not new code, but this change makes out_free the regular completion path for every invalidated file. Should the aux loop in out_free call fuse_writepage_finish() (or otherwise do the close_wait __fuse_file_put()) for each aux, either in this patch or in a fix preceding it? > if (inarg->offset + data_size <= size) { > inarg->size = data_size; > } else if (inarg->offset < size) { [ ... ] -- Konstantin Khorenko _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel