linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>,
	gregkh@linuxfoundation.org, peterz@infradead.org,
	lujialin4@huawei.com, lizefan.x@bytedance.com,
	hannes@cmpxchg.org, mingo@redhat.com, ebiggers@kernel.org,
	oleg@redhat.com, akpm@linux-foundation.org,
	viro@zeniv.linux.org.uk, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	bristot@redhat.com, vschneid@redhat.com,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file
Date: Tue, 27 Jun 2023 08:42:28 -1000	[thread overview]
Message-ID: <ZJstlHU4Y3ZtiWJe@slm.duckdns.org> (raw)
In-Reply-To: <20230627-ausgaben-brauhaus-a33e292558d8@brauner>

Hello, Christian.

On Tue, Jun 27, 2023 at 07:30:26PM +0200, Christian Brauner wrote:
...
> ->release() was added in
> 
>     commit 0e67db2f9fe91937e798e3d7d22c50a8438187e1
>     kernfs: add kernfs_ops->open/release() callbacks
> 
>     Add ->open/release() methods to kernfs_ops.  ->open() is called when
>     the file is opened and ->release() when the file is either released or
>     severed.  These callbacks can be used, for example, to manage
>     persistent caching objects over multiple seq_file iterations.
> 
>     Signed-off-by: Tejun Heo <tj@kernel.org>
>     Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Acked-by: Acked-by: Zefan Li <lizefan@huawei.com>
> 
> which mentions "either releases or severed" which imho already points to
> separate methods.

This is because kernfs has revoking operation which doesn't exist for other
filesystems. Other filesystem implemenations can't just say "I'm done. Bye!"
and go away. Even if the underlying filesystem has completely failed, the
code still has to remain attached and keep aborting operations.

However, kernfs serves as the midlayer to a lot of device drivers and other
internal subsystems and it'd be really inconvenient for each of them to have
to implement "I want to go away but I gotta wait out this user who's holding
onto my tuning knob file". So, kernfs exposes a revoke or severing semantics
something that's exposing interface through kernfs wants to stop doing so.

If you look at it from file operation implementation POV, this seems exactly
like ->release. All open files are shutdown and there won't be any future
operations. After all, revoke is forced closing of all fd's. So, for most
users, treating severing just like ->release is the right thing to do.

The PSI file which caused this is a special case because it attaches
something to its kernfs file which outlives the severing operation bypassing
kernfs infra. A more complete way to fix this would be supporting the
required behavior from kernfs side, so that the PSI file operates on kernfs
interface which knows the severing event and detaches properly. That said,
currently, this is very much an one-off.

Suren, if you're interested, it might make sense to pipe poll through kernfs
properly so that it has its kernfs operation and kernfs can sever it. That
said, as this is a fix for something which is currently causing crashes,
it'd be better to merge this simpler fix first no matter what.

Thanks.

-- 
tejun

  parent reply	other threads:[~2023-06-27 18:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26 20:17 [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file Suren Baghdasaryan
2023-06-26 20:17 ` [PATCH 2/2] sched/psi: tie psi trigger destruction with file's lifecycle Suren Baghdasaryan
2023-06-26 20:21 ` [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file Suren Baghdasaryan
2023-06-26 20:31 ` Tejun Heo
2023-06-26 20:39   ` Suren Baghdasaryan
2023-06-27  8:24   ` Christian Brauner
2023-06-27 17:09     ` Suren Baghdasaryan
2023-06-27 17:30       ` Christian Brauner
2023-06-27 17:36         ` Suren Baghdasaryan
2023-06-27 18:42         ` Tejun Heo [this message]
2023-06-27 20:09           ` Suren Baghdasaryan
2023-06-27 21:43             ` Suren Baghdasaryan
2023-06-27 21:58               ` Suren Baghdasaryan
2023-06-28  1:54                 ` Tejun Heo
2023-06-28  3:09                   ` Suren Baghdasaryan
2023-06-28  7:26                     ` Christian Brauner
2023-06-28  7:46                       ` Suren Baghdasaryan
2023-06-28  8:41                         ` Christian Brauner
2023-06-28 16:28                           ` Suren Baghdasaryan
2023-06-28 17:35                             ` Christian Brauner
2023-06-28 18:02                               ` Tejun Heo
2023-06-28 18:18                                 ` Suren Baghdasaryan
2023-06-28 18:42                                   ` Greg KH
2023-06-28 20:12                                     ` Suren Baghdasaryan
2023-06-28 20:34                                       ` Tejun Heo
2023-06-28 21:50                                         ` Suren Baghdasaryan
2023-06-30  0:59                                           ` Suren Baghdasaryan
2023-06-30  8:21                                             ` Christian Brauner
2023-07-10 20:38                                               ` Tejun Heo
2023-06-28 17:58                       ` Tejun Heo
2023-06-27  6:25 ` Greg KH
2023-06-27 17:03   ` Suren Baghdasaryan
2023-06-27 17:23     ` Christian Brauner
2023-06-27 17:36     ` Matthew Wilcox

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=ZJstlHU4Y3ZtiWJe@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=ebiggers@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=lujialin4@huawei.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=surenb@google.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vschneid@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).