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 B28EEC433DF for ; Sun, 16 Aug 2020 01:43:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6E20220675 for ; Sun, 16 Aug 2020 01:43:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="RGJPE4Vt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E20220675 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 D00BD6B0002; Sat, 15 Aug 2020 21:43:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8A126B0003; Sat, 15 Aug 2020 21:43:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B51246B0005; Sat, 15 Aug 2020 21:43:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id 9D2686B0002 for ; Sat, 15 Aug 2020 21:43:29 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 649B4180AD81D for ; Sun, 16 Aug 2020 01:43:29 +0000 (UTC) X-FDA: 77154734538.09.boy70_370348b2700a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 43CBE180AD81A for ; Sun, 16 Aug 2020 01:43:29 +0000 (UTC) X-HE-Tag: boy70_370348b2700a X-Filterd-Recvd-Size: 5842 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Sun, 16 Aug 2020 01:43:28 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id h19so13744726ljg.13 for ; Sat, 15 Aug 2020 18:43:28 -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=Bq4OvIdUwJpvYSOGzcS+78yeINRY4Kp3Rheq3HGXWqA=; b=RGJPE4Vt9YCW6xMiFm6gOV/bpmeJj1OTOb3RWIIa/uoStX7cdU2zvwR+F8W1W2Mapj PGU0b/7unQXLaJIOsdd7078nTUQmAoAP3BsQQEO7rza76S3TkrPaWumXMHldka7FYVOV +PjpXtJcaiT/r/4sadt4O/2YE2jZR00WJ0dys= 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=Bq4OvIdUwJpvYSOGzcS+78yeINRY4Kp3Rheq3HGXWqA=; b=tApJsgH5cB7Xyi26SSezT3JpJ5Llw2FHncVN5jtHaghueTBq728peCJlrspJ5ekW4W JEKFBwuL4PskbcvW/Bk/CljDPbsJIHTu5uEuDek/hEGC9dlhcPH93G2wjuV2g6apV8cl ED4V+ysAWP0at8k8n9eBQ7aRegvh4cX9g4n6ZM9i5DXI2R8WDKL0wa9t1Xx5YnRdrLvD eOgHCob1uA0yPbdJQi6ev2gTGOAYE40gRTvuHPzcBOACwQpHDeCJH07H+6V3gYMdfy+W bNGJGBCDJ+WhZZt0j5mG2uPG29fW1mXDmUz/2lcE/w/dOA7N0WPmsYB2Dep0WBzT9Ryy c6CQ== X-Gm-Message-State: AOAM531jx8cY/d/KpWzemLBkpu0dDAejL0l1Dna2KxrFxW9NMINGGL9+ JN1juam5cVmHG4F3ugK16aIATZGhHBdOEw== X-Google-Smtp-Source: ABdhPJy2j5SMZVK+mekE89ZqxLWgf8U+4gmBjYM/8+kpXY3pIUjped4ChfxVW7vS4hksXYw1kt7Dtw== X-Received: by 2002:a2e:9a53:: with SMTP id k19mr4485548ljj.272.1597542206592; Sat, 15 Aug 2020 18:43:26 -0700 (PDT) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id z25sm2960329lji.33.2020.08.15.18.43.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Aug 2020 18:43:25 -0700 (PDT) Received: by mail-lf1-f50.google.com with SMTP id i80so6605781lfi.13 for ; Sat, 15 Aug 2020 18:43:24 -0700 (PDT) X-Received: by 2002:a19:408d:: with SMTP id n135mr4357315lfa.192.1597542204274; Sat, 15 Aug 2020 18:43:24 -0700 (PDT) MIME-Version: 1.0 References: <20200814172939.55d6d80b6e21e4241f1ee1f3@linux-foundation.org> <20200815003102.dzZiwVm-K%akpm@linux-foundation.org> <20200815045900.GA2936603@google.com> <20200815183456.GB2936603@google.com> In-Reply-To: <20200815183456.GB2936603@google.com> From: Linus Torvalds Date: Sat, 15 Aug 2020 18:43:08 -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: 43CBE180AD81A 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 11:35 AM Minchan Kim wrote: > > > 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). > > Maybe, we could use mm_struct's mm_users to check caller is exclusive > owner so that rest of all are existing. Hmm. Checking mm_users sounds sane. But I think the /proc reference by any get_task_mm() site will also count as a mm_user, so it's not quite as useful as it could be. In an optimal world, all the temporary "grab a reference to the mm" would use mmgrab/mmdrop() that increments the mm_count, and "mm_users" would mean the number of actual threads that are actively using it. But that's not how it ends up working. mmgrab/mmdrop only keeps the "struct mm_struct" around - it doesn't keep the vma's or the page tables. So all the /proc users really do want to increase mm_users. I don't see any obvious thing to check for that would be about "this mm no longer makes sense to madvise on, because nobody cares any more". > Please tell me if you found something weird in this patchset series > so that in next cycle we could go smooth. No, the only other thing that worried me was just possible locking, but it looked like we already have all the "access page tables from other processes" situations and it didn't seem to introduce anything new in that respect. Linus