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 1B1E4C433F5 for ; Fri, 8 Apr 2022 08:37:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 526F96B0071; Fri, 8 Apr 2022 04:37:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B0036B0072; Fri, 8 Apr 2022 04:37:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3507C6B0074; Fri, 8 Apr 2022 04:37:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 2243A6B0071 for ; Fri, 8 Apr 2022 04:37:51 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D4F3D25DE9 for ; Fri, 8 Apr 2022 08:37:50 +0000 (UTC) X-FDA: 79333058700.03.74982F6 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf09.hostedemail.com (Postfix) with ESMTP id 53FE814000D for ; Fri, 8 Apr 2022 08:37:50 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649407067; 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=oISKE5LaMehx2C01N20eUScIwjSSk2eBrc+o245KWv4=; b=05bJBQvp24Dg2sKt23/aO72hj8DzDnrYfy3ByG1lOW5b56M8i/ZSL78ZRqE5WgNB7XWe3d qj+YrwxFGlayPpAQ21vh7p9QRVsWlDJkQQ4me8j6lhhGY7czRvwx/Vj12cxaBvQuXx2UqH LR4rmAZX3qtJ1q8lsDm/UXFvYn+5QVLuPGnooP/9/OJiThtX/OUBD9Vn7tHsxj5r9ZMNXg etLXLWeWlseVF/7ZpbzC9zf6fbJEeCcZlnpIbaquYOgq8LWEmuleDV3wHiNn/5vXMul0k+ 79mZpO0q0fj+V38HFOMJtFWWFmbagPUBO5HV0JpRtAc8TizNB/bw9bvH5TkQ6A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649407067; 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=oISKE5LaMehx2C01N20eUScIwjSSk2eBrc+o245KWv4=; b=kyb36WHbPjNrcEjhfChenUP8UmFtGni5hul51e0kQQ+s63IGL2sfZuz59MpTYh36TKnamP OuIo2ZUSB1JAPmCw== To: Peter Zijlstra , Nico Pache Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Rafael Aquini , Waiman Long , Baoquan He , Christoph von Recklinghausen , Don Dutile , "Herton R . Krzesinski" , David Rientjes , Michal Hocko , Andrea Arcangeli , Andrew Morton , Davidlohr Bueso , Ingo Molnar , Joel Savitz , Darren Hart , stable@kernel.org Subject: Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list_head In-Reply-To: <20220408081549.GM2731@worktop.programming.kicks-ass.net> References: <20220408032809.3696798-1-npache@redhat.com> <20220408081549.GM2731@worktop.programming.kicks-ass.net> Date: Fri, 08 Apr 2022 10:37:47 +0200 Message-ID: <87tub4j7hg.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: qzcpfzrzhcmkthi9581to7ffif3uwizk X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 53FE814000D Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=05bJBQvp; dkim=pass header.d=linutronix.de header.s=2020e header.b=kyb36WHb; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf09.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-Rspam-User: X-HE-Tag: 1649407070-296565 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 Fri, Apr 08 2022 at 10:15, Peter Zijlstra wrote: > On Thu, Apr 07, 2022 at 11:28:09PM -0400, Nico Pache wrote: >> Theoretically a failure can still occur if there are locks mapped as >> PRIVATE|ANON; however, the robust futexes are a best-effort approach. >> This patch only strengthens that best-effort. >> >> The following case can still fail: >> robust head (skipped) -> private lock (reaped) -> shared lock >> (skipped) > > This is still all sorts of confused.. it's a list head, the entries can > be in any random other VMA. You must not remove *any* user memory before > doing the robust thing. Not removing the VMA that contains the head is > pointless in the extreme. > > Did you not read the previous discussion? Aside of that we all agreed that giving a oom-killed task time to cleanup itself instead of brute force cleaning it up immediately, which is the real problem here. Can we fix that first before adding broken heuristics? Thanks, tglx