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 774FEC47258 for ; Mon, 15 Jan 2024 08:50:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECB5A6B007E; Mon, 15 Jan 2024 03:50:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7B616B0080; Mon, 15 Jan 2024 03:50:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D69666B0081; Mon, 15 Jan 2024 03:50:27 -0500 (EST) 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 C9A6E6B007E for ; Mon, 15 Jan 2024 03:50:27 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9BF6D804C5 for ; Mon, 15 Jan 2024 08:50:27 +0000 (UTC) X-FDA: 81680924094.12.2545A71 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf07.hostedemail.com (Postfix) with ESMTP id DFA9540007 for ; Mon, 15 Jan 2024 08:50:24 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705308625; 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; bh=wkXrJ1CaW4770VpGOe9ODLDLJ8I32P9Aq95VCH7HeDI=; b=h47hD4ZqKL4NryeocvtWVZlA23p6Zkgm5AcgmmaQK6L5erzqfwcO59WrB7Mu7AxhY4/GZn Ba/ZG+xTyGBVwUggJRK4n9KPYNc6bpcsecahqsBbyu1jd3E6QGKnzPpCHooHONdSMWKxIA nYd6xb5oPKPD1R0tqy1mwxXymmWaC3s= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705308625; a=rsa-sha256; cv=none; b=ug/pNCgmFLSI3BG2YEyDV6FUlDUXrrya/e8gJj8LSlc2Ij649bz7iLXTEUC2975LyfKzeh rieYWTG4b4rwo1P+2DQTinhk5EMbeqtZ+BZI9PKm6W3+ImuzLvBDKI0RbY23ZiGOSbOYKy Vmm1XdKxCD9arP6ziYT3sgRfsl9vc3s= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 36B472F4; Mon, 15 Jan 2024 00:51:10 -0800 (PST) Received: from [10.57.76.47] (unknown [10.57.76.47]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B77D3F6C4; Mon, 15 Jan 2024 00:50:20 -0800 (PST) Message-ID: <1188e67e-5c04-4bb5-b242-78d92c3fc85c@arm.com> Date: Mon, 15 Jan 2024 08:50:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap() Content-Language: en-GB To: Jiri Olsa , David Hildenbrand Cc: Andrew Morton , Matthew Wilcox , Yin Fengwei , Yu Zhao , Catalin Marinas , Anshuman Khandual , Yang Shi , "Huang, Ying" , Zi Yan , Luis Chamberlain , Itaru Kitayama , "Kirill A. Shutemov" , John Hubbard , David Rientjes , Vlastimil Babka , Hugh Dickins , Kefeng Wang , Barry Song <21cnbao@gmail.com>, Alistair Popple , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Barry Song References: <20231207161211.2374093-1-ryan.roberts@arm.com> <20231207161211.2374093-3-ryan.roberts@arm.com> <41dc7dff-1ea8-4894-a487-88d46ec2b2d8@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: DFA9540007 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: b3rrqofcynghm6ibej7ama1ya9u48i54 X-HE-Tag: 1705308624-734093 X-HE-Meta: U2FsdGVkX19MZFZ1pndXNEv5MWVX+wTPypAU4agSS/FRA/1UivqiQSHy/ouxPNEAyYdOkMxAn6/abwyNgvJBVCLfF/1TTT1AZw+quMTvCRxJqZ6Kty+3GqFuSpYzMpc8V2brF8JLvB/L7Lw48KwgqEHoFUj/chJMpgSKTlt5HkgjoXOgI+mGs2h46a4jEl00aZWVstfTTZ9lcOq2+1w/ooP4srzbNWkqY+PsgNtlNdvTRLfH+joPtLzCmdgFIwf9O1517cn9FBlwJyewwf+HRMf8fpXVT0hqD7o16SOXFZn0/QM+lRkxxL7OZ4RLfQWvQfplayvbWu7/lFo9SxXIzJvQpj/gBh38fb10vYit9+gJJvtQnaIaRiVBzX61cABdQFpOnoHd9k99TjibbcbG3Oa4P18FGv1jeJEldfkhTVlrbyKcofT8jkFvdiy4AEdfG1hV07y6dWQPsR96zxy7iB3q+zN6zn5s68zVkYHfVkP6Ok7PbGV9jf+rvcd7EfoQ92XRhCKNF9UGXUR6Ms+N1qG4nz00Yl2Ed6leoKd0r7JH6w9UIY6gUjKvIbdgEtOO8NN97p7+sRG8Mvfyb4htqoYBRTUZIr7iKBCkr8CGdt+edA9DUaG/ebQDt/2bambw4Elkb9CGk2NDvK+Hcbt38sDDVQvR+fNx52rZL7J6rMJCBnCKXjwn588GRnP8bHi0sNVzq9684v4T/c6iq2NlCMjTf+pXJHLSVU8CA5T8wIaF+jbv7dp2hNneClh2QlFHzrYQ8NzwpS+A1g5OAsglGw3V0T2A7CRV/7uQSptw4sCfWzHS894VCLFtaX9TVoxjniSd/M+1zD8PzJTQ8w2ePdb9C5zNR+WBxwLy2F4my9uHaT7cCK6sdfI+Mo2R4jvVLpsWRIWWq2wnK34A6HiGTUH84g74DWV1ip12tMxGgI5lY43s0zaCuqnIu0p7/LW7RckeViAk5P6xFzQ9wEr oVrQ0/y5 vimwee5NDIaXigmCL+j5FG2m7fmICm5V7f1gm122OpuZBfiyEUHaQEk+ouivjTzWy7bccTj8LbtYvS0KikvQR3d7LyTIkCtmDlbXE7FvnX+GX3gp5OR2faDX/4xzno9sfVTixzKnh45y1jKck+iyIngRbmObGbmdDYTGuTMVdtV4+qRrpC3d7nxtcSpOazA2KescyA12tQ+zgEq7uu1JCSzWLlJ0ZkkpQhfxro4gsWSGxoMhTExO4FKXCaKPcuYCnbB6ztMD2QCSCF1ZwYKVNdFi1yaQecIUI84ICzgjmV7FufnBrc4DZ9vY2NfV+TfXvkJdXs9X9J5JngYJBzabw9O8jiU2NfwopiYgD5nZWui7/5IGIgT1DnSC5yVsnOC5mWuZQOEx+1aExCryxokEWWGH2QO8AJxdJJBwAezE+cIeoRjwvX1xyfFUcy4Jm6tGG/Zml+2AXpEpyAuwVCTOKgYaNH+OO2Nh5HXAhfv2E42CyRXCGzuGnvajn1QHJ3cQivAy5gC+yl8XFEJpzB6t2s+/O5orZoBYqo4IflhHuSuXVsZC6UeYlKG4i/A== 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: On 14/01/2024 20:55, Jiri Olsa wrote: > On Sun, Jan 14, 2024 at 06:33:56PM +0100, David Hildenbrand wrote: >> On 13.01.24 23:42, Jiri Olsa wrote: >>> On Thu, Dec 07, 2023 at 04:12:03PM +0000, Ryan Roberts wrote: >>>> In preparation for supporting anonymous multi-size THP, improve >>>> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be >>>> passed to it. In this case, all contained pages are accounted using the >>>> order-0 folio (or base page) scheme. >>>> >>>> Reviewed-by: Yu Zhao >>>> Reviewed-by: Yin Fengwei >>>> Reviewed-by: David Hildenbrand >>>> Reviewed-by: Barry Song >>>> Tested-by: Kefeng Wang >>>> Tested-by: John Hubbard >>>> Signed-off-by: Ryan Roberts >>>> --- >>>> mm/rmap.c | 28 ++++++++++++++++++++-------- >>>> 1 file changed, 20 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/mm/rmap.c b/mm/rmap.c >>>> index 2a1e45e6419f..846fc79f3ca9 100644 >>>> --- a/mm/rmap.c >>>> +++ b/mm/rmap.c >>>> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma, >>>> * This means the inc-and-test can be bypassed. >>>> * The folio does not have to be locked. >>>> * >>>> - * If the folio is large, it is accounted as a THP. As the folio >>>> + * If the folio is pmd-mappable, it is accounted as a THP. As the folio >>>> * is new, it's assumed to be mapped exclusively by a single process. >>>> */ >>>> void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, >>>> unsigned long address) >>>> { >>>> - int nr; >>>> + int nr = folio_nr_pages(folio); >>>> - VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma); >>>> + VM_BUG_ON_VMA(address < vma->vm_start || >>>> + address + (nr << PAGE_SHIFT) > vma->vm_end, vma); >>> >>> hi, >>> I'm hitting this bug (console output below) with adding uprobe >>> on simple program like: >>> >>> $ cat up.c >>> int main(void) >>> { >>> return 0; >>> } >>> >>> # bpftrace -e 'uprobe:/home/jolsa/up:_start {}' >>> >>> $ ./up >>> >>> it's on top of current linus tree master: >>> 052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat >>> >>> before this patch it seems to work, I can send my .config if needed Thanks for the bug report! >> >> bpf only inserts a small folio, so no magic there. >> >> It was: >> VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma); >> And now it is >> VM_BUG_ON_VMA(address < vma->vm_start || address + (nr << PAGE_SHIFT) > vma->vm_end, vma); >> >> I think this change is sane. As long as the address is aligned to full pages >> (which it better should be) >> >> Staring at uprobe_write_opcode, likely vaddr isn't aligned ... >> >> Likely (hopefully) that is not an issue for __folio_set_anon(), because linear_page_index() >> will mask these bits off. >> >> >> Would the following change fix it for you? And thanks for fixing my mess so quickly, David. FWIW, I agree with your diagnosis. One small suggestion below. > > great, that fixes it for me, you can add my > > Tested-by: Jiri Olsa > > thanks, > jirka > >> >> From c640a8363e47bc96965a35115a040b5f876c4320 Mon Sep 17 00:00:00 2001 >> From: David Hildenbrand >> Date: Sun, 14 Jan 2024 18:32:57 +0100 >> Subject: [PATCH] tmp >> >> Signed-off-by: David Hildenbrand >> --- >> kernel/events/uprobes.c | 2 +- >> mm/rmap.c | 1 + >> 2 files changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c >> index 485bb0389b488..929e98c629652 100644 >> --- a/kernel/events/uprobes.c >> +++ b/kernel/events/uprobes.c >> @@ -537,7 +537,7 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm, >> } >> } >> - ret = __replace_page(vma, vaddr, old_page, new_page); >> + ret = __replace_page(vma, vaddr & PAGE_MASK, old_page, new_page); >> if (new_page) >> put_page(new_page); >> put_old: >> diff --git a/mm/rmap.c b/mm/rmap.c >> index f5d43edad529a..a903db4df6b97 100644 >> --- a/mm/rmap.c >> +++ b/mm/rmap.c >> @@ -1408,6 +1408,7 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, >> { >> int nr = folio_nr_pages(folio); >> + VM_WARN_ON_FOLIO(!IS_ALIGNED(address, PAGE_SIZE), folio); nit: Is it worth also adding this to __folio_add_anon_rmap() so that folio_add_anon_rmap_ptes() and folio_add_anon_rmap_pmd() also benefit? Regardless: Reviewed-by: Ryan Roberts >> VM_WARN_ON_FOLIO(folio_test_hugetlb(folio), folio); >> VM_BUG_ON_VMA(address < vma->vm_start || >> address + (nr << PAGE_SHIFT) > vma->vm_end, vma); >> -- >> 2.43.0 >> >> >> >> -- >> Cheers, >> >> David / dhildenb >>