Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Tue, 28 Nov 2023 09:51:08 -0500
From:   Gregory Price <gregory.price@memverge.com>
To:     Michal Hocko <mhocko@suse.com>
Cc:     Gregory Price <gourry.memverge@gmail.com>, linux-mm@kvack.org,
        linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
        linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
        arnd@arndb.de, tglx@linutronix.de, luto@kernel.org,
        mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
        x86@kernel.org, hpa@zytor.com, tj@kernel.org, ying.huang@intel.com
Subject: Re: [RFC PATCH 06/11] mm/mempolicy: modify do_mbind to operate on
 task argument instead of current
Message-ID: <ZWX+XL7+gmr/l/go@memverge.com>
References: <20231122211200.31620-1-gregory.price@memverge.com>
 <20231122211200.31620-7-gregory.price@memverge.com>
 <ZWX0-hEjqkmnR1Nq@tiehlicka>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZWX0-hEjqkmnR1Nq@tiehlicka>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?gyyk/Iy4Cvamq0arg7zCpgtUF4FFWXj0WoXRNm84sE+0BPED70VtMxgGXbBa?=
 =?us-ascii?Q?Lnti6Q+EDHfH2HmgM9RPBXqQ/HbuBJ2oQWtNsIgISucPBswnFgyN09IzKJze?=
 =?us-ascii?Q?o0j3qESMs9D0qWGCwRBDIMmr63HCUmWAcHpZR3G0d/JjJyfdxamen/NFTiza?=
 =?us-ascii?Q?8O7oiQEd0VZ3tcL+4ANF+tLEmvSDYiorZAb3FqqPLhvdb6uW1FvJhnDBvkMT?=
 =?us-ascii?Q?WMm0JwEj3K1qPqOkeYFXzVMHffXwErKwBcXuWzSyxzd3AFSSPmQ5Rem7I1nP?=
 =?us-ascii?Q?31I1fa22ehf7jvqrJM6V2pnZWWINAlaM/FqLV8G+CIYQD1Gnq3esU68ssJLn?=
 =?us-ascii?Q?aBd6LtD0nncrbj3cEXNVgz36jHPTcXa+txZN6ZSX2zRKo9DEMwJ6ZCo4yvSL?=
 =?us-ascii?Q?1bA8BDAF3yBY8m207DTYKOjwdZfjgAYIe6+iOkdPaftaMjdXeBW/7PA+ZxU8?=
 =?us-ascii?Q?zOPIxfbF9u8b/E2pUPWPbpDoVRtTlOjwJG6yDpa5x3mjYum2YKBs2HqNL04c?=
 =?us-ascii?Q?9AyBmEXlpdWfVkO4x/udibgTAGCwEH8toncBUpTISh0dt6nbbShMs5mowHY/?=
 =?us-ascii?Q?PsgQ9C85FCV4dTrkvpWiMeiybMDW9u9cDsuUVLed2PiOkgaWCD0voUtP90MF?=
 =?us-ascii?Q?4FkQtZR6JVKXAP1y6SnLfOpo/oCgkKKql+ceOOVVKWK8VoN0drpJSjuHpnS/?=
 =?us-ascii?Q?lFIMHKJEBCCTZmSMtcL4LsNedX3N5LM1iuy6xcRTjodzdgppp/jxsgD6Cedf?=
 =?us-ascii?Q?KAbszsU96HqMWYczVdqEHtThu1s0yORWEevt+O7O9ltELea2bzZPcf8FGhSv?=
 =?us-ascii?Q?pKq9kai+WjIGA1HMfhry9He1sOD6piCfiwlOkT1DCuIolcdpE98nQbJllkqf?=
 =?us-ascii?Q?84gh3yhSCZ/fBZWGvwZAerwbshvlR42/UnEUvWh00L8VIGuipIUcQZZE00Mc?=
 =?us-ascii?Q?CWYI+KfoKPiZNqb7fldVe5rLbyN6SwpUWWCECzwS3pfXSzK0JlKF/izuJ2SJ?=
 =?us-ascii?Q?RVGf3RafSuYN8KnuyaQydpSpPzyQJTSIyb5iiuV7CMJqH0At/GG0PrNKGmo6?=
 =?us-ascii?Q?VkTyGpdPq4dLo5Hgrq9dzqpD0z4+FojfioyLSK6a/kkQzT4DViOt3+dcyspz?=
 =?us-ascii?Q?gKPRPKPcO0IPB8uHp9oLKFNXlZLENaDq2rz9E3RQiYVdlvBqOPiNfhquLD6L?=
 =?us-ascii?Q?EGstIcPx0O50Jdk4LOWSxCC8crkCWZ3Na2jYfdsJhjK4XLUQ6mCqCNzRlBgI?=
 =?us-ascii?Q?1kGgGhmGO4sz1vVhGCdVxZd6kd8fV5iyqd9R5AfO7SjFrW9xVMYgHPKziQWy?=
 =?us-ascii?Q?ks33geCxYIGnbNxqHc3t/7E91voG2qSZ2rWO3OHGq47jR4So4xlnlBpTp9H/?=
 =?us-ascii?Q?dwIS3JkN+BQZx8N7aF0pS2Rmud3xrrmkIgU5de07gD+xKfVrpPlZQBEyhg5N?=
 =?us-ascii?Q?0gQ0lCCBsGpiJ0U7HgtJWUhZ+JwJR/OadRfuaL6BqJJbUqgvBlJsmt/bnt3m?=
 =?us-ascii?Q?inDjEzA8ng0PeMfNVfn/If/nwhD7FVno0tJQ7/SsJK5+IEUEZ+4EUlj2dau/?=
 =?us-ascii?Q?cQxyqVKRtOiZ+Xm3Q/2VcuYEBrhZfCGbZH690IWZ93plADeFF19sDFonN9iU?=
 =?us-ascii?Q?dA=3D=3D?=
X-OriginatorOrg: memverge.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4810fc7d-0249-4544-5943-08dbf02179a3
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB5512.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2023 14:51:16.9337
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5c90cb59-37e7-4c81-9c07-00473d5fb682
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2vTYPlIXuVqEoU3frhq0qus2YCCPhKuV+iv6xXe93YXRPvlKMdWY5b3Ik2YiDwznCUE5dfFOaQAJIsAHKrtl+wyrB2VTrwXuKbhSlTigD/w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR17MB6665
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 28 Nov 2023 06:53:23 -0800 (PST)

On Tue, Nov 28, 2023 at 03:11:06PM +0100, Michal Hocko wrote:
> On Wed 22-11-23 16:11:55, Gregory Price wrote:
> [...]
> > + * Like get_vma_policy and get_task_policy, must hold alloc/task_lock
> > + * while calling this.
> > + */
> > +static struct mempolicy *get_task_vma_policy(struct task_struct *task,
> > +					     struct vm_area_struct *vma,
> > +					     unsigned long addr, int order,
> > +					     pgoff_t *ilx)
> [...]
> 
> You should add lockdep annotation for alloc_lock/task_lock here for clarity and 
> also...  
> > @@ -1844,16 +1899,7 @@ struct mempolicy *__get_vma_policy(struct vm_area_struct *vma,
> >  struct mempolicy *get_vma_policy(struct vm_area_struct *vma,
> >  				 unsigned long addr, int order, pgoff_t *ilx)
> >  {
> > -	struct mempolicy *pol;
> > -
> > -	pol = __get_vma_policy(vma, addr, ilx);
> > -	if (!pol)
> > -		pol = get_task_policy(current);
> > -	if (pol->mode == MPOL_INTERLEAVE) {
> > -		*ilx += vma->vm_pgoff >> order;
> > -		*ilx += (addr - vma->vm_start) >> (PAGE_SHIFT + order);
> > -	}
> > -	return pol;
> > +	return get_task_vma_policy(current, vma, addr, order, ilx);
> 
> I do not think that all get_vma_policy take task_lock (just random check
> dequeue_hugetlb_folio_vma->huge_node->get_vma_policy AFAICS)
> 

hm, i might have gotten turned around on this one.  Forgot to check for
external references to get_vma_policy.  I thought I considered it, but i
clearly did not leave myself any notes if I did.

This pattern is troublesome, we're holding the task lock during the
callback stack in __get_vma_policy - just incase that returns NULL so we
can return the task policy instead.  If that vma is shared, it will take
the vma shared policy lock (sp->lock)

I almost want to change this interface to return NULL if the VMA doesn't
have one, and change callers to fetch the task policy explicitly instead
of implicitly returning the task policy.  At least then we'd only take
the task lock on an explicit access to the *Task* policy.

> Also I do not see policy_nodemask to be handled anywhere. That one is
> used along with get_vma_policy (sometimes hidden like in
> alloc_pages_mpol). It has a dependency on
> cpuset_nodemask_valid_mems_allowed. That means that e.g. mbind on a
> remote task would be constrained by current task cpuset when allocating
> migration targets for the target task. I am wondering how many other
> dependencies like that are lurking there.

bah!

thought i dug all these out, but i missed alloc_migration_target_by_mpol
from do_mbind.

I'll need to take another look at the calls to cpusets interfaces to
make sure i dig this out.  The number of hidden accesses to current is
really nasty :[ 

> -- 
> Michal Hocko
> SUSE Labs