All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Liu Kui <kui.liu@virtuozzo.com>
Cc: azaitsev@virtuozzo.com, devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.0] fs/fuse: fix fuse file refcount leak on close_wait writeback
Date: Tue, 22 Sep 2026 17:37:33 +0200	[thread overview]
Message-ID: <c6ebabcd-a826-4ba4-87ed-deb5fa90ef86@virtuozzo.com> (raw)
In-Reply-To: <20260922-vstor-145614-v1-1-e14dd025e85a@virtuozzo.com>

On 9/22/26 15:53, Liu Kui wrote:
> Mainline commit 4046d3adcca4 ("fuse: move fuse file initialization to
> wpa allocation time") moved acquisition of the wpa's fuse file
> reference from submit time (fuse_writepages_send) to wpa allocation
> time, and compensated by dropping the reference unconditionally in
> fuse_writepage_free().
> 
> This breaks the close_wait accounting in the vz tree, which splits the
> drop between two functions: fuse_writepage_finish() does
> __fuse_file_put() for close_wait (allowing fuse_release() to pass
> wait_event(ff->count == 1)), while fuse_writepage_free() puts the
> reference only for !close_wait. This split requires that every wpa
> owning a reference passes through fuse_writepage_finish() before being
> freed. Two paths free a wpa without calling it:
> 
>   - fuse_writepage_add(): temp page swap case frees the new wpa
>   - fuse_send_writepage(): out_free path frees the aux request chain
> 
> Before that commit these paths only ever saw wpas with ia.ff == NULL
> (never submitted or promoted), so nothing leaked. After it, every wpa
> owns a reference from birth, and on close_wait mounts both paths leak
> it: ff->count never returns to 1, fuse_release() hangs forever in
> wait_event(), and the fuse file and its FUSE_RELEASE are leaked.
> 
> Fix it by reverting to the old ownership model for the writeback path:
> a wpa is allocated with ia.ff = NULL and acquires the reference at
> submit time (fuse_writepages_send, fuse_writepage_locked) or at aux
> promotion time (fuse_writepage_end). Also make fuse_writepage_free()
> derive fuse_conn from wpa->inode since ia.ff may now legitimately be
> NULL there.
> 
> Note: this is effectively a revert of the mainline change for the
> writeback path. It can be restored later on a rework of the close_wait
> accounting (e.g. dropping the finish/free split in favour of an
> unconditional put).
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-145614

  Fixes: 6b5ddd8253eb ("fuse: Wait for real writeback to finish on file")
  Feature: vStorage

?


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

  reply	other threads:[~2026-09-22 15:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 13:53 Liu Kui
2026-09-22 15:37 ` Konstantin Khorenko [this message]
2026-09-22 15:54 ` Konstantin Khorenko
2026-09-22 18:54 ` Konstantin Khorenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6ebabcd-a826-4ba4-87ed-deb5fa90ef86@virtuozzo.com \
    --to=khorenko@virtuozzo.com \
    --cc=azaitsev@virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=kui.liu@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.