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 F1B9FC433EF for ; Mon, 7 Mar 2022 02:32:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80C7C8D0002; Sun, 6 Mar 2022 21:32:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BAE88D0001; Sun, 6 Mar 2022 21:32:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C568D0002; Sun, 6 Mar 2022 21:32:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 57AF58D0001 for ; Sun, 6 Mar 2022 21:32:17 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 21C2521632 for ; Mon, 7 Mar 2022 02:32:17 +0000 (UTC) X-FDA: 79216015914.13.1272526 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf19.hostedemail.com (Postfix) with ESMTP id 0A03E1A000A for ; Mon, 7 Mar 2022 02:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646620336; x=1678156336; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=SXGeXglSX4APogB18NQWD6xuQzy9t/El59W1w6Dfh40=; b=KzqQBM/HAYw1ml/Xm1rr4nKINSTQ+hVkLOmba0QrvTvN7r9ODnoAMt6H QJxM5toCOM5p5y5vA61+tnd3DPrCJPP3OVAWRUvG1qqGM/jZwtx3U6Sfz 3t4KiCQ0diYmEFzH802noXWZUgCAGNZVSTiRDXBUO8eKbCEadrWKJTK4F N4OBBPVaTtOHa4EWooJntSfx1+gthxVwRcQs7TEUCfJLPA2xll6GbbICR Xf1Oe6+lz5VXbX4aYXYppt7bMYMhZ2tg+zBsBfTPcYTKiNEufRFIlLUw3 MgoXJ4J9h5vzBQaK23+y0IVbSbVbqhrHeROtmUdz5XnczhiBuAE4tt/Ay A==; X-IronPort-AV: E=McAfee;i="6200,9189,10278"; a="254220455" X-IronPort-AV: E=Sophos;i="5.90,160,1643702400"; d="scan'208";a="254220455" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2022 18:32:14 -0800 X-IronPort-AV: E=Sophos;i="5.90,160,1643702400"; d="scan'208";a="643070548" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2022 18:32:08 -0800 From: "Huang, Ying" To: Miaohe Lin Cc: , , , , , , , , , , , , , , , , , , Christoph Lameter , David Howells , Linus Torvalds Subject: Re: [PATCH 04/16] mm/migration: reduce the rcu lock duration References: <20220304093409.25829-1-linmiaohe@huawei.com> <20220304093409.25829-5-linmiaohe@huawei.com> Date: Mon, 07 Mar 2022 10:32:06 +0800 In-Reply-To: <20220304093409.25829-5-linmiaohe@huawei.com> (Miaohe Lin's message of "Fri, 4 Mar 2022 17:33:57 +0800") Message-ID: <8735ju7as9.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 0A03E1A000A X-Stat-Signature: ek5rbdwdmqfg6a7c7q4x89747ojy1spk Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="KzqQBM/H"; spf=none (imf19.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646620335-510608 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: Miaohe Lin writes: > 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. > > 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 da5a81052468..26943bd819e8 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)) Digged some history via `git blame`, found that the RCU read lock is extended in the following commit, " 3268c63eded4612a3d07b56d1e02ce7731e6608e Author: Christoph Lameter AuthorDate: Wed Mar 21 16:34:06 2012 -0700 Commit: Linus Torvalds CommitDate: Wed Mar 21 17:54:58 2012 -0700 mm: fix move/migrate_pages() race on task struct Migration functions perform the rcu_read_unlock too early. As a result the task pointed to may change from under us. This can result in an oops, as reported by Dave Hansen in https://lkml.org/lkml/2012/2/23/302. The following patch extend the period of the rcu_read_lock until after the permissions checks are done. We also take a refcount so that the task reference is stable when calling security check functions and performing cpuset node validation (which takes a mutex). The refcount is dropped before actual page migration occurs so there is no change to the refcounts held during page migration. Also move the determination of the mm of the task struct to immediately before the do_migrate*() calls so that it is clear that we switch from handling the task during permission checks to the mm for the actual migration. Since the determination is only done once and we then no longer use the task_struct we can be sure that we operate on a specific address space that will not change from under us. " After that, the permission checking has been changed from __task_cred() to ptrace_may_access(). So the situation may change somewhat. Cced some names found in git history to verify. Best Regards, Huang, Ying