lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YDYdoRwezfVsWS4W@alley>
Date:   Wed, 24 Feb 2021 10:34:25 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Yiwei Zhang <zzyiwei@...roid.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Felix Kuehling <Felix.Kuehling@....com>,
        Jens Axboe <axboe@...nel.dk>,
        "J. Bruce Fields" <bfields@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Ilias Stamatis <stamatis.iliass@...il.com>,
        Rob Clark <robdclark@...omium.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Liang Chen <cl@...k-chips.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel-team <kernel-team@...roid.com>
Subject: Re: [PATCH] kthread: add kthread_mod_pending_delayed_work api

On Tue 2021-02-23 14:29:37, Yiwei Zhang wrote:
> > > which is not cool because it will make the
> > > asynchronous effort a no-op. Is there a way we can include caller
> > > thread metadata(task_struct pointer?) when it enqueues the work so
> > > that the RT worker thread won't preempt the caller thread when that
> > > queued work gets scheduled? Probably require the CPU scheduler to poke
> > > at the next work...or any other ideas will be very appreciated,
> > > thanks!
> >
> > This sounds like a very strange use case.
> > Why is the worker kthread RT when the work can be delayed?
> >
> > If the kthread has to be RT because of another work then
> > your proposal will not work. The delayed processing of
> > low priority work might block and delay any pending
> > high priority work.
> >
> > You should consider handling the less important work in a separate
> > kthread worker with a lower priority or by the system workqueue.
> 
> Just want to clarify that it's not about delayed_work any more. In my
> latest question, it's a RT thread with normal work queued and
> scheduled to be run immediately. However, I simply don't want the
> worker to preempt the thread that queues the work.
> 
> It's a high prio work that we don't want other random tasks to preempt
> it. Meanwhile, we don't want it to preempt the called thread. In
> addition, assume we can't raise the priority of those caller
> threads(otherwise I'd be fine with using a workqueue).

Honestly, it sounds weird to me. Either the caller or the
worker has higher priority.

Well, I think that behavior could be achieved by
CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY.

Anyway, this is rather a question for scheduler experts.
It is possible that it has some solution. But it is also
possible that it is so specific behavior and it would
complicate the scheduler too much.

Best Regards,
Petr

Powered by blists - more mailing lists