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 849A0C433F5 for ; Tue, 12 Apr 2022 00:02:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DFCB56B0071; Mon, 11 Apr 2022 20:02:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAD9D6B0073; Mon, 11 Apr 2022 20:02:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C26F16B0074; Mon, 11 Apr 2022 20:02:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id AE5726B0071 for ; Mon, 11 Apr 2022 20:02:06 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5C1C0A5D4C for ; Tue, 12 Apr 2022 00:02:06 +0000 (UTC) X-FDA: 79346274252.23.74D18A6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf17.hostedemail.com (Postfix) with ESMTP id CECF440004 for ; Tue, 12 Apr 2022 00:02:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649721725; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8c5EjZJFWQjGO0KtsK/b2yAf9oKCDamxmuxgZSqrg+g=; b=I0b79ZgvMO/f0ryG08CpWrW8AGXtFSuRzQFEXKtxEUKmIkZaGrLMyX6FVn5RYUaeMRHz3O 9YznV8VA0xiT61ObqUASqVN+wxZUJyyTfUOIWt+RxJQjJr27VQEwTv+c4q+KnJMRkPEIIk wPm3G5vFnCKerAd/MNVliWnwHOEaur4= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-358-asMYrabVMta5FcjUKwTp6A-1; Mon, 11 Apr 2022 20:02:03 -0400 X-MC-Unique: asMYrabVMta5FcjUKwTp6A-1 Received: by mail-qt1-f199.google.com with SMTP id k1-20020ac85fc1000000b002e1c5930386so13780134qta.3 for ; Mon, 11 Apr 2022 17:02:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=8c5EjZJFWQjGO0KtsK/b2yAf9oKCDamxmuxgZSqrg+g=; b=hZvJ0SxB5eJRVDhRkKjPLeMwt9MWBloa3AroRNRcnw3p3bQSp4n4iJDVk+UGaRXAQc xmBPpc3bJVMXXP2oN4cPlsfxEKGxLuS3A+Foh0ALq/O3JlCL4zF+PIeNXC5H3RZm+eb5 oSHdaSvSKtqq/ZkiHJW/YdGVdevxgYKgo/5+MOblFXEpaOLRpNLUtUxACWgOVAnCMWyJ 4OuVTwvYXqY97BigdyEy/qzw3zJUQ6qCSJFtl8UpRwA4veZovuuLnm6XL4JHOhsHQEdk CsFPNCXZv30I5kUCpkqGU0KN5eDB79ifGP4hg5PSmlZzYTD2In39KSE58MJKsJ1gVJhG 1URQ== X-Gm-Message-State: AOAM531APQhEHjmSnaUDpUQOiED0a80I89fz55MfeyggLUrbFeNpH06G bO6GiIZhTu0OqFQ8GneWP1uxIsNNhpcEe/PPAGSv1C6Xc+ErdrgS/Z5wjSnkMDr7Of1DVJ1O6S3 ZW5hS9v3gitg= X-Received: by 2002:ac8:58c5:0:b0:2e1:cca9:b3f3 with SMTP id u5-20020ac858c5000000b002e1cca9b3f3mr1521221qta.100.1649721723338; Mon, 11 Apr 2022 17:02:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRyGmd8uhOz3BleD/jMRXTkNltGHNdY2kfh6XYh8L18wcb9jFXAm4k21+nuZ3n/yFAlENfPA== X-Received: by 2002:ac8:58c5:0:b0:2e1:cca9:b3f3 with SMTP id u5-20020ac858c5000000b002e1cca9b3f3mr1521196qta.100.1649721723101; Mon, 11 Apr 2022 17:02:03 -0700 (PDT) Received: from [192.168.0.188] ([24.48.139.231]) by smtp.gmail.com with ESMTPSA id i62-20020a37b841000000b0069c10d27571sm3770984qkf.70.2022.04.11.17.02.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Apr 2022 17:02:02 -0700 (PDT) Message-ID: Date: Mon, 11 Apr 2022 20:02:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list_head To: Michal Hocko , Thomas Gleixner Cc: Joel Savitz , 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 References: <20220408032809.3696798-1-npache@redhat.com> <20220408081549.GM2731@worktop.programming.kicks-ass.net> <87k0bzk7e5.ffs@tglx> <87sfqni77s.ffs@tglx> <87wnfwf4e5.ffs@tglx> From: Nico Pache In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: mpg1uagxue8tpezhhotbrydxrcsfwg81 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I0b79Zgv; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf17.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=npache@redhat.com X-Rspamd-Queue-Id: CECF440004 X-HE-Tag: 1649721725-158743 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4/11/22 05:08, Michal Hocko wrote: > On Mon 11-04-22 09:47:14, Thomas Gleixner wrote: >> 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? > > Yes, I keep saying workaround because it really doesn't address the > underlying issue which is that the oom_reaper clobbers something it > shouldn't be. A full fix from my POV would be making oom_reaper code > more aware of the futex usage. But this is something nore really viable. This is *kinda* what this approach is doing, but as Thomas has pointed out, it has its shortcoming. Additionally, it has just come to my attention, that this solution does not cover the compat robust list... So there is yet another shortcoming. > > Btw. this is what I've in my local tree. It hasn't seen any testing but > it might be a good start to make it a full patch. I have decided to use > a timer rather than juggling tasks on the oom_reaper list because > initial implementation looked uglier. I will try to find some time to > finish that but if Nico or others beat me to it I won't complain. > Also I absolutely do not insist on the timer approach. > [...] I will spend tomorrow working the delay solution and testing it. Thanks for starting it :) I appreciate the comments and help from everyone that has participated! I'm sorry if any misunderstanding were had, its not our intention to upset anyone, but rather to learn and work a solution for the problem we are facing. Best, -- Nico