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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 00B27C433E1 for ; Sun, 16 Aug 2020 05:58:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B556B20735 for ; Sun, 16 Aug 2020 05:58:48 +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="ppr1dL0a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B556B20735 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 43B166B0002; Sun, 16 Aug 2020 01:58:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C45B6B0003; Sun, 16 Aug 2020 01:58:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23E676B0005; Sun, 16 Aug 2020 01:58:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 07EEA6B0002 for ; Sun, 16 Aug 2020 01:58:48 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B2ED9181AEF2A for ; Sun, 16 Aug 2020 05:58:47 +0000 (UTC) X-FDA: 77155377894.24.screw37_4807ce62700b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 7FE681A4A0 for ; Sun, 16 Aug 2020 05:58:47 +0000 (UTC) X-HE-Tag: screw37_4807ce62700b X-Filterd-Recvd-Size: 6598 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Sun, 16 Aug 2020 05:58:46 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id x25so6564008pff.4 for ; Sat, 15 Aug 2020 22:58:46 -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=xfDUny3k7daRnnu+JmgS0reVwLpN25X4sfvcLKXBtAY=; b=ppr1dL0afMTfeBMU26Ry6HP9oZgglRKtNXSzJ7/C2unWRWOjOfrudYAY98QPyjnB+8 KIkp0LJfbgdfUOFPsq749IFMhQXRyB23vjAH6e8290xQ9AJMYN5AGhvbVUmAafOQ3OGu FVINmTGVIZQRG5XMcuqQdSYeZPcU237+rA6dOJ9V0TWX2J1keaOgRunsNmsJdzKnSNPm UthjvBaJEsXtk8v82DDswyO7J1uNftajGvJscJ4sxfAOjiPX4on2zqVlE4oEcUfm/KVS oMtwYYila44C6wvcsml0MiBEkBwUqMpzv6Scx7GTF/LrU8XRcvpyS3YwBPWthvCPq9OC mHsg== 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=xfDUny3k7daRnnu+JmgS0reVwLpN25X4sfvcLKXBtAY=; b=qrG3egqKZg/7+0QkCzRghLzfcCwa6tgvCJqm3tPYsk7NR16uJ3OcCa1gnX1RMMA/87 vENunw8eyasscpV6V8WNAGw466Tn5jLbxxhc2kycrpnSr5rzcPboB11vbENLEwcCFB6Y AiNbzoIRDflXzw1wWe36rHuNtytYtZQc/fmlKhp3pGF+RjuGLJRwadObn1/zcix7umhw Q19pCPkU9s95yfqZsqFkC+sC99v37fkiAYDTdp25QlY3YFtLCTSwEMkg0CwXEF/LHdRo A5eAoJmAunCYrCsq/C8jVU7LhGBHN0c0Jb0kQFMNCW3ZkOuCywpWVOtvMWD0MhDTvo2P oSGQ== X-Gm-Message-State: AOAM5335vhe7sZGbu01R4SpB7uZYctNk5CBu8M46HzXLBELzfdTqHjWD 9eUIAPlsxX771qfb2kAIt00= X-Google-Smtp-Source: ABdhPJxgN2Swg5sZvzFSSyw6l9VUX6BEV7hl0Vqn3E5mwWLJ7Jk5lpNsmVi6MdmVjWmcddXQ4R662g== X-Received: by 2002:a63:cd56:: with SMTP id a22mr6204061pgj.259.1597557525701; Sat, 15 Aug 2020 22:58:45 -0700 (PDT) Received: from google.com ([2620:15c:211:1:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id 74sm13319854pfv.191.2020.08.15.22.58.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2020 22:58:44 -0700 (PDT) Date: Sat, 15 Aug 2020 22:58:42 -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: <20200816055842.GC2936603@google.com> References: <20200814172939.55d6d80b6e21e4241f1ee1f3@linux-foundation.org> <20200815003102.dzZiwVm-K%akpm@linux-foundation.org> <20200815045900.GA2936603@google.com> <20200815183456.GB2936603@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 7FE681A4A0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 06:43:08PM -0700, Linus Torvalds wrote: > 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". Yeah, there are bunch of places where makes false negaive potentially as well as proc but I expected it would be rather rare and even though it happens, finally, we can catch it up if they are temporally holding the refcount but our operation runs long. At worst case, it could make the operation void so we just wastes but when I consider the logic as optimization, it wouldn't be harmful to start with such *simple check* rather than adding more complication. If you still don't like the idea, at this point, I will drop the single patch as I mentioned because I don't think I have strong justification to add more complication here. > > > 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. Thanks for the review, Linus.