From: "tj@kernel.org" <tj@kernel.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "bfields@redhat.com" <bfields@redhat.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"jlayton@redhat.com" <jlayton@redhat.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"shli@fb.com" <shli@fb.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"oleg@redhat.com" <oleg@redhat.com>
Subject: Re: [PATCH 0/4] allow multiple kthreadd's
Date: Fri, 1 May 2020 15:20:57 -0400 [thread overview]
Message-ID: <20200501192057.GH5462@mtj.thefacebook.com> (raw)
In-Reply-To: <d937c9956c0edb0d6fefb9f7dc826367015db4aa.camel@hammerspace.com>
Hello,
On Fri, May 01, 2020 at 07:05:46PM +0000, Trond Myklebust wrote:
> Wen running an instance of knfsd from inside a container, you want to
> be able to have the knfsd kthreads be parented to the container init
> process so that they get killed off when the container is killed.
>
> Right now, we can easily leak those kernel threads simply by killing
> the container.
Hmm... I'm not sure that'd be a lot easier because they're in their own
thread group. It's not like you can queue signal to the group leader cause
the other kthreads to automatically die. Each would have to handle the exit
explicitly. As long as there is a way to iterate the member kthreads (e.g.
list going through kthread_data or sth else hanging off there), just using
existing kthread interface might not be much different, or maybe even easier
given how hairy signal handling in kthreads can get.
Thanks.
--
tejun
next prev parent reply other threads:[~2020-05-01 19:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 16:01 [PATCH 0/4] allow multiple kthreadd's J. Bruce Fields
2020-05-01 16:01 ` [PATCH 1/4] kthreads: minor kthreadd refactoring J. Bruce Fields
2020-05-01 16:01 ` [PATCH 2/4] kthreads: Simplify tsk_fork_get_node J. Bruce Fields
2020-05-01 16:01 ` [PATCH 3/4] kthreads: allow multiple kthreadd's J. Bruce Fields
2020-05-01 16:01 ` [PATCH 4/4] kthreads: allow cloning threads with different flags J. Bruce Fields
2020-05-01 17:59 ` [PATCH 0/4] allow multiple kthreadd's Linus Torvalds
2020-05-01 18:21 ` Tejun Heo
2020-05-01 18:30 ` Linus Torvalds
2020-05-01 19:02 ` J. Bruce Fields
2020-05-01 18:49 ` J. Bruce Fields
2020-05-01 19:05 ` Trond Myklebust
2020-05-01 19:20 ` tj [this message]
2020-05-01 19:22 ` J. Bruce Fields
2020-05-05 2:15 ` J. Bruce Fields
2020-05-05 15:54 ` Tejun Heo
2020-05-05 16:23 ` J. Bruce Fields
2020-05-05 21:01 ` J. Bruce Fields
2020-05-05 21:09 ` Tejun Heo
2020-05-05 21:25 ` J. Bruce Fields
2020-05-06 15:36 ` J. Bruce Fields
2020-05-06 15:39 ` Tejun Heo
2020-05-06 15:54 ` J. Bruce Fields
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=20200501192057.GH5462@mtj.thefacebook.com \
--to=tj@kernel.org \
--cc=bfields@redhat.com \
--cc=dhowells@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=shli@fb.com \
--cc=torvalds@linux-foundation.org \
--cc=trondmy@hammerspace.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).