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: Wed, 28 Jun 2023 08:02:06 -1000 [thread overview]
Message-ID: <ZJx1nkqbQRVCaKgF@slm.duckdns.org> (raw)
In-Reply-To: <20230628-spotten-anzweifeln-e494d16de48a@brauner>
On Wed, Jun 28, 2023 at 07:35:20PM +0200, Christian Brauner wrote:
> > To summarize my understanding of your proposal, you suggest adding new
> > kernfs_ops for the case you marked (1) and change ->release() to do
> > only (2). Please correct me if I misunderstood. Greg, Tejun, WDYT?
>
> Yes. I can't claim to know all the intricate implementation details of
> kernfs ofc but this seems sane to me.
This is going to be massively confusing for vast majority of kernfs users.
The contract kernfs provides is that you can tell kernfs that you want out
and then you can do so synchronously in a finite amount of time (you still
have to wait for in-flight operations to finish but that's under your
control). Adding an operation which outlives that contract as something
usual to use is guaranteed to lead to obscure future crnashes. For a
temporary fix, it's fine as long as it's marked clearly but please don't
make it something seemingly widely useable.
We have a long history of modules causing crashes because of this. The
severing semantics is not there just for fun.
Thanks.
--
tejun
next prev parent reply other threads:[~2023-06-28 18:02 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
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 [this message]
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=ZJx1nkqbQRVCaKgF@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).