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=-2.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,FSL_HELO_FAKE,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 49B28C433E1 for ; Sat, 15 Aug 2020 18:35:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E4E9F23117 for ; Sat, 15 Aug 2020 18:35:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lBsEOG3/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4E9F23117 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 42D356B0002; Sat, 15 Aug 2020 14:35:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B68D6B0003; Sat, 15 Aug 2020 14:35:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27D476B0005; Sat, 15 Aug 2020 14:35:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 0EF3C6B0002 for ; Sat, 15 Aug 2020 14:35:03 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7C1028248076 for ; Sat, 15 Aug 2020 18:35:02 +0000 (UTC) X-FDA: 77153654844.29.sink43_370993227007 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 525BF18086CD2 for ; Sat, 15 Aug 2020 18:35:02 +0000 (UTC) X-HE-Tag: sink43_370993227007 X-Filterd-Recvd-Size: 7029 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Sat, 15 Aug 2020 18:35:01 +0000 (UTC) Received: by mail-pl1-f193.google.com with SMTP id f10so5561767plj.8 for ; Sat, 15 Aug 2020 11:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hPqHDO0S+XL6QqHpVaCwL+AGobW4RXl16iXYcSuPMZA=; b=lBsEOG3/f7tuGUD7xW/y+tmQ0/ZBbY0YFIQvx5AJA5LiyQPpKwn18wXBDOPdoCf4Xp XnWDEb9eJgEvTtLnMVx4st1PEC6vRws3PS5r3lXROtGPiavrFLRpwqgNJn56H7IfENdT S5AKMkiCEc52rz01kZs06hT51RAgXI/dO6zbjtLeN3Or0ly/H9+IaMhr7Anu+dTRE9ZD 0nGYatNerJsj/zUUB/0Y0f8ZHDaVf5ZWWU1xZEkcJ28gd2W2csQGlh51oKcwc5Y9l3Fe bJ8vkhykMMUxoPsoptBzeSzXUa/jDn7Urct9OzRZiJJFrVwIw5yR4xpaXz2j/6NOT3Dj zm/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=hPqHDO0S+XL6QqHpVaCwL+AGobW4RXl16iXYcSuPMZA=; b=d81iAHefaoJoDlrXbmfH5j6keV8ICiw8v3mOwQ56VQg6himWJFR/IxR7eswfRXuB5z SXpvsxPdpRvDNxiCXINkUDU3NBCtv7zLKXYydJjTAaKAh3hp2VtJ8WNgD6YP9C8mRHO+ xTHGvJfHqLLWqkwOXnaoEIvfemx/wup+/Kd2RbrHWFRotbRokXTCEA+WIhwUSs54SvF8 gxsGkr/36aTQUKtsm4ityKnrP8CGX2jxQ9lgSSzeXZofey2HQvedSL/fS0g9kQaJwlSh Sv2jMqOu7c396ochWrqPeUC6nf2A+SpsXjhD1kbu3hitQnytJxiS1tZkAXoL70y9LUBM HUbw== X-Gm-Message-State: AOAM531Cok0HYHzI1Ei6bWIiIxeMqgK7pTgpxSwXT0cqB1xQSaBiMQOV dhNKTASu1Whv67W1YjWeI28= X-Google-Smtp-Source: ABdhPJyTvx50xSuwYoesmqNHShDKrniwc8fdH/zMI9I2zMQ5dvQi+rLeIfIPD7TGqElWHUz9PBsOuA== X-Received: by 2002:a17:902:ff16:: with SMTP id f22mr5993896plj.269.1597516500701; Sat, 15 Aug 2020 11:35:00 -0700 (PDT) Received: from google.com ([2620:15c:211:1:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id t33sm11723192pga.72.2020.08.15.11.34.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2020 11:34:58 -0700 (PDT) Date: Sat, 15 Aug 2020 11:34:56 -0700 From: Minchan Kim To: Linus Torvalds 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 Subject: Re: [patch 18/39] mm/madvise: check fatal signal pending of target process Message-ID: <20200815183456.GB2936603@google.com> References: <20200814172939.55d6d80b6e21e4241f1ee1f3@linux-foundation.org> <20200815003102.dzZiwVm-K%akpm@linux-foundation.org> <20200815045900.GA2936603@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 525BF18086CD2 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Sat, Aug 15, 2020 at 07:57:15AM -0700, Linus Torvalds wrote: > 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. True. > > 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". Agreed. > > 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. Maybe, we could use mm_struct's mm_users to check caller is exclusive owner so that rest of all are existing. > > 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. I agreed. I will drop this single patch with revising previous patch not to make passing task_struct since the idea. We could revist if someting real trouble happens. Please tell me if you found something weird in this patchset series so that in next cycle we could go smooth. Thanks for the review, Linus.