linux-kernel - Re: [patch V2 9/9] tasklets: Prevent kill/unlock

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: <87v9dd4ic9.fsf@nanos.tec.linutronix.de>
Date:   Mon, 07 Dec 2020 18:49:26 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Paul McKenney <paulmck@...nel.org>
Subject: Re: [patch V2 9/9] tasklets: Prevent kill/unlock_wait deadlock on RT

On Mon, Dec 07 2020 at 16:39, Sebastian Andrzej Siewior wrote:
> On 2020-12-07 16:22:07 [+0100], Thomas Gleixner wrote:
>> On Mon, Dec 07 2020 at 15:00, Sebastian Andrzej Siewior wrote:
>> > So we keep the RT part as-is and replace the non-RT bits with this?
>> 
>> No. It would work for both.
>
> So instead of boosting our way through we simply wait until the tasklet
> completes. Given that canceling is usually done on start/stop events, it
> shouldn't matter if the RT priority is lost.

That was my reasoning. The only thing we need to figure out whether
there are callers on !RT which invoke that muck from non-sleepable
context.

Thanks,

        tglx