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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 898B6C433EF for ; Tue, 21 Dec 2021 13:35:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231741AbhLUNfE (ORCPT ); Tue, 21 Dec 2021 08:35:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235298AbhLUNfD (ORCPT ); Tue, 21 Dec 2021 08:35:03 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94011C061574 for ; Tue, 21 Dec 2021 05:35:02 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2BDB4615B1 for ; Tue, 21 Dec 2021 13:35:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87F66C36AE2 for ; Tue, 21 Dec 2021 13:35:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640093701; bh=SB5zGXuVjZ54ZHTK9LNxlJ4nxNjZxgutVLXAW3t8YDU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ODOVmvi4N70mGOeFFl2Dl59RtRolLJc5zrutLUm2Qh5nPFOmt4y79NRpWYUgh7koj uq3ZpyB0OY6Ek4tevb7LAuLR0Riys4uXHXRC/s5XSyP64TjQM3HalIKZyqKvA/zr+z cs+BETc7NvEUc1w8ix83IdHdG6N13+g0Qi/9HOHswpM2IyK5O01XJbpGYjvl664UvF 7eyHsQwFal46jJQ+NWKGznqja8R7XXGLtlBgbvcdAMWE5fhK8rMPippYE7Qq2/vDBI sVrTIzBBUMTU2qkfrnDOlsKP3Ny+u0Kv2J8PoSBXP0XtgNQGa0F83iH9uT1Q9WX654 +2bXF3icNA3Jg== Received: by mail-wr1-f45.google.com with SMTP id e5so26967141wrc.5 for ; Tue, 21 Dec 2021 05:35:01 -0800 (PST) X-Gm-Message-State: AOAM5332XDT5AjqYew7gMH8MVZvV8/kuIyGSmU5o2RfGE3VxUcJ6JdFZ FLIC6KuCBIbMo6CJL8DiFVrX/6XE8eJJz721vO0= X-Google-Smtp-Source: ABdhPJwog6USymuJRT8kUtnzlfiJfh+Z3bpc7ogxmZankrw3B7hNj2HfV+Eg9W89t/4mUtTIOWSjFwhZliC5p4/VYeE= X-Received: by 2002:adf:c450:: with SMTP id a16mr2575034wrg.454.1640093699847; Tue, 21 Dec 2021 05:34:59 -0800 (PST) MIME-Version: 1.0 References: <20211122092816.2865873-1-ardb@kernel.org> <20211122092816.2865873-8-ardb@kernel.org> <0ffc858f-27e7-6789-4be1-c4c5ad61eb9d@samsung.com> In-Reply-To: From: Ard Biesheuvel Date: Tue, 21 Dec 2021 14:34:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks To: Marek Szyprowski Cc: linux-arm-kernel@lists.infradead.org, Russell King , Nicolas Pitre , Arnd Bergmann , Kees Cook , Keith Packard , Linus Walleij , Nick Desaulniers , Tony Lindgren , Krzysztof Kozlowski , Linux Samsung SOC Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org On Tue, 21 Dec 2021 at 12:15, Marek Szyprowski wrote: > > Hi Ard, > > On 21.12.2021 11:44, Ard Biesheuvel wrote: > > On Tue, 21 Dec 2021 at 11:39, Marek Szyprowski wrote: > >> On 22.11.2021 10:28, Ard Biesheuvel wrote: > >>> Wire up the generic support for managing task stack allocations via vmalloc, > >>> and implement the entry code that detects whether we faulted because of a > >>> stack overrun (or future stack overrun caused by pushing the pt_regs array) > >>> > >>> While this adds a fair amount of tricky entry asm code, it should be > >>> noted that it only adds a TST + branch to the svc_entry path. The code > >>> implementing the non-trivial handling of the overflow stack is emitted > >>> out-of-line into the .text section. > >>> > >>> Since on ARM, we rely on do_translation_fault() to keep PMD level page > >>> table entries that cover the vmalloc region up to date, we need to > >>> ensure that we don't hit such a stale PMD entry when accessing the > >>> stack. So we do a dummy read from the new stack while still running from > >>> the old one on the context switch path, and bump the vmalloc_seq counter > >>> when PMD level entries in the vmalloc range are modified, so that the MM > >>> switch fetches the latest version of the entries. > >>> > >>> Note that we need to increase the per-mode stack by 1 word, to gain some > >>> space to stash a GPR until we know it is safe to touch the stack. > >>> However, due to the cacheline alignment of the struct, this does not > >>> actually increase the memory footprint of the struct stack array at all. > >>> > >>> Signed-off-by: Ard Biesheuvel > >>> Tested-by: Keith Packard > >> This patch landed recently in linux-next 20211220 as commit a1c510d0adc6 > >> ("ARM: implement support for vmap'ed stacks"). Sadly it breaks > >> suspend/resume operation on all ARM 32bit Exynos SoCs. Probably the > >> suspend/resume related code must be updated somehow (it partially works > >> on physical addresses and disabled MMU), but I didn't analyze it yet. If > >> you have any hints, let me know. > >> > > Are there any such systems in KernelCI? We caught a suspend/resume > > related issue in development, which is why the hunk below was added. > > > I think that some Exynos-based Odroids (U3 and XU3) were some time ago > available in KernelCI, but I don't know if they are still there. > > > > In general, any virt-to-phys translation involving and address on the > > stack will become problematic. > > > > Could you please confirm whether the issue persists with the patch > > applied but with CONFIG_VMAP_STACK turned off? Just so we know we are > > looking in the right place? > > > I've just checked. After disabling CONFIG_VMAP_STACK suspend/resume > works fine both on commit a1c510d0adc6 and linux-next 20211220. > Thanks. Any other context you can provide beyond 'does not work' ? 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5EFE4C433EF for ; Tue, 21 Dec 2021 13:36:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gTxU5dXCh1a06db+6X2J6+55AFhVirwtdfwesjSstWk=; b=yoFJHq7RcVWMuW haQKRyUM5u5cddd9ZSRQtzuYKD8GI2tztDMw+gjSRPaTbriqA5nDpNotSoxmokDjow+cm94SmOxIJ hg12o11pXkgsikyDzZobLYLrMpWAlKNVMr5Ua6NrPJxA1lnHHMGIwN1rEtHFsrEz8I4hj4nW8nMHA drUIDgTNvBTuwNjjbD0swYXwcAH9z6SoLOraqHNhM1ZRnapsB1zy9PKEOkyL/Ow8d3aiCL6HNkukt SRKzyh/1+LMpHQcgUgKo9pieUtQXrow4aY8RaOEMi+NhrNxKXmD0cyjdYiAtIg31c9bOvGnDlZdqp QVyiuLddI2fyuXxcsdsQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mzfIK-006z4x-EV; Tue, 21 Dec 2021 13:35:08 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mzfIG-006z3n-FT for linux-arm-kernel@lists.infradead.org; Tue, 21 Dec 2021 13:35:05 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C003E615A6 for ; Tue, 21 Dec 2021 13:35:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7003C36AF1 for ; Tue, 21 Dec 2021 13:35:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640093701; bh=SB5zGXuVjZ54ZHTK9LNxlJ4nxNjZxgutVLXAW3t8YDU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ODOVmvi4N70mGOeFFl2Dl59RtRolLJc5zrutLUm2Qh5nPFOmt4y79NRpWYUgh7koj uq3ZpyB0OY6Ek4tevb7LAuLR0Riys4uXHXRC/s5XSyP64TjQM3HalIKZyqKvA/zr+z cs+BETc7NvEUc1w8ix83IdHdG6N13+g0Qi/9HOHswpM2IyK5O01XJbpGYjvl664UvF 7eyHsQwFal46jJQ+NWKGznqja8R7XXGLtlBgbvcdAMWE5fhK8rMPippYE7Qq2/vDBI sVrTIzBBUMTU2qkfrnDOlsKP3Ny+u0Kv2J8PoSBXP0XtgNQGa0F83iH9uT1Q9WX654 +2bXF3icNA3Jg== Received: by mail-wr1-f47.google.com with SMTP id q16so26990773wrg.7 for ; Tue, 21 Dec 2021 05:35:01 -0800 (PST) X-Gm-Message-State: AOAM531bnqHGtBAs7cF85cPUsZRW9LVoWhZN6Q8QukQTo4NZhHH61HUY neBcjAwkJ10IrOXbKuPcCIb514i0Suj4jFqN5Ug= X-Google-Smtp-Source: ABdhPJwog6USymuJRT8kUtnzlfiJfh+Z3bpc7ogxmZankrw3B7hNj2HfV+Eg9W89t/4mUtTIOWSjFwhZliC5p4/VYeE= X-Received: by 2002:adf:c450:: with SMTP id a16mr2575034wrg.454.1640093699847; Tue, 21 Dec 2021 05:34:59 -0800 (PST) MIME-Version: 1.0 References: <20211122092816.2865873-1-ardb@kernel.org> <20211122092816.2865873-8-ardb@kernel.org> <0ffc858f-27e7-6789-4be1-c4c5ad61eb9d@samsung.com> In-Reply-To: From: Ard Biesheuvel Date: Tue, 21 Dec 2021 14:34:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks To: Marek Szyprowski Cc: linux-arm-kernel@lists.infradead.org, Russell King , Nicolas Pitre , Arnd Bergmann , Kees Cook , Keith Packard , Linus Walleij , Nick Desaulniers , Tony Lindgren , Krzysztof Kozlowski , Linux Samsung SOC X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211221_053504_623628_61768DAE X-CRM114-Status: GOOD ( 36.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 21 Dec 2021 at 12:15, Marek Szyprowski wrote: > > Hi Ard, > > On 21.12.2021 11:44, Ard Biesheuvel wrote: > > On Tue, 21 Dec 2021 at 11:39, Marek Szyprowski wrote: > >> On 22.11.2021 10:28, Ard Biesheuvel wrote: > >>> Wire up the generic support for managing task stack allocations via vmalloc, > >>> and implement the entry code that detects whether we faulted because of a > >>> stack overrun (or future stack overrun caused by pushing the pt_regs array) > >>> > >>> While this adds a fair amount of tricky entry asm code, it should be > >>> noted that it only adds a TST + branch to the svc_entry path. The code > >>> implementing the non-trivial handling of the overflow stack is emitted > >>> out-of-line into the .text section. > >>> > >>> Since on ARM, we rely on do_translation_fault() to keep PMD level page > >>> table entries that cover the vmalloc region up to date, we need to > >>> ensure that we don't hit such a stale PMD entry when accessing the > >>> stack. So we do a dummy read from the new stack while still running from > >>> the old one on the context switch path, and bump the vmalloc_seq counter > >>> when PMD level entries in the vmalloc range are modified, so that the MM > >>> switch fetches the latest version of the entries. > >>> > >>> Note that we need to increase the per-mode stack by 1 word, to gain some > >>> space to stash a GPR until we know it is safe to touch the stack. > >>> However, due to the cacheline alignment of the struct, this does not > >>> actually increase the memory footprint of the struct stack array at all. > >>> > >>> Signed-off-by: Ard Biesheuvel > >>> Tested-by: Keith Packard > >> This patch landed recently in linux-next 20211220 as commit a1c510d0adc6 > >> ("ARM: implement support for vmap'ed stacks"). Sadly it breaks > >> suspend/resume operation on all ARM 32bit Exynos SoCs. Probably the > >> suspend/resume related code must be updated somehow (it partially works > >> on physical addresses and disabled MMU), but I didn't analyze it yet. If > >> you have any hints, let me know. > >> > > Are there any such systems in KernelCI? We caught a suspend/resume > > related issue in development, which is why the hunk below was added. > > > I think that some Exynos-based Odroids (U3 and XU3) were some time ago > available in KernelCI, but I don't know if they are still there. > > > > In general, any virt-to-phys translation involving and address on the > > stack will become problematic. > > > > Could you please confirm whether the issue persists with the patch > > applied but with CONFIG_VMAP_STACK turned off? Just so we know we are > > looking in the right place? > > > I've just checked. After disabling CONFIG_VMAP_STACK suspend/resume > works fine both on commit a1c510d0adc6 and linux-next 20211220. > Thanks. Any other context you can provide beyond 'does not work' ? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel