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 417E2C433EF for ; Wed, 8 Dec 2021 16:06:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A363E6B0073; Wed, 8 Dec 2021 11:05:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C0996B0074; Wed, 8 Dec 2021 11:05:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8866A6B0075; Wed, 8 Dec 2021 11:05:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay036.a.hostedemail.com [64.99.140.36]) by kanga.kvack.org (Postfix) with ESMTP id 7B39C6B0073 for ; Wed, 8 Dec 2021 11:05:58 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 527FF1210E8 for ; Wed, 8 Dec 2021 16:05:48 +0000 (UTC) X-FDA: 78895102776.11.0739D48 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf20.hostedemail.com (Postfix) with ESMTP id 02B74D0000BD for ; Wed, 8 Dec 2021 16:05:45 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C47761FD26; Wed, 8 Dec 2021 16:05:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1638979544; h=from:from:reply-to: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=CvcQBSNTvvCRdBpYrU4PvbzY2eZarvbTKMbxWQBvpFo=; b=MDXnmweZ+FXDg5XpNVKX3/IXscxA1kWIaMVSKlpCsoZx1Ew3hATEkPZe0NRJaYjk2AKg0C Gxe0Tm/HJ6Iont1ZzsZBFU79SoVnUuniIHqlkRgGDMfwkLhjxcr/wvzbSMG38F2lAb/yeL p4mBgkvMSLHHsQCpD1GXv8DRXnQJPoE= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 53F6DA3B93; Wed, 8 Dec 2021 16:05:44 +0000 (UTC) Date: Wed, 8 Dec 2021 17:05:43 +0100 From: Michal Hocko To: Andrew Morton Cc: Joel Savitz , linux-kernel@vger.kernel.org, Waiman Long , linux-mm@kvack.org, Nico Pache , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Darren Hart , Davidlohr Bueso , =?iso-8859-1?Q?Andr=E9?= Almeida Subject: Re: [PATCH] mm/oom_kill: wake futex waiters before annihilating victim shared mutex Message-ID: References: <20211207214902.772614-1-jsavitz@redhat.com> <20211207154759.3f3fe272349c77e0c4aca36f@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 02B74D0000BD Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=MDXnmweZ; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam04 X-Stat-Signature: 6689oq58jekp6joc8bpy74kxf3es65ex X-HE-Tag: 1638979545-671992 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 Wed 08-12-21 10:01:44, Michal Hocko wrote: > On Tue 07-12-21 15:47:59, Andrew Morton wrote: > > (cc's added) > > Extend CC to have all futex maintainers on board. > > > 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? > > > > > This is visible via pthreads by checking the __owner field of the > > > pthread_mutex_t structure within a waiting process, perhaps with gdb. > > > > > > We identify reproduction of this issue by checking a waiting process of > > > a test program and viewing the contents of the pthread_mutex_t, taking note > > > of the value in the owner field, and then checking dmesg to see if the > > > owner has already been killed. > > > > > > This issue can be tricky to reproduce, but with the modifications of > > > this small patch, I have found it to be impossible to reproduce. There > > > may be additional considerations that I have not taken into account in > > > this patch and I welcome any comments and criticism. > > Why does OOM killer need a special handling. All the oom killer does is > to send a fatal signal to the victim. Why is this any different from > sending SIGKILL from the userspace? I have had a closer look and I guess I can see what you are trying to achieve. futex_exit_release is normally called from exit_mm context. You are likely seeing a situation when the oom victim is blocked and cannot exit. That is certainly possible but it shouldn't be a permanent state. So I would be more interested about your particular issue and how long the task has been stuck unable to exit. Whether this is safe to be called from the oom killer context I cannot really judge. That would be a question to Futex folks. -- Michal Hocko SUSE Labs