Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp199688pxb; Mon, 11 Apr 2022 23:02:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFRfRav1F4xL4eXHtADSscBcGzWKiykJCnxsAPQfwAHDzWKG0ZPb0HqGYdvSmyDVuPc7XY X-Received: by 2002:a17:907:1623:b0:6df:c9da:a6a8 with SMTP id hb35-20020a170907162300b006dfc9daa6a8mr32410421ejc.303.1649743348952; Mon, 11 Apr 2022 23:02:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649743348; cv=none; d=google.com; s=arc-20160816; b=xzhFQQfBvRvuTiPpqIbAP5119EetAh2H5HYFR5oTKeRnmkbnj/uDvQFFGLgtI5MOc1 0CnsCG+oyHu9/z3Mp4KS5yLo+KPdkCji8NDo3BeMIg8fWPIG5kz6YU7nQykCDoW5jMqd e2pYzGna+WvG4+7AXA/qfTjR4U0hbVhonkAJPiU4AEcBj2ZHLEFWR3JbXk6wbGvkKcj8 dFJt/3V0E+/4AjjjVNrNSWbQS7KGdBZ7WvlFT0OdGruNwKcF1fZ+LKAARCVFfy0RnOxO 1GY2ho27uPmgsdAhS3dI+um1kEbJOoiVrneD0+s1P9rOusMf9qi/+ZG0bbJkeNVhgxHz 8qJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Q6Qt/7zIphtgdljo33ozWKYZbX8UCtN64PZbxI4ynqw=; b=wkkaaLWm7ivF1+8UbtywXFndqNVuzoJGbIGRN/Wom/0J7DzR888vWEWr1NgGvP7AE1 edzgQAqupoLdocLJKRtjP8l96kKqgZlj3qtmFlSWTIjSlTOcU82p8v/qf2IbzkUcJPF5 /swTV6rHS7jyrGeqMVaL+0ag6+QdedFOeLPxrWkdjZTDoQgLaaGFVJExyCOU6OyASawq gjN4CcW3CE63+yxTNeUZWzh0As8EmDwRmP2UojtqQkzqdXW86OK240fCUwVNe0KBraAc iS1ZmJvXLzwTeKHovcj2Ic2SnIv3SE3IG25Cfen+8UV000sbq96jo6N1AnYfDhkEnQSa 9PmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=vWvVnerv; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hc16-20020a170907169000b006df76385ee2si9043420ejc.898.2022.04.11.23.01.59; Mon, 11 Apr 2022 23:02:28 -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=@suse.com header.s=susede1 header.b=vWvVnerv; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245054AbiDKGvC (ORCPT + 99 others); Mon, 11 Apr 2022 02:51:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231299AbiDKGvA (ORCPT ); Mon, 11 Apr 2022 02:51:00 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 021A118361 for ; Sun, 10 Apr 2022 23:48:47 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id AD80A1F388; Mon, 11 Apr 2022 06:48:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649659726; 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=Q6Qt/7zIphtgdljo33ozWKYZbX8UCtN64PZbxI4ynqw=; b=vWvVnerv/tjfxZAbDG7/Zv0b0LO+/8VrLmtaLRBB8lyuUhhsc2YBPSNDMLSyIg9Kf1P0hn pJv15RXG45PZEKGst8+awsZmMyCxeR4+AxRAIGNzGe1Kaa50KAqNRM/DZfyueIjN8Tmr34 IaCOQBI01Q5L6EZG60GGKCjRarPHU1s= 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 1BDC2A3B83; Mon, 11 Apr 2022 06:48:44 +0000 (UTC) Date: Mon, 11 Apr 2022 08:48:38 +0200 From: Michal Hocko To: Thomas Gleixner 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 Message-ID: References: <20220408032809.3696798-1-npache@redhat.com> <20220408081549.GM2731@worktop.programming.kicks-ass.net> <87k0bzk7e5.ffs@tglx> <87sfqni77s.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sfqni77s.ffs@tglx> 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 On Fri 08-04-22 23:41:11, Thomas Gleixner wrote: [...] > 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? 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. On the other hand I do agree that delayed oom_reaper execution is a reasonable workaround and the most simplistic one. 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. HTH -- Michal Hocko SUSE Labs