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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 931C1C433E1 for ; Sat, 15 Aug 2020 22:00:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 73EB62053B for ; Sat, 15 Aug 2020 22:00:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597528839; bh=jARuppsTdoVvePT5G2IluZKuYc/7m/o9A2xwDPs9HYk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=UnY/yt6sArP6TeizfGWtC2f7LHw+8Et/pk417oO0OQRA/3r1Lyma8h0xwgXHjSM9c HCMSZ8z6DECJeOYR0O56Ir9Y8tDNvWQe0kV7KrosmmY3hP8ODej5ducs4YeIJ8Xo6i ouRIMBlq0kQba2VaL2r03fGav6yZ/PvcytNM1xQs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729188AbgHOWA1 (ORCPT ); Sat, 15 Aug 2020 18:00:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728838AbgHOVvf (ORCPT ); Sat, 15 Aug 2020 17:51:35 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D11EFC09B041 for ; Sat, 15 Aug 2020 08:05:17 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id g6so12850029ljn.11 for ; Sat, 15 Aug 2020 08:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3XlBZ6/uS++fkskLWFm8hL4f2NZ/FD4ZhqhfsdhmxAA=; b=RYCK8ewEScLRlrt+evxmgkhxFJOtwVQUtJeT7zY0r8OPXIcAaP0URnYs26SgWiukwg 3xvMTroCRD16NUz4HcgP1nfS2KTxzngiSJc/ZSLB5Hh1+ysGUSSdS/YqxYHpZ8w8iNMZ bJrZwR1AH2gre3kG7OfuOl4xzQcyqsVm19Gr0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3XlBZ6/uS++fkskLWFm8hL4f2NZ/FD4ZhqhfsdhmxAA=; b=qvWnIZopPzI4jJfH0iFpGXMCqAf2nsSlSru7ZiCGf206sr1TEhlJp84kAUwXVszIjq nZ8OEm+6GmNklspGHVERowPhyONplNrARV+R44WdIsWnm9e2LrFgeU3lnKfn8snPpniL RCRfFB8u+QpeBeoARfb+327vdcFUAdPic6C+LTTb8GWJfdzCqUDsqmGgKUCjJ3rl6aL8 VvcNwLDikIlMu+wi7Re/cJN7mbh6V+sx+qoAKiPuQafzPP61O2uQ2VPog2UEzYwR9X95 0UBW2i/5Q/10gwS5PLzfx/KPms+7K9Ij9IOsXNegF2BAHCD+Bhwkxnmiud7n4oxZp0JA RrPg== X-Gm-Message-State: AOAM533fTl8wnbLnSJtN8qX79+JHAk8uqbkK3oC3Ctj/ZbIJxpnNWfei 6Ni3DTM87KI6d/VOpHFPl9xhxNoziPjoEw== X-Google-Smtp-Source: ABdhPJwFufxXA3OedbUBmkZj8qPG4a6qXXmFnc63rSd4T7nSVGhjuQsu9DuoDddqrtMMHjEK284XwQ== X-Received: by 2002:a2e:9a15:: with SMTP id o21mr3602354lji.419.1597503916033; Sat, 15 Aug 2020 08:05:16 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id y16sm2459448ljg.21.2020.08.15.08.05.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Aug 2020 08:05:15 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id c15so6253681lfi.3 for ; Sat, 15 Aug 2020 08:05:15 -0700 (PDT) X-Received: by 2002:a05:6512:241:: with SMTP id b1mr3563049lfo.125.1597503451806; Sat, 15 Aug 2020 07:57:31 -0700 (PDT) MIME-Version: 1.0 References: <20200814172939.55d6d80b6e21e4241f1ee1f3@linux-foundation.org> <20200815003102.dzZiwVm-K%akpm@linux-foundation.org> <20200815045900.GA2936603@google.com> In-Reply-To: <20200815045900.GA2936603@google.com> From: Linus Torvalds Date: Sat, 15 Aug 2020 07:57:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 18/39] mm/madvise: check fatal signal pending of target process To: Minchan Kim Cc: Andrew Morton , Alexander Duyck , Jens Axboe , Brian Geffon , Christian Brauner , Christian Brauner , Daniel Colascione , Johannes Weiner , Jann Horn , John Dias , Joel Fernandes , Kirill Tkhai , linux-man , Linux-MM , Michal Hocko , mm-commits@vger.kernel.org, Oleksandr Natalenko , David Rientjes , Shakeel Butt , sj38.park@gmail.com, sjpark@amazon.de, Sonny Rao , Sandeep Patil , Suren Baghdasaryan , Tim Murray , Vlastimil Babka Content-Type: text/plain; charset="UTF-8" Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On Fri, Aug 14, 2020 at 9:59 PM Minchan Kim wrote: > > Currently, madvise(MADV_COLD|PAGEOUT) already have done it. I just wanted > to sync with it with process_madvise. Ting was process_madvise couldn't > get target task while madvise could get it easily. The thing is, for "current" it makes sense. It makes sense because "current" is also the one doing the action, so when current is dying, stopping the action is sane too. But when you target somebody else, the signal handling simply doesn't make any sense at all. It doesn't make sense because the error code doesn't make sense (EINTR really is about the _actor_ getting interrupted, not the target), but it also doesn't make sense simply because there is no 1:1 relationship between the target mm and the target thread. The pid that was the target may be dying, but that does *not* mean that the mm itself is dying. So stopping the operation arbitrarily somewhere in the middle is a fundamentally insane operation. You've done something partial to a mm that may well still be active. So I think it's simply conceptually wrong to look at some "target thread signal state" in ways that it isn't to look at "current signal state". Now, it might be worth it to have some kind of "this mm is dying, don't bother" thing. We _kind_ of have things like that already in the form of the MMF_OOM_VICTIM flag (and TIF_MEMDIE is the per-thread image of it). It might be reasonable to have a MMF_DYING flag, but I'm not even sure how to implement it, exactly because of that "this thread group may be dying, but the MM might still be attached to other tasks" issue. For example, if you do "vfork()" and the child is killed, the mm is still active and attached to the vfork() parent. Similarly, on a trivial level, a particular thread might be killed without the rest of the threads being necessarily killed. Again, for regular "madvise()" it makes sense to look at whether the _current_ thread is being killed - because that fundamentally interrupts the operator. But for somebody else, operating on the mm of a thread, I really think it's wrong to look at the target thread state and leave the MM operation in some half-way state. Linus 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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52A18C433DF for ; Sat, 15 Aug 2020 14:57:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1130623110 for ; Sat, 15 Aug 2020 14:57:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="RYCK8ewE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1130623110 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7FF306B0002; Sat, 15 Aug 2020 10:57:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AFAB6B0005; Sat, 15 Aug 2020 10:57:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69EE96B0006; Sat, 15 Aug 2020 10:57:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id 518C06B0002 for ; Sat, 15 Aug 2020 10:57:37 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 04687181AEF15 for ; Sat, 15 Aug 2020 14:57:37 +0000 (UTC) X-FDA: 77153106954.25.desk54_4804fac27006 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id BCEC11804E3A1 for ; Sat, 15 Aug 2020 14:57:36 +0000 (UTC) X-HE-Tag: desk54_4804fac27006 X-Filterd-Recvd-Size: 6472 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Sat, 15 Aug 2020 14:57:36 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id i10so12904576ljn.2 for ; Sat, 15 Aug 2020 07:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3XlBZ6/uS++fkskLWFm8hL4f2NZ/FD4ZhqhfsdhmxAA=; b=RYCK8ewEScLRlrt+evxmgkhxFJOtwVQUtJeT7zY0r8OPXIcAaP0URnYs26SgWiukwg 3xvMTroCRD16NUz4HcgP1nfS2KTxzngiSJc/ZSLB5Hh1+ysGUSSdS/YqxYHpZ8w8iNMZ bJrZwR1AH2gre3kG7OfuOl4xzQcyqsVm19Gr0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3XlBZ6/uS++fkskLWFm8hL4f2NZ/FD4ZhqhfsdhmxAA=; b=USD7LzgzcgkKa8NVWbemukBHLMFvxoLTBbY0MN6uLMJYU64G2+55NeUH6+to81nEQY ZKq/WCxEnOOk1PMKJYGMEgrteYSN3sYiMWb+2MF03WnTWyu0tFGhqhcBHEqfSTUp63Mk VVJUu9ffY9jzxzMR2boTxi++GoGU2Y3pH0ZggDLkHIzY3AJl+8Rf9ZEuYxQ5VziKfugI 9h8OwTIPiYhPBkDo4FwJdI9v3HlPl1bfh6fQLuGNr0orr1HAntng3C9NhgZGIS1rPbdp ba8OEC+aIwobodvgfaTCyZr9VGU7K5N8goz54VS9x5SdTPj4+g2bONpGx7MABYxInICX oCuQ== X-Gm-Message-State: AOAM530dM2NgC1e4O8n015Oyp4eqzR0hylEVQxOK+h2q1H1PpCGBqlkc rOQ8gR3XRy/+E4Lf4jWnrQvw5Bw+MuNvAg== X-Google-Smtp-Source: ABdhPJy32FfVDuhW0DnVnsxy8kCqpD1ihz57t0IvSN73mgtWA9xeZJoDTegk5rwUZ/kled9ckEslBw== X-Received: by 2002:a2e:9cd2:: with SMTP id g18mr3414849ljj.448.1597503453796; Sat, 15 Aug 2020 07:57:33 -0700 (PDT) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com. [209.85.167.53]) by smtp.gmail.com with ESMTPSA id n205sm2618435lfd.59.2020.08.15.07.57.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Aug 2020 07:57:32 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id j22so6242878lfm.2 for ; Sat, 15 Aug 2020 07:57:32 -0700 (PDT) X-Received: by 2002:a05:6512:241:: with SMTP id b1mr3563049lfo.125.1597503451806; Sat, 15 Aug 2020 07:57:31 -0700 (PDT) MIME-Version: 1.0 References: <20200814172939.55d6d80b6e21e4241f1ee1f3@linux-foundation.org> <20200815003102.dzZiwVm-K%akpm@linux-foundation.org> <20200815045900.GA2936603@google.com> In-Reply-To: <20200815045900.GA2936603@google.com> From: Linus Torvalds Date: Sat, 15 Aug 2020 07:57:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 18/39] mm/madvise: check fatal signal pending of target process To: Minchan Kim Cc: Andrew Morton , Alexander Duyck , Jens Axboe , Brian Geffon , Christian Brauner , Christian Brauner , Daniel Colascione , Johannes Weiner , Jann Horn , John Dias , Joel Fernandes , Kirill Tkhai , linux-man , Linux-MM , Michal Hocko , mm-commits@vger.kernel.org, Oleksandr Natalenko , David Rientjes , Shakeel Butt , sj38.park@gmail.com, sjpark@amazon.de, Sonny Rao , Sandeep Patil , Suren Baghdasaryan , Tim Murray , Vlastimil Babka Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BCEC11804E3A1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 14, 2020 at 9:59 PM Minchan Kim wrote: > > Currently, madvise(MADV_COLD|PAGEOUT) already have done it. I just wanted > to sync with it with process_madvise. Ting was process_madvise couldn't > get target task while madvise could get it easily. The thing is, for "current" it makes sense. It makes sense because "current" is also the one doing the action, so when current is dying, stopping the action is sane too. But when you target somebody else, the signal handling simply doesn't make any sense at all. It doesn't make sense because the error code doesn't make sense (EINTR really is about the _actor_ getting interrupted, not the target), but it also doesn't make sense simply because there is no 1:1 relationship between the target mm and the target thread. The pid that was the target may be dying, but that does *not* mean that the mm itself is dying. So stopping the operation arbitrarily somewhere in the middle is a fundamentally insane operation. You've done something partial to a mm that may well still be active. So I think it's simply conceptually wrong to look at some "target thread signal state" in ways that it isn't to look at "current signal state". Now, it might be worth it to have some kind of "this mm is dying, don't bother" thing. We _kind_ of have things like that already in the form of the MMF_OOM_VICTIM flag (and TIF_MEMDIE is the per-thread image of it). It might be reasonable to have a MMF_DYING flag, but I'm not even sure how to implement it, exactly because of that "this thread group may be dying, but the MM might still be attached to other tasks" issue. For example, if you do "vfork()" and the child is killed, the mm is still active and attached to the vfork() parent. Similarly, on a trivial level, a particular thread might be killed without the rest of the threads being necessarily killed. Again, for regular "madvise()" it makes sense to look at whether the _current_ thread is being killed - because that fundamentally interrupts the operator. But for somebody else, operating on the mm of a thread, I really think it's wrong to look at the target thread state and leave the MM operation in some half-way state. Linus