linux-kernel - Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond

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: <0f6a45f80d01e9a5054c7973090a479707bda52f.camel@fb.com>
Date:   Mon, 9 May 2022 14:13:17 +0000
From:   Rik van Riel <riel@...com>
To:     "peterz@...radead.org" <peterz@...radead.org>,
        Song Liu <songliubraving@...com>
CC:     "joe.lawrence@...hat.com" <joe.lawrence@...hat.com>,
        "song@...nel.org" <song@...nel.org>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        Kernel Team <Kernel-team@...com>,
        "live-patching@...r.kernel.org" <live-patching@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched

On Mon, 2022-05-09 at 11:38 +0200, Peter Zijlstra wrote:
> On Mon, May 09, 2022 at 08:06:22AM +0000, Song Liu wrote:
> > 
> > 
> > > On May 9, 2022, at 12:04 AM, Peter Zijlstra
> > > <peterz@...radead.org> wrote:
> > > 
> > > On Sat, May 07, 2022 at 10:46:28AM -0700, Song Liu wrote:
> > > > Busy kernel threads may block the transition of livepatch. Call
> > > > klp_try_switch_task from __cond_resched to make the transition
> > > > easier.
> > > 
> > > What will a PREEMPT=y kernel do? How is it not a problem there,
> > > and if
> > > it is, this will not help that.
> 
> Not really. There is no difference between an explicit preemption
> point
> (cond_resched) or an involuntary preemption point (PREEMPT=y).
> 
> So unless you can *exactly* say why it isn't a problem on PREEMPT=y,
> none of this makes any sense.

I suspect it is a problem on PREEMPT=y too, but is there some sort
of fairly light weight (in terms of stuff we need to add to the kernel)
solution that could solve both?

Do we have some real time per-CPU kernel threads we could just
issue a NOOP call to, which would preempt long-running kernel
threads (like a kworker with oodles of work to do)?

Could the stopper workqueue be a suitable tool for this job?