Received: by 2002:a05:6a10:87d6:0:0:0:0 with SMTP id g22csp917955pxr; Mon, 11 Apr 2022 10:16:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/e05ps901q2OObDARkDLkhT3l2Zjly2V7I04jwAKHr1AlVmNau34bQDvsvfobR7NkiJqp X-Received: by 2002:a05:6402:358c:b0:41d:18ff:be23 with SMTP id y12-20020a056402358c00b0041d18ffbe23mr19205386edc.39.1649697392965; Mon, 11 Apr 2022 10:16:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649697392; cv=none; d=google.com; s=arc-20160816; b=uZImwynXa0wshzltsdphCBsuuO4YaPD7Tws3NCkYwOBXdzC9Pz7qdR/69tpu+Mfexr VBpGLB6VaGCIkjS7eITMFXjr7V2CC0pSQCqm7K04tfHQ8CBRJDGLWuBFYyQkB1HH+wLb TVguGg9Wo1SZYKsMk6m+g42YW25+wmPoss0HG633Eop6VCPtuz53cA35LGdrCGCigSQE 5cg9FnPHt8KVRKabHp06JqRTNWA7Vk5wqR9knOPxG3q4W1vfWyI/e6cwUiLrq5NXG/42 si4oohCEmMAKxiXpnNkGBW595PDzyWHP0gMsVn/6n6hohFAXqigaSLP2FYmZnkNkpoYF ElhQ== 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=8G2U5MD5zaVGJHAphYPYznWmTkNAetSatOvZPIWwsmk=; b=ib71GpaNQ3pQuOn+XBhabuReUcHlYcMJyo50SA+uafl7IwN3oCZAUOSxr1gaD5n3jc kAl7mtj+sMiwTcUwthEdkAlR7vF1X6uG6fHDmp3WogsEuIHsCKm24UxRw+8Ut7C5ww8u I82wqHF1p3LiuFcfycjYdrGBqNKShteAWw27WzUPJd83lkr11biMJOjvJtcn0cU44DNS UUkPbjL+PpOVInt0ZuY+QEJHgxTdhzyC/YeYKOMyAx5pNEPSAPBpKDn17BySSrfu9Agh 9V5LLLkFOWkrPs7IBhhIpmyEparXiB5nXjIdCBlyp8S0G3mDyTaVQ7xDuPIiaBpGNlI2 1Z8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=qqFtrIdt; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; 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 x8-20020aa7d6c8000000b0041cc2ef4536si4825697edr.554.2022.04.11.10.16.07; Mon, 11 Apr 2022 10:16:32 -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=qqFtrIdt; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; 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 S235681AbiDHVnU (ORCPT + 99 others); Fri, 8 Apr 2022 17:43:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232842AbiDHVnT (ORCPT ); Fri, 8 Apr 2022 17:43:19 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 614DC1C6 for ; Fri, 8 Apr 2022 14:41:14 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649454072; 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=8G2U5MD5zaVGJHAphYPYznWmTkNAetSatOvZPIWwsmk=; b=qqFtrIdtLcCCKJtlfzudtgKgR+pfzVMpkpTurjlEyc1YQCNCfVNHVVAzC7kTpQPZGwQabD Ep4X5jxbAE9qJpHGEdqEVPu5Duu2aCwEudL9asmKAwAkE/olNZCAnpHBf2kCQxY8pf6jfc K8rbibNG7d9jRH47J3OU7E8qylNaXvMjjZ9HPyJAxBeIf2c2m3BShg4a8xVFgNN9gAYMhv 55ZvOFwL1YnOd0KQw/rBb1wpMHdxc/BUANQR7R9tv1aE1v5f8Jw9Dc0FdDTh4h/6dHarVK JgAZaLctapB0bDfHCfgmyKj3Ty4xbO0ihwE6g2prEwJmMo2ZPNBwL/9TTjxJXQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649454072; 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=8G2U5MD5zaVGJHAphYPYznWmTkNAetSatOvZPIWwsmk=; b=fhrwe8lvhSItZ56SlDvIBRQRSSQ5R+c6bw3pCFjDvoEeWBxWpSfQK0x3Hox7Ay8N7SP6kZ EFfkRiAlRBIDQjAg== To: Joel Savitz Cc: 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 , Michal Hocko , 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> Date: Fri, 08 Apr 2022 23:41:11 +0200 Message-ID: <87sfqni77s.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,URIBL_BLOCKED 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 On Fri, Apr 08 2022 at 12:13, Joel Savitz wrote: >> if (!fork()) { >> pri = mmap(NULL, 1<<20, PROT_READ | PROT_WRITE, >> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); >> pthread_mutexattr_init(&mat_p); >> pthread_mutexattr_setpshared(&mat_p, PTHREAD_PROCESS_PRIVATE); >> pthread_mutexattr_setrobust(&mat_p, PTHREAD_MUTEX_ROBUST); > One thing I don't understand is what kind of sane use case relies on > robust futex for a process-private lock? > Is there a purpose to a lock being on the robust list if there are no > other processes that must be woken in case the holder process is > killed? Ever heard about the concept of multi threading? > If this usage serves no purpose besides causing races during oom, we > should discourage this use, perhaps by adding a note on the manpage. This usage does not cause races during oom. It does not even cause races if it would be silly, which it is not except for the demonstrator above. The keyword here is *demonstrator*. The oom killer itself causes the race because it starts reaping the VMAs without granting the target time to terminate. This needs to be fixed in the first place, period. If the target can't terminate because it is stuck then yes, there will be fallout where a robust futex cannot be released, but that's something which cannot be solved at all. I'm really tired of this by now. Several people explained in great length the shortcomings of your 'cure the symptom' approach, showed you that the "impossible to reproduce" problem is real and told you very explicitely what the proper solution is. So instead of sitting down and really tackling the root cause, all you can come up with is to post the same 'cure the symptom' muck over and over and then if debunked grasp for straws. Coming back to your original question. What's the difference between a process shared and a process private futex in the context of a multi threaded process? - The process shared must obviously have a shared mapping - The process private has no need for a shared mapping because all threads share the same address space. What do they have in common? - All of them are threads in the kernel POV - All of them care about the unexpected exit/death of some other thread vs. locking So why would a process private robust mutex be any different from a process shared one? I'm sure you can answer that question yourself by now. Thanks, tglx