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 41957C433EF for ; Thu, 6 Jan 2022 10:22:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9D686B0073; Thu, 6 Jan 2022 05:22:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B4CE16B0074; Thu, 6 Jan 2022 05:22:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A16026B0075; Thu, 6 Jan 2022 05:22:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 93EE96B0073 for ; Thu, 6 Jan 2022 05:22:47 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4C509181D4711 for ; Thu, 6 Jan 2022 10:22:47 +0000 (UTC) X-FDA: 78999473574.12.3E2FF7B Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf09.hostedemail.com (Postfix) with ESMTP id C020C140003 for ; Thu, 6 Jan 2022 10:22:37 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id i31so3937727lfv.10 for ; Thu, 06 Jan 2022 02:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0WWAn60jvAU8+fUt4TyQU6LDH6mvfpEhABYSISoIc7A=; b=sn0lzS/nPUwXYJjTjI1l52geusnkl37PbLCwP5F6+7Za6hf7UFkD4pkOArLMtmQr3S WAtJqImb8gExFCIRnVJ+pyiJS2hb7eaKgnLfzdk5Yxw/BDOUtKF7QRkivDZgZbvgHqLM o2g7+aa+bpIu8NHTIkk3zCaOUbpIJbAY1jZNHWUWX6NQAUXRXlIiGpjto9TRzCRnX8q/ 8ajiR1eH2UvUQNrhMGj69jAYtyxRADV+s1Lw/zGrxqQCwNTz4/oWguVwfDk5cZDdaQnx RnVxMaZWaw97RkH/QZu5hmbwvmzn8DbjLkCKuAoEYR98JPGIzz70LZOfWiErDYyvi8Sg 8/Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0WWAn60jvAU8+fUt4TyQU6LDH6mvfpEhABYSISoIc7A=; b=nJax7R4+JXowiD9t9s0X8OaKxHwJ8whu8ffodwTr4UDdunsOEY5K6MORknkTj+MK7M b5UhZ70wPxOpz8iDfyJgMtCDwbH1PKHqdlDyKD2hKI8Du0FIXPxhdB2t8jvG4BylHy5Q Bd37Bpk328qj7XMTwFU+Goks4VL4+Y1PLedkW+vVL9L1uPKsag/4bxQvkhNTZCMRsGfh JXiOCKTMRa7kaS+HR+FRNhL/DgaWkVBNb8YXHLiTs7LmJV6kfwTiST3dRPRdlL5fsj7j lVwFpHIn3+rCw+gd29gk3gie7XbQIvr1U7CwoYsrJmGGDmL1nGVyXo4TQ2qqyHy1nnSS dudw== X-Gm-Message-State: AOAM531mBnLOWAZEsjvr4VGOlX9ANKV+/qqbfCBiYE4GoB+UDt8lW3kZ U9MTX/SyvkfPW88dUzMn7euf/01On8A5zCcuI++Vgg== X-Google-Smtp-Source: ABdhPJw0H2SPqPQR90p6wbxU0Urt+DcUneiWX2ZhgHg2shVfWu1qf9Uhqz317dkZhPYSxWamCB2KwNa6AZ6UQEFY4Ts= X-Received: by 2002:a05:6512:22c7:: with SMTP id g7mr50847168lfu.315.1641464564846; Thu, 06 Jan 2022 02:22:44 -0800 (PST) MIME-Version: 1.0 References: <20220106102027.634842-1-jannh@google.com> In-Reply-To: <20220106102027.634842-1-jannh@google.com> From: Jann Horn Date: Thu, 6 Jan 2022 11:22:18 +0100 Message-ID: Subject: Re: [PATCH v2] mm, oom: OOM sysrq should always kill a process To: Andrew Morton , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Michal Hocko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C020C140003 X-Stat-Signature: 6ao5qs7zosf58ni673s7k86yocymoapq Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="sn0lzS/n"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=jannh@google.com X-HE-Tag: 1641464557-224429 X-Bogosity: Ham, tests=bogofilter, spamicity=0.032292, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jan 6, 2022 at 11:21 AM Jann Horn wrote: > The OOM kill sysrq (alt+sysrq+F) should allow the user to kill the > process with the highest OOM badness with a single execution. > > However, at the moment, the OOM kill can bail out if an OOM notifier > (e.g. the i915 one) says that it reclaimed a tiny amount of memory > from somewhere. That's probably not what the user wants. > > As documented in struct oom_control, order == -1 means the oom kill is > required by sysrq. So check for that, and if it's true, don't bail out > no matter what the OOM notifiers say. Er, sorry, I just noticed after sending this that the commit message doesn't make sense anymore... I'll send a new version in a sec.