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 X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC164C10F0E for ; Fri, 12 Apr 2019 17:06:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 75AD6218AF for ; Fri, 12 Apr 2019 17:06:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=vmware.com header.i=@vmware.com header.b="FPND4+jR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726925AbfDLRGE (ORCPT ); Fri, 12 Apr 2019 13:06:04 -0400 Received: from mail-eopbgr790070.outbound.protection.outlook.com ([40.107.79.70]:27660 "EHLO NAM03-CO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726777AbfDLRGD (ORCPT ); Fri, 12 Apr 2019 13:06:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tri8CThGeI0Fog54JNhqIGeKjLdF19xBZHs5GfnqGqY=; b=FPND4+jRC0vauLwqeGFTEBG6O8NeBQmmIn9DcLZlz0nel+3bTTdewhdJjkfWHl9EcN3Bx18BM9vTJH8kt+v/SOJijnbiJ1fY+vebYIndkDVQQFVREI6yCUbe2enfiolf7MhrkXYuFcXblKnq3VvQylqB9xwtftM5720stTwRxTk= Received: from BYAPR05MB4776.namprd05.prod.outlook.com (52.135.233.146) by BYAPR05MB5974.namprd05.prod.outlook.com (20.178.53.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.10; Fri, 12 Apr 2019 17:05:53 +0000 Received: from BYAPR05MB4776.namprd05.prod.outlook.com ([fe80::4140:b8f2:8e3:f5fd]) by BYAPR05MB4776.namprd05.prod.outlook.com ([fe80::4140:b8f2:8e3:f5fd%4]) with mapi id 15.20.1792.009; Fri, 12 Apr 2019 17:05:53 +0000 From: Nadav Amit To: Peter Zijlstra CC: kernel test robot , LKP , Linux List Kernel Mailing , Linux-MM , linux-arch , Ingo Molnar , Thomas Gleixner , Will Deacon , Andy Lutomirski , Linus Torvalds , Dave Hansen Subject: Re: 1808d65b55 ("asm-generic/tlb: Remove arch_tlb*_mmu()"): BUG: KASAN: stack-out-of-bounds in __change_page_attr_set_clr Thread-Topic: 1808d65b55 ("asm-generic/tlb: Remove arch_tlb*_mmu()"): BUG: KASAN: stack-out-of-bounds in __change_page_attr_set_clr Thread-Index: AQHU8R5sUhi0mJ9uO0aA/EiVew3tvaY4YIQAgABBN4CAAB//AA== Date: Fri, 12 Apr 2019 17:05:53 +0000 Message-ID: References: <5cae03c4.iIPk2cWlfmzP0Zgy%lkp@intel.com> <20190411193906.GA12232@hirez.programming.kicks-ass.net> <20190411195424.GL14281@hirez.programming.kicks-ass.net> <20190411211348.GA8451@worktop.programming.kicks-ass.net> <20190412105633.GM14281@hirez.programming.kicks-ass.net> <20190412111756.GO14281@hirez.programming.kicks-ass.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=namit@vmware.com; x-originating-ip: [66.170.99.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ac12229-7c4a-4300-23ab-08d6bf691f48 x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020);SRVR:BYAPR05MB5974; x-ms-traffictypediagnostic: BYAPR05MB5974: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(39860400002)(396003)(366004)(376002)(136003)(346002)(189003)(199004)(45080400002)(81156014)(97736004)(4001150100001)(53936002)(82746002)(68736007)(6246003)(966005)(6436002)(478600001)(6486002)(36756003)(316002)(2906002)(54906003)(6116002)(71190400001)(83716004)(256004)(86362001)(229853002)(99286004)(26005)(105586002)(6512007)(486006)(25786009)(561944003)(33656002)(8936002)(6306002)(81166006)(71200400001)(3846002)(14444005)(5660300002)(11346002)(2616005)(446003)(476003)(106356001)(76176011)(93886005)(7736002)(4326008)(14454004)(305945005)(6506007)(102836004)(186003)(6916009)(53546011)(8676002)(7416002)(66066001)(41533002);DIR:OUT;SFP:1101;SCL:1;SRVR:BYAPR05MB5974;H:BYAPR05MB4776.namprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FAN6SMk7t7LidEc6KPpNJbyS7CdSLeJ8OVx0DFEGJV3NDug5iCAKY9gdV83n4AbHAyWIq+OKpAyOYRGHe/hmjek4c+joy008kNEaH4O2xr/iOkuAtB8UGGVLClKaauIIMCbpIkls6hdoG3ZrlaIIR7lDakGSCByzLpiapPDA5iF1/xdwE0HMplRGO3hWQxkEznlGMXPwbFBnclKfT1EjEq8MJjPI9027hQdRJH+rg8/EqZuUjjzt9LZ74oJfHScjm7jqVqlRQTO89ES/vGlKiU1ZHejWO3BpGJz5nFyQeUkhbvfc35OIVOJ5aUJMwTMZO30cRuR12GwSpTry/rZHvYE0fSSogBslG17zGJ99NZ5PyCkTKwBbAXe7PFHQB697bFDBE4Ij9sLBJgrMDINidW0gKtgpA7r7hGDHnnsczdA= Content-Type: text/plain; charset="us-ascii" Content-ID: <77F1797517EF464CA320EE9FAAD0EAB3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ac12229-7c4a-4300-23ab-08d6bf691f48 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 17:05:53.4174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5974 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Apr 12, 2019, at 8:11 AM, Nadav Amit wrote: >=20 >> On Apr 12, 2019, at 4:17 AM, Peter Zijlstra wrote= : >>=20 >> On Fri, Apr 12, 2019 at 12:56:33PM +0200, Peter Zijlstra wrote: >>> On Thu, Apr 11, 2019 at 11:13:48PM +0200, Peter Zijlstra wrote: >>>> On Thu, Apr 11, 2019 at 09:54:24PM +0200, Peter Zijlstra wrote: >>>>> On Thu, Apr 11, 2019 at 09:39:06PM +0200, Peter Zijlstra wrote: >>>>>> I think this bisect is bad. If you look at your own logs this patch >>>>>> merely changes the failure, but doesn't make it go away. >>>>>>=20 >>>>>> Before this patch (in fact, before tip/core/mm entirely) the errror >>>>>> reads like the below, which suggests there is memory corruption >>>>>> somewhere, and the fingered patch just makes it trigger differently. >>>>>>=20 >>>>>> It would be very good to find the source of this corruption, but I'm >>>>>> fairly certain it is not here. >>>>>=20 >>>>> I went back to v4.20 to try and find a time when the below error did = not >>>>> occur, but even that reliably triggers the warning. >>>>=20 >>>> So I also tested v4.19 and found that that was good, which made me >>>> bisect v4.19..v4.20 >>>>=20 >>>> # bad: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20 >>>> # good: [84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d] Linux 4.19 >>>> git bisect start 'v4.20' 'v4.19' >>>> # bad: [ec9c166434595382be3babf266febf876327774d] Merge tag 'mips_fixe= s_4.20_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux >>>> git bisect bad ec9c166434595382be3babf266febf876327774d >>>> # bad: [50b825d7e87f4cff7070df6eb26390152bb29537] Merge git://git.kern= el.org/pub/scm/linux/kernel/git/davem/net-next >>>> git bisect bad 50b825d7e87f4cff7070df6eb26390152bb29537 >>>> # good: [99e9acd85ccbdc8f5785f9e961d4956e96bd6aa5] Merge tag 'mlx5-upd= ates-2018-10-17' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/lin= ux >>>> git bisect good 99e9acd85ccbdc8f5785f9e961d4956e96bd6aa5 >>>> # good: [c403993a41d50db1e7d9bc2d43c3c8498162312f] Merge tag 'for-linu= s-4.20' of https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Fgithub.com%2Fcminyard%2Flinux-ipmi&data=3D02%7C01%7Cnamit%40vmware.= com%7Ca1c3ea5d4bc34cfc785508d6bf388ff3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7= C0%7C0%7C636906647013777573&sdata=3D3VSR3VdE5rxOitAdkqFNPpAnAtLgDmYLzJt= oUrs5v9Y%3D&reserved=3D0 >>>> git bisect good c403993a41d50db1e7d9bc2d43c3c8498162312f >>>> # good: [c05f3642f4304dd081876e77a68555b6aba4483f] Merge branch 'perf-= core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>>> git bisect good c05f3642f4304dd081876e77a68555b6aba4483f >>>> # bad: [44786880df196a4200c178945c4d41675faf9fb7] Merge branch 'parisc= -4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-lin= ux >>>> git bisect bad 44786880df196a4200c178945c4d41675faf9fb7 >>>> # bad: [99792e0cea1ed733cdc8d0758677981e0cbebfed] Merge branch 'x86-mm= -for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>>> git bisect bad 99792e0cea1ed733cdc8d0758677981e0cbebfed >>>> # good: [fec98069fb72fb656304a3e52265e0c2fc9adf87] Merge branch 'x86-c= pu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>>> git bisect good fec98069fb72fb656304a3e52265e0c2fc9adf87 >>>> # bad: [a31acd3ee8f7dbc0370bdf4a4bfef7a8c13c7542] x86/mm: Page size aw= are flush_tlb_mm_range() >>>> git bisect bad a31acd3ee8f7dbc0370bdf4a4bfef7a8c13c7542 >>>> # good: [a7295fd53c39ce781a9792c9dd2c8747bf274160] x86/mm/cpa: Use flu= sh_tlb_kernel_range() >>>> git bisect good a7295fd53c39ce781a9792c9dd2c8747bf274160 >>>> # good: [9cf38d5559e813cccdba8b44c82cc46ba48d0896] kexec: Allocate dec= rypted control pages for kdump if SME is enabled >>>> git bisect good 9cf38d5559e813cccdba8b44c82cc46ba48d0896 >>>> # good: [5b12904065798fee8b153a506ac7b72d5ebbe26c] x86/mm/doc: Clean u= p the x86-64 virtual memory layout descriptions >>>> git bisect good 5b12904065798fee8b153a506ac7b72d5ebbe26c >>>> # good: [cf089611f4c446285046fcd426d90c18f37d2905] proc/vmcore: Fix i3= 86 build error of missing copy_oldmem_page_encrypted() >>>> git bisect good cf089611f4c446285046fcd426d90c18f37d2905 >>>> # good: [a5b966ae42a70b194b03eaa5eaea70d8b3790c40] Merge branch 'tlb/a= sm-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux in= to x86/mm >>>> git bisect good a5b966ae42a70b194b03eaa5eaea70d8b3790c40 >>>> # first bad commit: [a31acd3ee8f7dbc0370bdf4a4bfef7a8c13c7542] x86/mm:= Page size aware flush_tlb_mm_range() >>>>=20 >>>> And 'funnily' the bad patch is one of mine too :/ >>>>=20 >>>> I'll go have a look at that tomorrow, because currrently I'm way past >>>> tired. >>>=20 >>> OK, so the below patchlet makes it all good. It turns out that the >>> provided config has: >>>=20 >>> CONFIG_X86_L1_CACHE_SHIFT=3D7 >>>=20 >>> which then, for some obscure raisin, results in flush_tlb_mm_range() >>> compiling to use 320 bytes of stack: >>>=20 >>> sub $0x140,%rsp >>>=20 >>> Where a 'defconfig' build results in: >>>=20 >>> sub $0x58,%rsp >>>=20 >>> The thing that pushes it over the edge in the above fingered patch is >>> the addition of a field to struct flush_tlb_info, which grows if from 3= 2 >>> to 36 bytes. >>>=20 >>> So my proposal is to basically revert that, unless we can come up with >>> something that GCC can't screw up. >>=20 >> To clarify, 'that' is Nadav's patch: >>=20 >> 515ab7c41306 ("x86/mm: Align TLB invalidation info") >>=20 >> which turns out to be the real problem. >=20 > Sorry for that. I still think it should be aligned, especially with all t= he > effort the Intel puts around to avoid bus-locking on unaligned atomic > operations. >=20 > So the right solution seems to me as putting this data structure off stac= k. > It would prevent flush_tlb_mm_range() from being reentrant, so we can kee= p a > few entries for this matter and atomically increase the entry number ever= y > time we enter flush_tlb_mm_range(). >=20 > But my question is - should flush_tlb_mm_range() be reentrant, or can we > assume no TLB shootdowns are initiated in interrupt handlers and #MC > handlers? Peter, what do you say about this one? I assume there are no nested TLB flushes, but the code can easily be adapted (assuming there is a limit on the nesting level). -- >8 -- Subject: [PATCH] x86: Move flush_tlb_info off the stack --- arch/x86/mm/tlb.c | 49 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 35 insertions(+), 14 deletions(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index bc4bc7b2f075..15fe90d4e3e1 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -14,6 +14,7 @@ #include #include #include +#include =20 #include "mm_internal.h" =20 @@ -722,43 +723,63 @@ void native_flush_tlb_others(const struct cpumask *cp= umask, */ unsigned long tlb_single_page_flush_ceiling __read_mostly =3D 33; =20 +static DEFINE_PER_CPU_SHARED_ALIGNED(struct flush_tlb_info, flush_tlb_info= ); +#ifdef CONFIG_DEBUG_VM +static DEFINE_PER_CPU(local_t, flush_tlb_info_idx); +#endif + void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start, unsigned long end, unsigned int stride_shift, bool freed_tables) { + struct flush_tlb_info *info; int cpu; =20 - struct flush_tlb_info info __aligned(SMP_CACHE_BYTES) =3D { - .mm =3D mm, - .stride_shift =3D stride_shift, - .freed_tables =3D freed_tables, - }; - cpu =3D get_cpu(); =20 + info =3D this_cpu_ptr(&flush_tlb_info); + +#ifdef CONFIG_DEBUG_VM + /* + * Ensure that the following code is non-reentrant and flush_tlb_info + * is not overwritten. This means no TLB flushing is initiated by + * interrupt handlers and machine-check exception handlers. If needed, + * we can add additional flush_tlb_info entries. + */ + BUG_ON(local_inc_return(this_cpu_ptr(&flush_tlb_info_idx)) !=3D 1); +#endif + + info->mm =3D mm; + info->stride_shift =3D stride_shift; + info->freed_tables =3D freed_tables; + /* This is also a barrier that synchronizes with switch_mm(). */ - info.new_tlb_gen =3D inc_mm_tlb_gen(mm); + info->new_tlb_gen =3D inc_mm_tlb_gen(mm); =20 /* Should we flush just the requested range? */ if ((end !=3D TLB_FLUSH_ALL) && ((end - start) >> stride_shift) <=3D tlb_single_page_flush_ceiling) { - info.start =3D start; - info.end =3D end; + info->start =3D start; + info->end =3D end; } else { - info.start =3D 0UL; - info.end =3D TLB_FLUSH_ALL; + info->start =3D 0UL; + info->end =3D TLB_FLUSH_ALL; } =20 if (mm =3D=3D this_cpu_read(cpu_tlbstate.loaded_mm)) { - VM_WARN_ON(irqs_disabled()); + lockdep_assert_irqs_enabled(); local_irq_disable(); - flush_tlb_func_local(&info, TLB_LOCAL_MM_SHOOTDOWN); + flush_tlb_func_local(info, TLB_LOCAL_MM_SHOOTDOWN); local_irq_enable(); } =20 if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids) - flush_tlb_others(mm_cpumask(mm), &info); + flush_tlb_others(mm_cpumask(mm), info); =20 +#ifdef CONFIG_DEBUG_VM + barrier(); + local_dec(this_cpu_ptr(&flush_tlb_info_idx)); +#endif put_cpu(); } =20 --=20 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5562396353498824600==" MIME-Version: 1.0 From: Nadav Amit To: lkp@lists.01.org Subject: Re: 1808d65b55 ("asm-generic/tlb: Remove arch_tlb*_mmu()"): BUG: KASAN: stack-out-of-bounds in __change_page_attr_set_clr Date: Fri, 12 Apr 2019 17:05:53 +0000 Message-ID: In-Reply-To: List-Id: --===============5562396353498824600== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Apr 12, 2019, at 8:11 AM, Nadav Amit wrote: > = >> On Apr 12, 2019, at 4:17 AM, Peter Zijlstra wro= te: >> = >> On Fri, Apr 12, 2019 at 12:56:33PM +0200, Peter Zijlstra wrote: >>> On Thu, Apr 11, 2019 at 11:13:48PM +0200, Peter Zijlstra wrote: >>>> On Thu, Apr 11, 2019 at 09:54:24PM +0200, Peter Zijlstra wrote: >>>>> On Thu, Apr 11, 2019 at 09:39:06PM +0200, Peter Zijlstra wrote: >>>>>> I think this bisect is bad. If you look at your own logs this patch >>>>>> merely changes the failure, but doesn't make it go away. >>>>>> = >>>>>> Before this patch (in fact, before tip/core/mm entirely) the errror >>>>>> reads like the below, which suggests there is memory corruption >>>>>> somewhere, and the fingered patch just makes it trigger differently. >>>>>> = >>>>>> It would be very good to find the source of this corruption, but I'm >>>>>> fairly certain it is not here. >>>>> = >>>>> I went back to v4.20 to try and find a time when the below error did = not >>>>> occur, but even that reliably triggers the warning. >>>> = >>>> So I also tested v4.19 and found that that was good, which made me >>>> bisect v4.19..v4.20 >>>> = >>>> # bad: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20 >>>> # good: [84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d] Linux 4.19 >>>> git bisect start 'v4.20' 'v4.19' >>>> # bad: [ec9c166434595382be3babf266febf876327774d] Merge tag 'mips_fixe= s_4.20_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux >>>> git bisect bad ec9c166434595382be3babf266febf876327774d >>>> # bad: [50b825d7e87f4cff7070df6eb26390152bb29537] Merge git://git.kern= el.org/pub/scm/linux/kernel/git/davem/net-next >>>> git bisect bad 50b825d7e87f4cff7070df6eb26390152bb29537 >>>> # good: [99e9acd85ccbdc8f5785f9e961d4956e96bd6aa5] Merge tag 'mlx5-upd= ates-2018-10-17' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/lin= ux >>>> git bisect good 99e9acd85ccbdc8f5785f9e961d4956e96bd6aa5 >>>> # good: [c403993a41d50db1e7d9bc2d43c3c8498162312f] Merge tag 'for-linu= s-4.20' of https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Fgithub.com%2Fcminyard%2Flinux-ipmi&data=3D02%7C01%7Cnamit%40vmware.= com%7Ca1c3ea5d4bc34cfc785508d6bf388ff3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7= C0%7C0%7C636906647013777573&sdata=3D3VSR3VdE5rxOitAdkqFNPpAnAtLgDmYLzJt= oUrs5v9Y%3D&reserved=3D0 >>>> git bisect good c403993a41d50db1e7d9bc2d43c3c8498162312f >>>> # good: [c05f3642f4304dd081876e77a68555b6aba4483f] Merge branch 'perf-= core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>>> git bisect good c05f3642f4304dd081876e77a68555b6aba4483f >>>> # bad: [44786880df196a4200c178945c4d41675faf9fb7] Merge branch 'parisc= -4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-lin= ux >>>> git bisect bad 44786880df196a4200c178945c4d41675faf9fb7 >>>> # bad: [99792e0cea1ed733cdc8d0758677981e0cbebfed] Merge branch 'x86-mm= -for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>>> git bisect bad 99792e0cea1ed733cdc8d0758677981e0cbebfed >>>> # good: [fec98069fb72fb656304a3e52265e0c2fc9adf87] Merge branch 'x86-c= pu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip >>>> git bisect good fec98069fb72fb656304a3e52265e0c2fc9adf87 >>>> # bad: [a31acd3ee8f7dbc0370bdf4a4bfef7a8c13c7542] x86/mm: Page size aw= are flush_tlb_mm_range() >>>> git bisect bad a31acd3ee8f7dbc0370bdf4a4bfef7a8c13c7542 >>>> # good: [a7295fd53c39ce781a9792c9dd2c8747bf274160] x86/mm/cpa: Use flu= sh_tlb_kernel_range() >>>> git bisect good a7295fd53c39ce781a9792c9dd2c8747bf274160 >>>> # good: [9cf38d5559e813cccdba8b44c82cc46ba48d0896] kexec: Allocate dec= rypted control pages for kdump if SME is enabled >>>> git bisect good 9cf38d5559e813cccdba8b44c82cc46ba48d0896 >>>> # good: [5b12904065798fee8b153a506ac7b72d5ebbe26c] x86/mm/doc: Clean u= p the x86-64 virtual memory layout descriptions >>>> git bisect good 5b12904065798fee8b153a506ac7b72d5ebbe26c >>>> # good: [cf089611f4c446285046fcd426d90c18f37d2905] proc/vmcore: Fix i3= 86 build error of missing copy_oldmem_page_encrypted() >>>> git bisect good cf089611f4c446285046fcd426d90c18f37d2905 >>>> # good: [a5b966ae42a70b194b03eaa5eaea70d8b3790c40] Merge branch 'tlb/a= sm-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux in= to x86/mm >>>> git bisect good a5b966ae42a70b194b03eaa5eaea70d8b3790c40 >>>> # first bad commit: [a31acd3ee8f7dbc0370bdf4a4bfef7a8c13c7542] x86/mm:= Page size aware flush_tlb_mm_range() >>>> = >>>> And 'funnily' the bad patch is one of mine too :/ >>>> = >>>> I'll go have a look at that tomorrow, because currrently I'm way past >>>> tired. >>> = >>> OK, so the below patchlet makes it all good. It turns out that the >>> provided config has: >>> = >>> CONFIG_X86_L1_CACHE_SHIFT=3D7 >>> = >>> which then, for some obscure raisin, results in flush_tlb_mm_range() >>> compiling to use 320 bytes of stack: >>> = >>> sub $0x140,%rsp >>> = >>> Where a 'defconfig' build results in: >>> = >>> sub $0x58,%rsp >>> = >>> The thing that pushes it over the edge in the above fingered patch is >>> the addition of a field to struct flush_tlb_info, which grows if from 32 >>> to 36 bytes. >>> = >>> So my proposal is to basically revert that, unless we can come up with >>> something that GCC can't screw up. >> = >> To clarify, 'that' is Nadav's patch: >> = >> 515ab7c41306 ("x86/mm: Align TLB invalidation info") >> = >> which turns out to be the real problem. > = > Sorry for that. I still think it should be aligned, especially with all t= he > effort the Intel puts around to avoid bus-locking on unaligned atomic > operations. > = > So the right solution seems to me as putting this data structure off stac= k. > It would prevent flush_tlb_mm_range() from being reentrant, so we can kee= p a > few entries for this matter and atomically increase the entry number every > time we enter flush_tlb_mm_range(). > = > But my question is - should flush_tlb_mm_range() be reentrant, or can we > assume no TLB shootdowns are initiated in interrupt handlers and #MC > handlers? Peter, what do you say about this one? I assume there are no nested TLB flushes, but the code can easily be adapted (assuming there is a limit on the nesting level). -- >8 -- Subject: [PATCH] x86: Move flush_tlb_info off the stack --- arch/x86/mm/tlb.c | 49 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 35 insertions(+), 14 deletions(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index bc4bc7b2f075..15fe90d4e3e1 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -14,6 +14,7 @@ #include #include #include +#include = #include "mm_internal.h" = @@ -722,43 +723,63 @@ void native_flush_tlb_others(const struct cpumask *cp= umask, */ unsigned long tlb_single_page_flush_ceiling __read_mostly =3D 33; = +static DEFINE_PER_CPU_SHARED_ALIGNED(struct flush_tlb_info, flush_tlb_info= ); +#ifdef CONFIG_DEBUG_VM +static DEFINE_PER_CPU(local_t, flush_tlb_info_idx); +#endif + void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start, unsigned long end, unsigned int stride_shift, bool freed_tables) { + struct flush_tlb_info *info; int cpu; = - struct flush_tlb_info info __aligned(SMP_CACHE_BYTES) =3D { - .mm =3D mm, - .stride_shift =3D stride_shift, - .freed_tables =3D freed_tables, - }; - cpu =3D get_cpu(); = + info =3D this_cpu_ptr(&flush_tlb_info); + +#ifdef CONFIG_DEBUG_VM + /* + * Ensure that the following code is non-reentrant and flush_tlb_info + * is not overwritten. This means no TLB flushing is initiated by + * interrupt handlers and machine-check exception handlers. If needed, + * we can add additional flush_tlb_info entries. + */ + BUG_ON(local_inc_return(this_cpu_ptr(&flush_tlb_info_idx)) !=3D 1); +#endif + + info->mm =3D mm; + info->stride_shift =3D stride_shift; + info->freed_tables =3D freed_tables; + /* This is also a barrier that synchronizes with switch_mm(). */ - info.new_tlb_gen =3D inc_mm_tlb_gen(mm); + info->new_tlb_gen =3D inc_mm_tlb_gen(mm); = /* Should we flush just the requested range? */ if ((end !=3D TLB_FLUSH_ALL) && ((end - start) >> stride_shift) <=3D tlb_single_page_flush_ceiling) { - info.start =3D start; - info.end =3D end; + info->start =3D start; + info->end =3D end; } else { - info.start =3D 0UL; - info.end =3D TLB_FLUSH_ALL; + info->start =3D 0UL; + info->end =3D TLB_FLUSH_ALL; } = if (mm =3D=3D this_cpu_read(cpu_tlbstate.loaded_mm)) { - VM_WARN_ON(irqs_disabled()); + lockdep_assert_irqs_enabled(); local_irq_disable(); - flush_tlb_func_local(&info, TLB_LOCAL_MM_SHOOTDOWN); + flush_tlb_func_local(info, TLB_LOCAL_MM_SHOOTDOWN); local_irq_enable(); } = if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids) - flush_tlb_others(mm_cpumask(mm), &info); + flush_tlb_others(mm_cpumask(mm), info); = +#ifdef CONFIG_DEBUG_VM + barrier(); + local_dec(this_cpu_ptr(&flush_tlb_info_idx)); +#endif put_cpu(); } = -- = 2.17.1 --===============5562396353498824600==--