Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp307231pxb; Tue, 12 Apr 2022 02:24:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxm2iyHlDKkk1Hx5oE6i9K2+CpS1UF4EFXYQRqIZGCMMa+pQPkew6HzzqwrPXx+GvTrszJi X-Received: by 2002:a63:3441:0:b0:39d:a27b:e594 with SMTP id b62-20020a633441000000b0039da27be594mr447013pga.98.1649755447627; Tue, 12 Apr 2022 02:24:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649755447; cv=none; d=google.com; s=arc-20160816; b=gnJSm/j7YFxPiXg9fq77ff/dubH+h4JfyxJYGJh9+2lJL/YwNKf9vsUmmZNiaMyUtz 8fYhqbpCYfkUdJ0PpCZojqxYkah2Y8SNgrkzWB6c6n+8bvn8fOB7N72jBwFOhZ2zQScs sqT3pfxDVDWk18cFkYMEyONYrJiwk58J/R7YsQcIWRa0/g0dDe5g0VRzzY0u5iOkI8ud y6V4lzh1d9jX0aDMeamcM+pA+pRZlV7JpS6JpLeyD1SW/4lPdDUmcQIGAauNcKgXYaCS Q1UZD0vRogF4X+UlWPy4xyz//WYYtSCVbaoNu5ACeTCH7FGqFeTxeFbhnyBL2+orVbwr JoEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=uK7/dZRTApAGFgqX1YHKs8HnTEUKBlTqZabjdZ+TFs0=; b=nUK1Z3ZWoUTinvml4UJPSMZSkapJngB7KAbQgMMfzpQ/GayQXLz1EhEFB6P0n3evay QoTklx/NVCdbqVMAFyJKngHFOk+JB+e7E5vjI0p0esBDiMKr/17+D5rY1rvmESGDWv8t 5qPhWrlhK2Nhm9hES87K8FKECjbh8WtOmQcCgIGE8M62rj94MD7meDLub8bmBrqhKQdq vRPOFhanlgJr5asW6d28iya+E4c9rhXXwP5lMrzcRgIMfhCT0J95IJ7+fu00MVslyZgO VaTZ8wD8G9nX/k7jqsy6qSfLmY9nTE4Ab+aY9eoeIVxYfOFeEte3Y79LhRQ7pLx0KXcD VYsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=fK89maEf; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u63-20020a638542000000b0039d1adfb84dsi2132073pgd.37.2022.04.12.02.23.52; Tue, 12 Apr 2022 02:24:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=fK89maEf; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245640AbiDKHte (ORCPT + 99 others); Mon, 11 Apr 2022 03:49:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243358AbiDKHta (ORCPT ); Mon, 11 Apr 2022 03:49:30 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CC8023140 for ; Mon, 11 Apr 2022 00:47:16 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649663234; 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=uK7/dZRTApAGFgqX1YHKs8HnTEUKBlTqZabjdZ+TFs0=; b=fK89maEfT47Wb8IySkCCcsB6rrxNE16tLQzgsQ2NcFmFPRYFnSr1dOuLlj7rAaT2RNPG89 oeVvB+xJV+1sTJwQOFxrxjNzPrC5p7Of6tG+GBvxRI3fYa1jjk9xy011SFu1YTdroaq47O T+znjnzrgUwv0AGgf8DleNwTLatO8qCKOgxJgj5w5TTPB3k5jD/8E2b/GbJt5nF6HH3U16 KNkTy14c6BhRtQRDIVqSqQ4tx2W1n80JxKcr5t5BtODrZXwati/IUuUF4Ujt6eZLVS+mrY 64yHeoTK80OFOr6GQA+i0KirTPMu0TjeN5UHSccb0LdvSPZQ68GFFxQXgE4YkA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649663234; 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=uK7/dZRTApAGFgqX1YHKs8HnTEUKBlTqZabjdZ+TFs0=; b=uPGtRp03EBVhBkL8NVE8CyJo28YTIY4xyDxaE7uo8X7Agw/iQhxLwpKfN98iGWyBf60EGh +ymdKccM+W1h8cDA== To: Michal Hocko Cc: Joel Savitz , Nico Pache , Peter Zijlstra , linux-mm@kvack.org, linux-kernel , Rafael Aquini , Waiman Long , Baoquan He , Christoph von Recklinghausen , Don Dutile , "Herton R . Krzesinski" , David Rientjes , Andrea Arcangeli , Andrew Morton , Davidlohr Bueso , Ingo Molnar , 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: References: <20220408032809.3696798-1-npache@redhat.com> <20220408081549.GM2731@worktop.programming.kicks-ass.net> <87k0bzk7e5.ffs@tglx> <87sfqni77s.ffs@tglx> Date: Mon, 11 Apr 2022 09:47:14 +0200 Message-ID: <87wnfwf4e5.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal, On Mon, Apr 11 2022 at 08:48, Michal Hocko wrote: > On Fri 08-04-22 23:41:11, Thomas Gleixner wrote: >> 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. Yes, it kills everything, but the reaper also reaps non-shared VMAs. So if the process private futex sits in a reaped VMA the shared one becomes unreachable. > On the other hand I do agree that delayed oom_reaper execution is a > reasonable workaround and the most simplistic one. I think it's more than a workaround. It's a reasonable expectation that the kernel side of the user space threads can mop up the mess the user space part created. So even if one of of N threads is stuck in a place where it can't, then N-1 can still reach do_exit() and mop their mess up. The oom reaper is the last resort to resolve the situation in case of a stuck task. No? > 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. Right. The robust list exit code does the user access with pagefaults disabled and if it fails, it terminates the list walk. Bad luck :) Thanks, tglx