linux-kernel - Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list

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: <YlPPRrGrX2ECe8QY@dhcp22.suse.cz>
Date:   Mon, 11 Apr 2022 08:48:38 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Joel Savitz <jsavitz@...hat.com>, Nico Pache <npache@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>, linux-mm@...ck.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Rafael Aquini <aquini@...hat.com>,
        Waiman Long <longman@...hat.com>, Baoquan He <bhe@...hat.com>,
        Christoph von Recklinghausen <crecklin@...hat.com>,
        Don Dutile <ddutile@...hat.com>,
        "Herton R . Krzesinski" <herton@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Ingo Molnar <mingo@...hat.com>,
        Darren Hart <dvhart@...radead.org>, stable@...nel.org
Subject: Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing
 the robust_list_head

On Fri 08-04-22 23:41:11, Thomas Gleixner wrote:
[...]
> Coming back to your original question.
> 
> What's the difference between a process shared and a process private
> futex in the context of a multi threaded process?
> 
>   - The process shared must obviously have a shared mapping
> 
>   - The process private has no need for a shared mapping because
>     all threads share the same address space.
> 
> What do they have in common?
> 
>   - All of them are threads in the kernel POV
> 
>   - All of them care about the unexpected exit/death of some other
>     thread vs. locking
> 
> So why would a process private robust mutex be any different from a
> process shared one?

Purely from the OOM POV they are slightly different because the OOM
killer always kills all threads which share the mm with the selected
victim (with an exception of the global init - see __oom_kill_process).
Note that this is including those threads which are not sharing signals
handling.
So clobbering private locks shouldn't be observable to an alive thread
unless I am missing something.

On the other hand I do agree that delayed oom_reaper execution is a
reasonable workaround and the most simplistic one. If I understand your
example code then we would need to evaluate the whole robust list and
that is simply not feasible because that would require a #PF in general
case.

HTH
-- 
Michal Hocko
SUSE Labs