linux-kernel - Re: [PATCH v4] kernel/fork: beware of __put_task

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]

Date:   Tue, 7 Feb 2023 12:26:10 -0300
From:   Wander Lairson Costa <wander@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Andy Lutomirski <luto@...nel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Andrei Vagin <avagin@...il.com>,
        open list <linux-kernel@...r.kernel.org>,
        Hu Chunyu <chuhu@...hat.com>, Oleg Nesterov <oleg@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        Paul McKenney <paulmck@...nel.org>
Subject: Re: [PATCH v4] kernel/fork: beware of __put_task_struct calling context

On Mon, Feb 6, 2023 at 10:09 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Mon,  6 Feb 2023 10:04:47 -0300 Wander Lairson Costa <wander@...hat.com> wrote:
>
> > Under PREEMPT_RT, __put_task_struct() indirectly acquires sleeping
> > locks. Therefore, it can't be cala from a non-preemptible context.
>
> Well that's regrettable. Especially if non-preempt kernels don't do
> this.
>
> Why does PREEMPT_RT do this and can it be fixed?
>

Under PREEMPT_RT, spin_lock becomes a wrapper around rtmutex, which is
a sleeping lock. This is necessary because of the deterministic
scheduling requirements of the RT kernel. Most of the places that run
in atomic context in the stock kernel, become process context in the
RT kernel, so the change spin_lock -> rtmutex is safe. However, there
are always exceptions.

In this particular case, __put_task_struct calls kcache_mem_free,
which refill_obj_stock. refill_obj_stock acquires a local_lock, that
is implemented using a spin_lock.

> If it cannot be fixed then we should have a might_sleep() in
> __put_task_struct() for all kernel configurations, along with an
> apologetic comment explaining why.
>

This patch is supposed to be the fix.