Re: [PATCH v5] KEYS: key_garbage_collector(): process in chunks

[Jarkko Sakkinen]

On Fri, Oct 30, 2026 at 05:17:34PM +0200, Jarkko Sakkinen wrote:
> On Fri, Oct 30, 2026 at 02:10:06PM +0800, Hillf Danton wrote:
> > 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.
> 
> No.

But I will file the complaint at least if this nonsense won't stop
otherwise. This is now second time where you give nothing except random
snippets, neither explain nor help,  use toxic language, cherry pick
and weaponize words from previous discussions, and generally seem
to try to put other people in a bad position.

I did search over lore and there's a pattern of this behaviour.

Br, Jarkko