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 C9949C433E1 for ; Sun, 16 Aug 2020 01:43:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AAB5620675 for ; Sun, 16 Aug 2020 01:43:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597542211; bh=0b3XlekOm7dvUqQmG16A2319uBfmvaTrrrTAXsK9uGo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=x1OBnAQyJWrpyO6m7t2nGdGnfnL5tlRasoQBHeC+H24Wjc6zbBWVQvaFqTqASQM4q UlaUFXHM5R/wTlA9xgcjW3YUEHEwjSpxeuOOc6cDwCZzPNZEVeQj1G6/9h5pOOR4cK qWVcYoK9by9Ej1TJFw6AmIUhTd+xG65GL0zTC0Gk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728706AbgHPBna (ORCPT ); Sat, 15 Aug 2020 21:43:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728111AbgHPBn3 (ORCPT ); Sat, 15 Aug 2020 21:43:29 -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 C1506C061786 for ; Sat, 15 Aug 2020 18:43:28 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id h19so13744725ljg.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=tKPgFmTh14XCFQ2o1DuXaqCD1+ONpuLdNGfk6G32kLCVAqPah4p8JL6v3f5vPQAKeS MxqdD0AEKao62Hnwla3f46cGNv6JpspZoK3mLtwDojWRGwWZEUCZhDPMQsgjj3x+uMnJ Fm9u6zSiZzf5ZrXI1BAZxBHYnDoav3hCwvlrRXSKo/CElljrNMqsQp+6dWzpuy85GMnv AQG5WMMDBFN3mWUgOQM+lS4E/DBSp6cSwxZ4d/6q4Xk30i0bladcpckSRd1ZQIcQ2FWw SbgLNFAbLRs1QuvJ7wXjxe4UUTzjHysje1zg9Ng+nXhIeDI14Xehn1qLQBYcXYVE+Mqb kDQg== X-Gm-Message-State: AOAM530cU5BuK5ZmNTSxt9jUfpHTyc7EazZYuQOtzjhkT+9gtZG1XUXm z/myN6Y6eRE3oRTkLfd2kLNt0ZJG2iVv/A== X-Google-Smtp-Source: ABdhPJzFM/Qp8G56RpBI6dTNBaTdv20uNv/CrRbd22dVqvvvh7BzgevdMM+ysxE7yEtRAf3ROUQbmA== X-Received: by 2002:a2e:5c5:: with SMTP id 188mr4193654ljf.466.1597542206724; Sat, 15 Aug 2020 18:43:26 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id t20sm2956503ljd.12.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-f47.google.com with SMTP id b30so6625290lfj.12 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" Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org 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 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