All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hillf Danton <hdanton@sina.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: David Howells <dhowells@redhat.com>,
	Eric Biggers <ebiggers@kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH v5] KEYS: key_garbage_collector(): process in chunks
Date: Fri, 30 Oct 2026 14:10:06 +0800	[thread overview]
Message-ID: <20261030061030.233-1-hdanton@sina.com> (raw)
In-Reply-To: <auPjLi6xocFw7r-k@kernel.org>

On Fri, 30 Oct 2026 02:22:06 +0200 Jarkko Sakkinen wrote:
> On Fri, Oct 30, 2026 at 02:17:31AM +0200, Jarkko Sakkinen wrote:
> > On Fri, Oct 30, 2026 at 07:41:48AM +0800, Hillf Danton wrote:
> > > On Thu, 29 Oct 2026 19:29:17 +0200 Jarkko Sakkinen wrote:
> > > > key_garbage_collector() has a design that is not resistant enough for
> > > > workqueue lockups. The duration scales up relative to the number of items
> > > > in the serial tree, which causes a reoccuring theme of being guilty of
> > > > causing workqueue lockups.
> > > >
> > > Given cond_resched() the gc work is not a cpu hog, and given concurrency
> > > workqueue can get individual cpu highly overloaded in short time, so what
> > > you delivered is a half backed croissant, HBC, as you failed to make it
> > > clear why lockup occurs when the number of gc items rockets up.
> > 
> > Please, read:
> > 
> > 1. Documentation/process/code-of-conduct-interpretation.rst
> > 2. Documentation/process/code-of-conduct.rst
> 
> And: I'd suggest to do some self-reflection and not use LKML for
> trolling. There's 4chan, Reddit and other more appriate forums for
> doing that.
> 
Can you answer the simple question, why is your patch correct for curing
the root cause of the workqueue lockup? Because it has nothing to do with
trolling.

  reply	other threads:[~2026-10-30  6:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 17:29 [PATCH v5] KEYS: key_garbage_collector(): process in chunks Jarkko Sakkinen
2026-10-29 17:40 ` Jarkko Sakkinen
2026-10-29 17:41 ` sashiko-bot
2026-10-29 23:41 ` Hillf Danton
2026-10-30  0:17   ` Jarkko Sakkinen
2026-10-30  0:22     ` Jarkko Sakkinen
2026-10-30  6:10       ` Hillf Danton [this message]
2026-10-30 15:17         ` Jarkko Sakkinen
2026-10-30 15:21           ` Jarkko Sakkinen
2026-10-30 15:26             ` Jarkko Sakkinen

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=20261030061030.233-1-hdanton@sina.com \
    --to=hdanton@sina.com \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.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.