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 E929CC71130 for ; Tue, 8 Jul 2025 03:05:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 68D9E6B03AC; Mon, 7 Jul 2025 23:05:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6655D6B03AD; Mon, 7 Jul 2025 23:05:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A2236B03AE; Mon, 7 Jul 2025 23:05:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4B79A6B03AC for ; Mon, 7 Jul 2025 23:05:30 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EE52AC046C for ; Tue, 8 Jul 2025 03:05:29 +0000 (UTC) X-FDA: 83639606778.24.C05C568 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by imf07.hostedemail.com (Postfix) with ESMTP id 017D540009 for ; Tue, 8 Jul 2025 03:05:26 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=oT3wy+oh; spf=pass (imf07.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.110 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=1751943928; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J3ynsQAOt/q+jc8kffxwv8krXnzEOOdPtqUFYfHtdHg=; b=UNfa3Mm9EEcmv1vo8+M6tsL9d1TeOsCMZ3S6PHqHbgNeCFwtvr1/BoJ10lZPMKGwV5AViq wy6xMclGoazRzSDLJCromKYXALkE283E95pAUHWz9pJYNg+jrNgRucahe3mDVPblerWhTI W0pBzhwHjccXKghDAPIDsxxrmjQVKAw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=oT3wy+oh; spf=pass (imf07.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=ying.huang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751943928; a=rsa-sha256; cv=none; b=UnhcvWVkRIynpxY+yLArd+gUaQZHKavioe4Jjfp1+J34WmlHSajEK4i0lRNKvAfHP3MR4E srovK3NfilSlHm0L+ij+5YjniAW0/rR7dJdDY4tdsqkt25ESU6ZRN4KEKD0HlEXqtcGihs ZM1N8HxWGDppQFoKG6Cc/fPewFy7ptk= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1751943924; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=J3ynsQAOt/q+jc8kffxwv8krXnzEOOdPtqUFYfHtdHg=; b=oT3wy+ohTezU4HH5aSR+XdWFzwJ+9b4oNGs0J7FhIxEAW4ZwLbLthngwwzfjiaTl/Lui+b6ZTq5WKe4kvacBVhoBR04fetkLMnv1GT4J4Qnfx3IhKy8B1o4ZaxvuCQWNWuPoT11epsgzYUR9aNtPtQEngt7Y5ft8Im8uvM9ySu0= Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0WiJ5i4c_1751943922 cluster:ay36) by smtp.aliyun-inc.com; Tue, 08 Jul 2025 11:05:22 +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: <12881493-93db-56a6-471c-888051fd94fb@huawei.com> (Jinjiang Tu's message of "Tue, 8 Jul 2025 10:51:41 +0800") References: <94a3d35d-0872-5696-0333-7273f4a69979@huawei.com> <87cyabxxau.fsf@DESKTOP-5N7EMDA> <12881493-93db-56a6-471c-888051fd94fb@huawei.com> Date: Tue, 08 Jul 2025 11:05:21 +0800 Message-ID: <875xg3wff2.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: z1a8iuuobhgzeudxirh45tm9x6c73g8u X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 017D540009 X-HE-Tag: 1751943926-921200 X-HE-Meta: U2FsdGVkX18uxFNgVZlptBY4Ga4CycElHO4EjfrBkINnzYOcXxP4MSMQGrGZ8cII3xR3cT5BFY1VICxn9vERX2vvKSR0AIHQLn8k6VXrFyO8y9d6FjyBvkAsB/000NPuCOYSfdjU/bkZUvdgHUGs45FabKVrJt04RsH4CYIvPCp6w7PQdixIRqKOSMmCIht+X++9N17k4G+ZCImoiRnR2SkTIIR/6BrhJxzq2DnfpwLALHWRa/fy1wmFWB6NEkI8fkzmHepBtGApjO75nq+xmqcYxE4TgvFdBR6qWV1UwI44kmym6CGcGClt7y9hgCN7VUborUQLByBoQuC/vi+6RFmkstAp6ybfWRBBNSdKIJLSazp5jModDsFL3UE37t0PC5tzc0OH5iWE0SAQJXdf8pbJ2KemAUBb0EIvvJ/6BEwoglqz4RW3TXp1HrcPRBIuE4HVwbXxg65t5+gfgMoOMkiXxMPgDXXMdxQYNg7EbwQNjOehVojiN5wbnATlrp/t4kOCDua7as65W3Q7fCU3Itp8YWubLnfCp+qV5kmpARH32OGixSy9S8fTS6D/af7NQcSvyq9UPLXpgBEM0GlMNCyJpewbWDNu0mZcU0XU3DbWl02K4Vxdky9QZKi8lFZcOuQfN6KrTuBhjtSLj5UVCQ5rmgnmKGKp8GPi9ZjJWt7M4b2DyGyd7vGzKt3ar8XGH5eiudJ8AVfl/wYqx6tehU8cebH/P9yDMuEay9QEn805HsbBFbCS9U816woRnWi8k1/FUe27Dm4fFEziJRZkMpmMEikZaAXBjP1EkzmnF0Ppa/4bZcK2eWNuiW5LwzD0l58cjXoSMXilJBT361Mqyw6JR8SUNJSyP2pYgz07cXSBnHLi5zvT+/VHZ8FETEcykK4GMgIfyVD8lJ+0L/4K3Tqg+U+sXQ+6GiLDmgCeYukhi6i8E1k7opXAd9t72JLJYdarzPbUsHmpXB1UbT8 KlWuhhxw ZEBavjUZDNVMnemHpyBFfADgptyX/J7lAqDPZPJFTuwrOWKlTIYBEsNQqS7rz1taXMJIoRtYJHkn/r6lHq+455IAePetFMCDNIZ2Uo9Hw1MGHHKudQS56aJHTXwlxOdBWVmyxR8Z9Hh3La+nOcDzHE4/KClEWv/Z1Z/0r2g4t0aR5sUKeqyc8BfsnCXb3VYJ62v1SHwa44d96aiksbpGWlpaZxGAkJaOpZhF/JeSbjq0idrG7LeViV0UDlZWSmyrHwR78rhHx4S6PU94jMIfOx9WFvvuxNEyAY/6mEgimUJdgtaEfsAliXAc0e1sCXB6wUewAfos/8aEd5zZrpWFg3G91I3hRLfZpOaILyR9ILeHjNkJpny29LnZl3/r6gnFiuKyxahmXLYo7GSIF4grN93petOdSQsDtL8EfwMF5oAeoc08= 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: Jinjiang Tu writes: > =E5=9C=A8 2025/7/8 9:53, Huang, Ying =E5=86=99=E9=81=93: >> 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(). > > IIUC, exec() replaces current->mm with new mm, and the task_struct isn't = changed, > thus task mempolicy is same, so it is reasonable to use get_user_pages_re= mote() in exec(). > >> Do you have some practical issue with pin/get_user_pages_remote()? > > Yes, I have a driver to pin_user_pages_remote() for other task. Please give more details of your issue to help us to understand it. For example, why cannot you use pin_user_pages()? --- Best Regards, Huang, Ying