All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-nfs@vger.kernel.org, Jeff Layton <jlayton@redhat.com>,
	David Howells <dhowells@redhat.com>, Tejun Heo <tj@kernel.org>,
	Shaohua Li <shli@fb.com>, Oleg Nesterov <oleg@redhat.com>,
	linux-kernel@vger.kernel.org,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: [PATCH 0/4] allow multiple kthreadd's
Date: Fri,  1 May 2020 12:01:48 -0400	[thread overview]
Message-ID: <1588348912-24781-1-git-send-email-bfields@redhat.com> (raw)

From: "J. Bruce Fields" <bfields@redhat.com>

These patches allow a caller to create its own kthreadd.

The motivation is file delegations: currently any write operation from a
client breaks all delegations, even delegations held by the same client.

To fix that, we need to know which client is performing a given
operation.

So, we let nfsd put all the nfsd threads into the same thread group (by
spawning them from its own private kthreadd), then patch the delegation
code to treat delegation breaks from the same thread group as not
conflicting, and then leave it to nfsd to sort out conflicts among its
own clients.  Those patches are in:

	git://linux-nfs.org/~bfields/linux.git deleg-fix-self-conflicts

This was an idea from Trond.  Part of his motivation was that it could
work for userspace servers (like Ganesha and Samba) as well.  (We don't
currently let them request delegations, but probably will some day--it
shouldn't be difficult.)

Previously I considered instead adding a new field somewhere in the
struct task.  That might require a new system call to expose to user
space.  Or we might be able to put this in a keyring, if David Howells
thought that would work.

Before that I tried passing the identity of the breaker explicitly, but
that looks like it would require passing the new argument around to huge
swaths of the VFS.

Anyway, does this multiple kthreadd approach look reasonable?

(If so, who should handle the patches?)

--b.

J. Bruce Fields (4):
  kthreads: minor kthreadd refactoring
  kthreads: Simplify tsk_fork_get_node
  kthreads: allow multiple kthreadd's
  kthreads: allow cloning threads with different flags

 include/linux/kthread.h |  21 +++++-
 init/init_task.c        |   3 +
 init/main.c             |   4 +-
 kernel/fork.c           |   4 ++
 kernel/kthread.c        | 140 +++++++++++++++++++++++++++++-----------
 5 files changed, 132 insertions(+), 40 deletions(-)

-- 
2.26.2


             reply	other threads:[~2020-05-01 16:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 16:01 J. Bruce Fields [this message]
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
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=1588348912-24781-1-git-send-email-bfields@redhat.com \
    --to=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=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.