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 A1D52C02180 for ; Thu, 16 Jan 2025 00:22:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC1256B007B; Wed, 15 Jan 2025 19:22:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B46B66B0082; Wed, 15 Jan 2025 19:22:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 998BB280001; Wed, 15 Jan 2025 19:22:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 78B356B007B for ; Wed, 15 Jan 2025 19:22:00 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8B1BF1C6F46 for ; Thu, 16 Jan 2025 00:21:59 +0000 (UTC) X-FDA: 83011412358.09.E51B533 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf02.hostedemail.com (Postfix) with ESMTP id 220A780007 for ; Thu, 16 Jan 2025 00:21:56 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=J4tKA2z9; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf02.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736986917; a=rsa-sha256; cv=none; b=juBQhTT088PVOSD19sLKrRClXmvwq7l4vxNbEeH/1duoA3zzjK8033IGSuxmN4Ycg6YIgh qXSf9GzAy7FGZ4XMeL0FgZTmzpE29iXi+Y2LvzA/o4WkusOwxZ03SAMK7Ml46nf4Vwl4t0 C0XndRLYSW/iRQY8v6dD6lFE16GO7HM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=J4tKA2z9; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf02.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736986917; 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=sf+0ox9qps9OCdNOEgrNakgxyzYQCzMyDXp9Teo1SPg=; b=tmxxgEEujEK9pfXpcizw0+w2luI5p/N4s2zkgJGsYmE033PDtLUqczotiN3uGdO8CXxJPK BzGHAZHxofQkqxPHhJ8lZTTl7hKZ0UDimh8C+iQqT+MEQWLPhsPAEVDcqbx+YwyPyl241w L4Kpj8ocj4HPVLKv4Rhf1K7FgUFId/Q= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 9A84340E0289; Thu, 16 Jan 2025 00:21:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HRzNY0NNFBah; Thu, 16 Jan 2025 00:21:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1736986908; bh=sf+0ox9qps9OCdNOEgrNakgxyzYQCzMyDXp9Teo1SPg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J4tKA2z9c1dX6/H2/3UFIDVILO8xBwPl1TEyUVQC4DlsQu0QI4LpBFQsTv6iHdtZ2 p9YzSu1IhOTiU08BN0L2M0PecKjs22CleittrM2qBO2cPFFy2HJaYp5I0uY6OZRukR zozlAlfCzmYK6zA6a7rnwMrIQ0b9nW+RolLTUFHyU+pjU2cgIrmrHLhc5fWiU93M7s 2LkZr/YbbEmZFQD4jIKQDyVrDvGkXqUQxr/6r6ASqtjZeCHNBw03OzcKbqcsL4Zf7y r1sNh+hwC4E+Sr34rsrK2zYDvzgRcnP4r3tkiHo/VN5TYvqIp98CXQqbLfpwJEbhX6 LaT6JfdqWRw5QyxhDfkiFjx/XLr9NsYyJlC7ZF0t4iyxrgh9cNrQSodGzZq46p9SyW +WsaNZgJgyJuKoQeomDMVOTWzfADMeQN5FYTZwJH0fqluCcbXDu1gyb+MVca8Gq90k llpN+og3N+QW/Z2lzB9EkrkOeRj43toNWqIzt56gvuiATFuUMDYR70QV3oeogpE80D afkT8idhQsUhKtFR8pKG/nJdJsboyyBxDAYqoVUea/m1agSvHxOA/qykF1MomKo6Rn 83v/tkyRaK2qlfWRqxNzTUP0WyMRLSCK9+KBi9ZUGMvUEoc5K77pSKK9g5j/jP4qjT q2Tju1YxL09ppY+Av5Rr7RuI= Received: from zn.tnic (p200300eA971f93c3329C23fFFEA6A903.dip0.t-ipconnect.de [IPv6:2003:ea:971f:93c3:329c:23ff:fea6:a903]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 7299840E0277; Thu, 16 Jan 2025 00:19:07 +0000 (UTC) Date: Thu, 16 Jan 2025 01:18:58 +0100 From: Borislav Petkov To: Brendan Jackman Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Richard Henderson , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Guo Ren , Brian Cain , Huacai Chen , WANG Xuerui , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , Dinh Nguyen , Jonas Bonn , Stefan Kristiansson , Stafford Horne , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Madhavan Srinivasan , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , "David S. Miller" , Andreas Larsson , Richard Weinberger , Anton Ivanov , Johannes Berg , Chris Zankel , Max Filippov , Arnd Bergmann , Andrew Morton , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Uladzislau Rezki , Christoph Hellwig , Masami Hiramatsu , Mathieu Desnoyers , Mike Rapoport , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Dennis Zhou , Tejun Heo , Christoph Lameter , Sean Christopherson , Paolo Bonzini , Ard Biesheuvel , Josh Poimboeuf , Pawan Gupta , x86@kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org Subject: Re: [PATCH RFC v2 01/29] mm: asi: Make some utility functions noinstr compatible Message-ID: <20250116001858.GDZ4hQctZe_PFvJ0AJ@fat_crate.local> References: <20250110-asi-rfc-v2-v2-0-8419288bc805@google.com> <20250110-asi-rfc-v2-v2-1-8419288bc805@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250110-asi-rfc-v2-v2-1-8419288bc805@google.com> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 220A780007 X-Stat-Signature: ez1nzy9zs7qx5ncsoec3u6zut5z8up3h X-HE-Tag: 1736986916-38650 X-HE-Meta: U2FsdGVkX18zh2LEEemxVWPSkYQJ2MKF2ErOfyBHM8ZEgU+gh9k7k7ood3L7gAS852zqcKxtZR3eE1mMRkRSxiVne9CbGlPG41jP5JjnzMPtnT+GGR2o8lzXgTdpp4I9eYUKwMx+/hYejbtNUE26UVguSHRBOCeKQx8Iutmbu9pansk5BOr5Jm5CjOKuR5e8S5kCzbFEQ9ep6NSbJkI2MeFPQ7Pb3fLdrnwau8piRVmFLWaiGeD4fYl0In6alhPOYROabNuUzJMoXsv4bjZVHI6/rFAOnw6g3edjJfHdslAXu5VLZVnU9xBQ+YXqJQJM15DGkkrVDHNoK8eg8iLT5r8hE5wBGgY0MyzEY1QQv1p4jwZQ798R78+b4xZC0da16axRMs8rjFqCBLV5UqUHe5q74XSkT3y7V+rD3swTcX7RUye0VePidAr8478gp4VwChtVYzuOyJWU2+vRefmKMB3mfuJgra8D8r+y+mSYu/3PNcjkJ7/85Lw7ToAOTgBixJssYeOvjh9kcVjgbfCRgOZBpaYPFTGn52cbsc59wqTgsyR61b9MYS52uKmDwDVBFsrEAxdealrSxX29wTGykz16+e9MHL5z16VbhUsySB+KqhOmDpRmaft/qBYJ+djrj46kwLB+sPJtAEdjkD/HCZH9H+9KIv24aSll4XfckS+l+iHOwrMqisayg3lDxTsAGdDdC0oxDqNm6qnlZd5tqaLj2YVy0xH6vcsBUf0zpbCCFj57JoTOFmIrUGJadE3I38m0iuFdYJ705v99nxbtj38V5yNUUmgg98/ky9KHdq4YA5Q6cFtEbDxiRkkQBbRCd9Kg2cyc46xMtIgFC//yja6uzsYnlYVmK8YCTKUDLhEdX0VL5CzmwVkETIxgbW8ETJqwNHXf4hce7zuTLTQfpBBJk1SbEk0U29uJ1vr0XWtoEk4rPLmyfnVN/m+l5ejf1DcAgfCTUFnj7of7K1U YwkWQJFs 74yRuomx9ib1HCuxDfmad2Eyw4L20i8uQ7TFKRMdV8cPGeZ28//XSThSDy3B+3NQXdtyBk4M2mhuZ8f8hTC/Rl54fh7Szu0kOO7mWPXg0q2Vg0BU6nWHTMuFW9RFJwxnyK4sJM7WCuHfKCSFaurw0Y7x4Rto+ikEo5cK3fp4C5tEYw+LX5B+Gn0ZAQef9FNAF+68/2i8llbwtIDY0MAo09w8YGW1q6GsoIw89m7eW2LvDFPS03DTLTLoO/lCq7bHzxRlEe0Soj9gBsWrgoxlU6dQNvo/wyiyzemITtTBhG7SE+fUajQz+cpMn9FS8tYwVyjprkJh0DJZTyTf9yluUrV5suw== 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 Fri, Jan 10, 2025 at 06:40:27PM +0000, Brendan Jackman wrote: > Subject: Re: [PATCH RFC v2 01/29] mm: asi: Make some utility functions noinstr compatible The tip tree preferred format for patch subject prefixes is 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', 'genirq/core:'. Please do not use file names or complete file paths as prefix. 'git log path/to/file' should give you a reasonable hint in most cases. So I guess "x86/asm:" or so. > Some existing utility functions would need to be called from a noinstr > context in the later patches. So mark these as either noinstr or > __always_inline. > > An earlier version of this by Junaid had a macro that was intended to > tell the compiler "either inline this function, or call it in the > noinstr section", which basically boiled down to: > > #define inline_or_noinstr noinline __section(".noinstr.text") > > Unfortunately Thomas pointed out this will prevent the function from > being inlined at call sites in .text. > > So far I haven't been able[1] to find a formulation that lets us : > 1. avoid calls from .noinstr.text -> .text, > 2. while also letting the compiler freely decide what to inline. > > 1 is a functional requirement so here I'm just giving up on 2. Existing > callsites of this code are just forced inline. For the incoming code > that needs to call it from noinstr, they will be out-of-line calls. I'm not sure some of that belongs in the commit message - if you want to have it in the submission, you should put it under the --- line below, right above the diffstat. > [1] https://lore.kernel.org/lkml/CA+i-1C1z35M8wA_4AwMq7--c1OgjNoLGTkn4+Td5gKg7QQAzWw@mail.gmail.com/ > > Checkpatch-args: --ignore=COMMIT_LOG_LONG_LINE Yeah, you can drop those. People should not turn off brain, use checkpatch and point at all the silly errors it spits anyway. > Signed-off-by: Brendan Jackman > --- > arch/x86/include/asm/processor.h | 2 +- > arch/x86/include/asm/special_insns.h | 8 ++++---- > arch/x86/include/asm/tlbflush.h | 3 +++ > arch/x86/mm/tlb.c | 13 +++++++++---- > 4 files changed, 17 insertions(+), 9 deletions(-) So I was just about to look at the below diff but then booting the patch in my guest causes it to stop at: [ 1.110988] sr 2:0:0:0: Attached scsi generic sg1 type 5 [ 1.114210] PM: Image not found (code -22) [ 1.114903] clk: Disabling unused clocks [ 1.119397] EXT4-fs (sda2): mounted filesystem 90868bc4-a017-4fa2-ac81-931ba260346f ro with ordered data mode. Quota mode: disabled. [ 1.121069] VFS: Mounted root (ext4 filesystem) readonly on device 8:2. <--- EOF with the below call stack. Booting it on Linus' master branch is ok but this is tip/master with all that we've accumulated for the next merge window along with other stuff I'm poking at... Long story short, lemme try to poke around tomorrow to try to figure out what actually happens. It could be caused by the part of Rik's patches and this one inlining things. We'll see... native_flush_tlb_one_user (addr=2507219558400) at arch/x86/mm/tlb.c:1177 1177 if (!static_cpu_has(X86_FEATURE_PTI)) (gdb) bt #0 native_flush_tlb_one_user (addr=2507219558400) at arch/x86/mm/tlb.c:1177 #1 0xffffffff8128206e in flush_tlb_one_user (addr=addr@entry=2507219558400) at arch/x86/mm/tlb.c:1196 #2 flush_tlb_one_kernel (addr=addr@entry=2507219558400) at arch/x86/mm/tlb.c:1151 #3 0xffffffff812820b7 in do_kernel_range_flush (info=0xffff88807dc311c0) at arch/x86/mm/tlb.c:1092 #4 0xffffffff8137beb6 in csd_do_func (csd=0x0 , info=0xffff88807dc311c0, func=0xffffffff81282090 ) at kernel/smp.c:134 #5 smp_call_function_many_cond (mask=, func=func@entry=0xffffffff81282090 , info=0xffff88807dc311c0, scf_flags=scf_flags@entry=3, cond_func=cond_func@entry=0x0 ) at kernel/smp.c:876 #6 0xffffffff8137c254 in on_each_cpu_cond_mask (cond_func=cond_func@entry=0x0 , func=func@entry=0xffffffff81282090 , info=, wait=wait@entry=true, mask=) at kernel/smp.c:1052 #7 0xffffffff81282020 in on_each_cpu (wait=1, info=, func=0xffffffff81282090 ) at ./include/linux/smp.h:71 #8 flush_tlb_kernel_range (start=start@entry=18446683600570097664, end=, end@entry=18446683600579907584) at arch/x86/mm/tlb.c:1106 #9 0xffffffff81481c3f in __purge_vmap_area_lazy (start=18446683600570097664, start@entry=18446744073709551615, end=18446683600579907584, end@entry=0, full_pool_decay=full_pool_decay@entry=false) at mm/vmalloc.c:2284 #10 0xffffffff81481fde in _vm_unmap_aliases (start=start@entry=18446744073709551615, end=end@entry=0, flush=, flush@entry=0) at mm/vmalloc.c:2899 #11 0xffffffff81482049 in vm_unmap_aliases () at mm/vmalloc.c:2922 #12 0xffffffff81284d9f in change_page_attr_set_clr (addr=0xffffc9000001fef0, numpages=, mask_set=..., mask_clr=..., force_split=, in_flag=0, pages=0x0 ) at arch/x86/mm/pat/set_memory.c:1881 #13 0xffffffff81285c52 in change_page_attr_set (array=0, mask=..., numpages=511, addr=0xffffc9000001fef0) at arch/x86/mm/pat/set_memory.c:1922 #14 set_memory_nx (addr=, addr@entry=18446744071759204352, numpages=numpages@entry=511) at arch/x86/mm/pat/set_memory.c:2110 #15 0xffffffff8127b729 in free_init_pages (what=what@entry=0xffffffff8226bac0 "unused decrypted", begin=18446744071759204352, end=18446744071761297408) at arch/x86/mm/init.c:929 #16 0xffffffff898f25aa in mem_encrypt_free_decrypted_mem () at arch/x86/mm/mem_encrypt_amd.c:574 #17 0xffffffff81ca06c3 in free_initmem () at arch/x86/mm/init.c:973 #18 0xffffffff81c9fa48 in kernel_init (unused=) at init/main.c:1475 #19 0xffffffff812398a0 in ret_from_fork (prev=, regs=0xffffc9000001ff58, fn=0xffffffff81c9fa10 , fn_arg=0x0 ) at arch/x86/kernel/process.c:148 #20 0xffffffff81206f7a in ret_from_fork_asm () at arch/x86/entry/entry_64.S:244 #21 0x1f0f2e6600000000 in ?? () #22 0x2e66000000000084 in ?? () #23 0x0000000000841f0f in ?? () #24 0x000000841f0f2e66 in ?? () #25 0x00841f0f2e660000 in ?? () #26 0x1f0f2e6600000000 in ?? () #27 0x2e66000000000084 in ?? () #28 0x0000000000841f0f in ?? () #29 0x000000841f0f2e66 in ?? () #30 0x00841f0f2e660000 in ?? () #31 0x0000000000000000 in ?? () (gdb) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette