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 AF30DC71130 for ; Tue, 8 Jul 2025 01:53:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 281C36B03B9; Mon, 7 Jul 2025 21:53:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 232F46B03BA; Mon, 7 Jul 2025 21:53:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 149386B03BB; Mon, 7 Jul 2025 21:53:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 008BC6B03B9 for ; Mon, 7 Jul 2025 21:53:55 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5FB01128AD1 for ; Tue, 8 Jul 2025 01:53:55 +0000 (UTC) X-FDA: 83639426430.02.D0907D3 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf15.hostedemail.com (Postfix) with ESMTP id EAF68A0007 for ; Tue, 8 Jul 2025 01:53:51 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=TzUfNl39; spf=pass (imf15.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=ying.huang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751939633; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YNvT60mTax7uwp+RG6VYOLHLI7agEiPsi+dmHtnqPCI=; b=0NIH732q//iixbpEvCstr5i8mh+de8f4UdaJwQEpjb94W3TOaGq/kYRgdQgq4YKghxzjJp j6qrbbkuXSOMRpRFbCXsK1q9ZFuCPjM3+d/G1JN2F7kIjlHQntc+LjDlXvUT+wuk81Otpd bYdc3uZCBLbuMMwyK0FBxanPnD/YKgw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751939633; a=rsa-sha256; cv=none; b=vOaZC9gBBgBZ+bNpaTomWwjjW1+U/s1PEuByPKk6uyltu55037BWNgU9cXuYcluKukqc47 y8R7C+a4Rca5iYIGO5lV8ObUp6edmecE+p74tvKgRyYLh2DXPqzeTvy5zal1I2uFJ9umAw RL+es1aVTstrmZeTqfbnX0/n6StEXu0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=TzUfNl39; spf=pass (imf15.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=ying.huang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1751939629; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=YNvT60mTax7uwp+RG6VYOLHLI7agEiPsi+dmHtnqPCI=; b=TzUfNl39OUcUmqB3RcI8wMyoRnCBE3Y0tT3Xn4rqfnYSqj2ALtFvuDK8jvF0ybkBwkGoLkLU+UH4F+NI7bNGHJ/kUFCfjsqFxbSbsd4Gk2wl2Ju9wjKmn+0GV/7/EC+aFczNZ3gXROeaui8azQvqi0DawNekC2/KoMWjkucp8HQ= Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0WiIAH4n_1751939626 cluster:ay36) by smtp.aliyun-inc.com; Tue, 08 Jul 2025 09:53:47 +0800 From: "Huang, Ying" To: Jinjiang Tu Cc: Andrew Morton , David Hildenbrand , , , Peter Xu , Zi Yan , , , , , , , , Kefeng Wang Subject: Re: [Question] get_vma_policy() isn't compatible with {pin, get}_user_pages_remote In-Reply-To: <94a3d35d-0872-5696-0333-7273f4a69979@huawei.com> (Jinjiang Tu's message of "Tue, 8 Jul 2025 09:21:57 +0800") References: <94a3d35d-0872-5696-0333-7273f4a69979@huawei.com> Date: Tue, 08 Jul 2025 09:53:45 +0800 Message-ID: <87cyabxxau.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: EAF68A0007 X-Stat-Signature: obknydwuhj4j19m9tfx683ussoihycmw X-HE-Tag: 1751939631-52119 X-HE-Meta: U2FsdGVkX18nNv0r49rU/G55SuzqxvZRR1kV+VJJAwPttc+vUB4twzi/mWOjftQTNgwJGFjzkafLtJrBcxxYfsZUoqt4enTEVmD7JVZVVxvenS4B7mV8GDQ834mfgReAjb6R/1ID7IBBNON9WD/+zo0AxL4xrfpKqy0TeYBTzhUVzDQozjqhG7MPFvEJJIEZKwMyyTgYu11/UYZNbUB6d5RjoblofUqN5G3D162BHxD2KqZ2AfGxT/cnMTDVRGBjfk8KfJo6jSqFHQ66ucskS8Cr1hEmoSeCiINVJ3wY0PYxgfgiV25ko/93+DO6ADzY9TMRgmiv/CN9SyFWjWcdidzFl+cmxVQE3PxqOoEJRTMbdKplgKQKhrh2DqCtZ6yLX1+UQyvLBQ8QSbMbVpOQFEW+/opdvhuH8CY3UhhYUfb/J94KWLdgrwb+MJcaehQI8EzZKe9wPpZqxnHwtjpMhA1IcIWXDUr+njtZ5OpmCVjR+nu3RhYv9KPMduQJxOBbYHKzjohdcEDJU8KQBZFMFelF9UjZbHhepXgf6ig0AhYkX60DPJffQwuFYHDGC7MbOIMJ1AYDjfWIHTP1ISwFTyuCv0GIthCzyhDqd3Iuh4ngZQY8YFBa3Ats7Vz0qX6PQNsTtwM6U0jWHDBSNIJelgsSxQlYvuUi4ciCm+JZapIjTAfvNhwSnsswveL6iWK0W/OJ4GgIE63OAr18A8zGK3u9nfRfy88G9zv5i+vhjHJb+d09TKw6OJhQiNAYQqKjoKMU9YKY/buDIqODc4hlVpNuLMmX9bAzl9QMFBZToheDq0FPwkVg5w7EiJTTBcvSZZifNMq41HvKsc6Lwaz5oJBE2JIQFmhCT5RhVNI22oSE8wN70QzjnZGmz+qKK4TQW93/Lzkt212JRxk0bVO8rWVddg0XrPl1t85nRFRe/stCljNrYKs8YAP4DT/dArKQbhgI4YwnrwEEOm13FHE ogi8RPFs ZXxmpoThAGArboorI3OFQNrDZDC4VeD6SX/R/wSoYBuH6LxshtGzWZhUP2UGR8jIqlZDqSeXqFcZVfpsk8U6Gz1kFPi7CyH/sGQOXu2FbJ76BIfw/Vde+whFTdMY290J6QPVCYEyex8uJDS972jeqHIL/7y0QnJRgy5eYFlTD3swTh6KJtontevG9eHU0RteoKIL5LWjheUc54X4ZLSnHU2qMNf8VM5/ozDXkU8pc1HTNx1CyDx1DiTCS7tsUJ6M2U0LlZTsOGR/ecE4gvOWAJYD0DJxioyedBfu80AcKx20zflnFC4jMNLUEztHfxtSY1PpA3Uh9ke15AMefPV974tR36PxNmuYwDzGBNhPAfYoZb782T9zi5NrD2goDbvUXwB0OTowXLjxL+P9hsVHGkFti17Ku2jCpIRjAjyNnfcoMmEg= 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: List-Subscribe: List-Unsubscribe: Hi, Jinjiang, Jinjiang Tu writes: > get_vma_policy() returns the mempolicy for the vma. If the vma has set > mempolicy, the policy is returned. Otherwise, > call get_task_policy(current) to get the mempolicy of current > task. However, it isn't reasonable for > pin_user_pages_remote() and get_user_pages_remote() cases. > > Assume task A calls pin_user_pages_remote() to pin user pages from > task B. If the [start, start + nr_pages) isn't > populated with pages, handle_mm_fault() will be called by task > A. However, if the vma doesn't set memory policy, > the mempolicy of task A instead of task B is used to allocate. It > seems to be unreasonable. See > dequeue_hugetlb_folio_vma()->huge_node(). > > We can only obtain mm in get_vma_policy(), but we couldn't get the > task, since a mm can be associated with multiple > tasks(threads) and the task mempolicy is at thread granularity. > > Is this situation reasonable? And if not, how could we fix it? Yes. This sounds like an issue in theory and it's hard to be resolved if possible. Please take a look at get_user_pages_remote() usage in exec(). Do you have some practical issue with pin/get_user_pages_remote()? --- Best Regards, Huang, Ying