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 C6900C433EF for ; Wed, 8 Dec 2021 06:13:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55E046B0071; Wed, 8 Dec 2021 01:13:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 50D986B0073; Wed, 8 Dec 2021 01:13:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FBF86B0074; Wed, 8 Dec 2021 01:13:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay032.a.hostedemail.com [64.99.140.32]) by kanga.kvack.org (Postfix) with ESMTP id 301736B0071 for ; Wed, 8 Dec 2021 01:13:35 -0500 (EST) Received: by unirelay08.hostedemail.com (Postfix, from userid 108) id 4E2642053B; Wed, 8 Dec 2021 05:33:37 +0000 (UTC) Received: by unirelay08.hostedemail.com (Postfix, from userid 108) id 69BB120927; Wed, 8 Dec 2021 02:24:39 +0000 (UTC) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A84A72090A for ; Wed, 8 Dec 2021 01:58:23 +0000 (UTC) X-FDA: 78892967244.04.1267298 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf28.hostedemail.com (Postfix) with ESMTP id 360B9900009A for ; Wed, 8 Dec 2021 01:58:23 +0000 (UTC) Received: from mail.kernel.org (unknown [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4738AB81E56; Wed, 8 Dec 2021 01:58:21 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 9386C60E98; Wed, 8 Dec 2021 01:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1638928699; bh=UHBVM39wbjqenKtvco+63lP4qWtUsYPVUFf21pmCGkU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NOXMljeOqG0L1T/Hm4N9sMFXEMlV3KiuhihWAed98uC3qDQFF0dAmdSuUmpsT5OUx QNJn2Z4XDJrsr3nd90fLur2Yi+iUKnKXOOIeWCNXRTrxv6JF2NaGsngYV8pZ0LvSf9 4GWqffd7Ge5/lwjfHi0yZyKYKf0HHMtODwdDruEE= Date: Tue, 7 Dec 2021 17:58:16 -0800 From: Andrew Morton To: Nico Pache Cc: Joel Savitz , linux-kernel@vger.kernel.org, Waiman Long , linux-mm@kvack.org, Peter Zijlstra , Michal Hocko Subject: Re: [PATCH] mm/oom_kill: wake futex waiters before annihilating victim shared mutex Message-Id: <20211207175816.8c45ff5b82cb964ade82d6f1@linux-foundation.org> In-Reply-To: References: <20211207214902.772614-1-jsavitz@redhat.com> <20211207154759.3f3fe272349c77e0c4aca36f@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 360B9900009A X-Stat-Signature: hs7f7j4a7cx8fapjyne85dxib895n4qj Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=NOXMljeO; spf=pass (imf28.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1638928703-355148 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 Tue, 7 Dec 2021 19:46:57 -0500 Nico Pache wrote: > > > On 12/7/21 18:47, Andrew Morton wrote: > > (cc's added) > > > > On Tue, 7 Dec 2021 16:49:02 -0500 Joel Savitz wrote: > > > >> In the case that two or more processes share a futex located within > >> a shared mmaped region, such as a process that shares a lock between > >> itself and a number of child processes, we have observed that when > >> a process holding the lock is oom killed, at least one waiter is never > >> alerted to this new development and simply continues to wait. > > > > Well dang. Is there any way of killing off that waiting process, or do > > we have a resource leak here? > > If I understood your question correctly, there is a way to recover the system by > killing the process that is utilizing the futex; however, the purpose of robust > futexes is to avoid having to do this. OK. My concern was whether we have a way in which userspace can permanently leak memory, which opens a (lame) form of denial-of-service attack. > >From my work with Joel on this it seems like a race is occurring between the > oom_reaper and the exit signal sent to the OMM'd process. By setting the > futex_exit_release before these signals are sent we avoid this. OK. It would be nice if the patch had some comments explaining *why* we're doing this strange futex thing here. Although that wouldn't be necessary if futex_exit_release() was documented...