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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 108D3C433FE for ; Tue, 12 Apr 2022 02:07:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 66E2D6B0073; Mon, 11 Apr 2022 22:07:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61C666B0074; Mon, 11 Apr 2022 22:07:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E5B56B0075; Mon, 11 Apr 2022 22:07:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 4068C6B0073 for ; Mon, 11 Apr 2022 22:07:26 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 07BFE24448 for ; Tue, 12 Apr 2022 02:07:26 +0000 (UTC) X-FDA: 79346590092.04.8D10E50 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf15.hostedemail.com (Postfix) with ESMTP id 6C3E8A0003 for ; Tue, 12 Apr 2022 02:07:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649729244; x=1681265244; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=6kiwW3/nUQ5dHrFHY7pnkV2uT9+KRnLaqlbep6xwdc8=; b=ModvDwpkP0+rhHpkVPlBEFw4739XzeaddNk3q9iOdvfPYNNg/2iLp8+r 1KfKXAmclYI0Q46tvw7AhRiCgHionPvnb3QzjQdh2+DG19N/rCeqSIywV Ot9Pl0woaCZPP+GMl66tXgwFk8aQqcmTUOFU0dZCf0g4Rv4pFBIgKSkF5 AdzKe5BoPFz+4EAlqz67t5XypA28nvMInAhzsb7LI2gv1thFhRMopIsp+ rE5WQFl/cNiaD5f6FLDKb/lp57tVQBr5X/GC7TU+dRve5vH3yR7FBkYgP 8zm0VMoH+HFUr0Zr61HMu86lpM5I1O8+4YZRk6cHmQOe40a5ysbQBqjsX g==; X-IronPort-AV: E=McAfee;i="6400,9594,10314"; a="262002692" X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="262002692" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 19:07:23 -0700 X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="551486957" Received: from joliu-mobl2.ccr.corp.intel.com ([10.254.214.243]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 19:07:18 -0700 Message-ID: <557be6cc7ecdee357391df3fe94e5573f9e1746d.camel@intel.com> Subject: Re: [PATCH 1/4] mm/migration: reduce the rcu lock duration From: "ying.huang@intel.com" To: Miaohe Lin , akpm@linux-foundation.org Cc: mike.kravetz@oracle.com, shy828301@gmail.com, willy@infradead.org, ziy@nvidia.com, minchan@kernel.org, apopple@nvidia.com, dave.hansen@linux.intel.com, o451686892@gmail.com, jhubbard@nvidia.com, peterx@redhat.com, naoya.horiguchi@nec.com, mhocko@suse.com, riel@redhat.com, osalvador@suse.de, david@redhat.com, sfr@canb.auug.org.au, linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Tue, 12 Apr 2022 10:07:15 +0800 In-Reply-To: <20220409073846.22286-2-linmiaohe@huawei.com> References: <20220409073846.22286-1-linmiaohe@huawei.com> <20220409073846.22286-2-linmiaohe@huawei.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: yjukguna1xt6y7qkirou1idftatmfdxn Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ModvDwpk; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf15.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=ying.huang@intel.com X-Rspamd-Queue-Id: 6C3E8A0003 X-HE-Tag: 1649729244-128267 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, 2022-04-09 at 15:38 +0800, Miaohe Lin wrote: > rcu_read_lock is required by grabbing the task refcount but it's not > needed for ptrace_may_access. So we could release the rcu lock after > task refcount is successfully grabbed to reduce the rcu holding time. > > Reviewed-by: Muchun Song > Signed-off-by: Miaohe Lin > --- >  mm/migrate.c | 3 +-- >  1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index a3d8c2be2631..d8aae6c75990 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -1907,17 +1907,16 @@ static struct mm_struct *find_mm_struct(pid_t pid, nodemask_t *mem_nodes) >   return ERR_PTR(-ESRCH); >   } >   get_task_struct(task); > + rcu_read_unlock(); >   > >   /* >   * Check if this process has the right to modify the specified >   * process. Use the regular "ptrace_may_access()" checks. >   */ >   if (!ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS)) { > - rcu_read_unlock(); >   mm = ERR_PTR(-EPERM); >   goto out; >   } > - rcu_read_unlock(); >   > >   mm = ERR_PTR(security_task_movememory(task)); >   if (IS_ERR(mm)) Why do you ignore our discussion for the previous version? https://lore.kernel.org/linux-mm/8735ju7as9.fsf@yhuang6-desk2.ccr.corp.intel.com/ Best Regards, Huang, Ying