From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B17BFC433F5 for ; Thu, 21 Apr 2022 14:40:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 169C36B0074; Thu, 21 Apr 2022 10:40:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F1D16B0075; Thu, 21 Apr 2022 10:40:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EACFE6B0078; Thu, 21 Apr 2022 10:40:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id D61546B0074 for ; Thu, 21 Apr 2022 10:40:09 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A60C123427 for ; Thu, 21 Apr 2022 14:40:09 +0000 (UTC) X-FDA: 79381146138.02.5361788 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf10.hostedemail.com (Postfix) with ESMTP id 31CD9C001C for ; Thu, 21 Apr 2022 14:40:06 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1650552007; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oAO55pYABee/TxUYtxpv4J57hWPpV3OsKogaKGHUQvk=; b=Ia7H/FRQaz3jsRLyf7HhoMbf60W57A9vxjB3+R883fiv6ayKf1x8R8IUrvrHshU8+Qc8A+ EBKGLgoxSauIV5rUuEetjS5gozS2++9WzsGMrm7Ztob8OxAtXNL8oD/AeFslT232RIAP/s G0w+IFDnVw0SAJ8JY2LuCh42Nlzf9GznOwU9PeesLIxI/GSKcbO+IIxw9akDppS7xcAe0i EhwIcpoktsOh7aXsxI52sizO14YaAYKUT0yo7i0QfE/RkuVeVB97kpFv0FG/K7Yh1TV7QF Q1nkiR8YOsDJNkDbYnlMCyBP7+8tE6iCyEnHRMZskyczueFc/gOYwJu6GFmNPA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1650552007; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oAO55pYABee/TxUYtxpv4J57hWPpV3OsKogaKGHUQvk=; b=wHfBjKfKS+/a0EV3Q/YQ+0z9Jt/DhcCvjjsJ5ikuLKtHRCZxCYN8NMfsQGEG0zagqkehxD 9haw2grX+YVepbCQ== To: Nico Pache , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Rafael Aquini , Waiman Long , "Herton R . Krzesinski" , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , David Rientjes , Michal Hocko , Andrea Arcangeli , Andrew Morton , Davidlohr Bueso , Peter Zijlstra , Ingo Molnar , Joel Savitz , Darren Hart , stable@kernel.org Subject: Re: [PATCH v9] oom_kill.c: futex: Delay the OOM reaper to allow time for proper futex cleanup In-Reply-To: <20220414144042.677008-1-npache@redhat.com> References: <20220414144042.677008-1-npache@redhat.com> Date: Thu, 21 Apr 2022 16:40:06 +0200 Message-ID: <874k2mts8p.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="Ia7H/FRQ"; dkim=pass header.d=linutronix.de header.s=2020e header.b=wHfBjKfK; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf10.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 31CD9C001C X-Stat-Signature: kak5g15o91e4xxc35d7ckrisodh9m5ki X-HE-Tag: 1650552006-270116 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 14 2022 at 10:40, Nico Pache wrote: > The pthread struct is allocated on PRIVATE|ANONYMOUS memory [1] which can > be targeted by the oom reaper. This mapping is used to store the futex > robust list head; the kernel does not keep a copy of the robust list and > instead references a userspace address to maintain the robustness during > a process death. A race can occur between exit_mm and the oom reaper that > allows the oom reaper to free the memory of the futex robust list before > the exit path has handled the futex death: > > CPU1 CPU2 > ------------------------------------------------------------------------ > page_fault > do_exit "signal" > wake_oom_reaper > oom_reaper > oom_reap_task_mm (invalidates mm) > exit_mm > exit_mm_release > futex_exit_release > futex_cleanup > exit_robust_list > get_user (EFAULT- can't access memory) > > If the get_user EFAULT's, the kernel will be unable to recover the > waiters on the robust_list, leaving userspace mutexes hung indefinitely. > > Delay the OOM reaper, allowing more time for the exit path to perform > the futex cleanup. > > Reproducer: https://gitlab.com/jsavitz/oom_futex_reproducer > > [1] https://elixir.bootlin.com/glibc/latest/source/nptl/allocatestack.c#L370 A link to the original discussion about this would be more useful than a code reference which is stale tomorrow. The above explanation is good enough to describe the problem. > > +/* > + * Give the OOM victim time to exit naturally before invoking the oom_reaping. > + * The timers timeout is arbitrary... the longer it is, the longer the worst > + * case scenario for the OOM can take. If it is too small, the oom_reaper can > + * get in the way and release resources needed by the process exit path. > + * e.g. The futex robust list can sit in Anon|Private memory that gets reaped > + * before the exit path is able to wake the futex waiters. > + */ > +#define OOM_REAPER_DELAY (2*HZ) > +static void queue_oom_reaper(struct task_struct *tsk) Bah. Did you run out of newlines? Glueing that define between the comment and the function is unreadable. Other than that. Acked-by: Thomas Gleixner