From: Linus Walleij <linus.walleij@linaro.org> To: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de>, cuigaosheng <cuigaosheng1@huawei.com>, Russell King - ARM Linux <linux@armlinux.org.uk>, Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>, Andrew Lunn <andrew@lunn.ch>, Gregory CLEMENT <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, Viresh Kumar <vireshk@kernel.org>, Shiraz Hashim <shiraz.linux.kernel@gmail.com>, SoC Team <soc@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" <linux-samsung-soc@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, gongruiqi1@huawei.com, wangweiyang2@huawei.com Subject: Re: [PATCH -next 0/3] replace open coded VA->PA calculation Date: Fri, 24 Dec 2021 05:05:46 +0100 [thread overview] Message-ID: <CACRpkdafoc_erHyfkby9X1LhkYgkBQsad=qNyXh+Tq_32zr_yg@mail.gmail.com> (raw) In-Reply-To: <CAMj1kXHgptq47g3mSPTKW9KMnqTH4K2Q7riBVwX4iA1V9YWYiA@mail.gmail.com> On Wed, Dec 22, 2021 at 10:30 AM Ard Biesheuvel <ardb@kernel.org> wrote: > On Wed, 22 Dec 2021 at 03:31, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > > I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G > > > memory model, which in turn depends on having the kernel in vmalloc space, as > > > implemented by Linus Walleij in > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1 > > > > Yeah I'm still working on this series. The 4/4 split works pretty well, Actually it's just kernel-in-vmalloc, 4/4 comes after that. > > but it breaks KASan and I was in the process of fixing that when I left > > for parental leave. > > > > The reason it breaks would be related to KASan not expecting > > executable code in the vmalloc area, and since the shadowing > > algorithm is a simple pointer offset, and since we go to lengths > > to chisel shadow memory out of lowmem at a fixed offset from > > TEXT_OFFSET, we have a problem. > > > > Vmap'ed stacks actually has a similar problem, which is why it is > disabled when KAsan is enabled. But this can be fixed by enabling arch > support for KASAN_VMALLOC, and I suspect it may address the vmap'ed > kernel as well. Yep after seeing the other convo on the topic I realized that this is indeed the same as I'm seeing. I can't disable KASAN just because the kernel is in VMALLOC though, so I suppose when I finally get back to this I have to fix KASAN_VMALLOC too if noone beats me to it. (It'd be great if someone could beat me to it...) Yours, Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org> To: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de>, cuigaosheng <cuigaosheng1@huawei.com>, Russell King - ARM Linux <linux@armlinux.org.uk>, Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>, Andrew Lunn <andrew@lunn.ch>, Gregory CLEMENT <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, Viresh Kumar <vireshk@kernel.org>, Shiraz Hashim <shiraz.linux.kernel@gmail.com>, SoC Team <soc@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" <linux-samsung-soc@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, gongruiqi1@huawei.com, wangweiyang2@huawei.com Subject: Re: [PATCH -next 0/3] replace open coded VA->PA calculation Date: Fri, 24 Dec 2021 05:05:46 +0100 [thread overview] Message-ID: <CACRpkdafoc_erHyfkby9X1LhkYgkBQsad=qNyXh+Tq_32zr_yg@mail.gmail.com> (raw) In-Reply-To: <CAMj1kXHgptq47g3mSPTKW9KMnqTH4K2Q7riBVwX4iA1V9YWYiA@mail.gmail.com> On Wed, Dec 22, 2021 at 10:30 AM Ard Biesheuvel <ardb@kernel.org> wrote: > On Wed, 22 Dec 2021 at 03:31, Linus Walleij <linus.walleij@linaro.org> wrote: > > On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > > I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G > > > memory model, which in turn depends on having the kernel in vmalloc space, as > > > implemented by Linus Walleij in > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1 > > > > Yeah I'm still working on this series. The 4/4 split works pretty well, Actually it's just kernel-in-vmalloc, 4/4 comes after that. > > but it breaks KASan and I was in the process of fixing that when I left > > for parental leave. > > > > The reason it breaks would be related to KASan not expecting > > executable code in the vmalloc area, and since the shadowing > > algorithm is a simple pointer offset, and since we go to lengths > > to chisel shadow memory out of lowmem at a fixed offset from > > TEXT_OFFSET, we have a problem. > > > > Vmap'ed stacks actually has a similar problem, which is why it is > disabled when KAsan is enabled. But this can be fixed by enabling arch > support for KASAN_VMALLOC, and I suspect it may address the vmap'ed > kernel as well. Yep after seeing the other convo on the topic I realized that this is indeed the same as I'm seeing. I can't disable KASAN just because the kernel is in VMALLOC though, so I suppose when I finally get back to this I have to fix KASAN_VMALLOC too if noone beats me to it. (It'd be great if someone could beat me to it...) Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-12-24 4:06 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-18 8:58 [PATCH -next 0/3] replace open coded VA->PA calculation Gaosheng Cui 2021-12-18 8:58 ` Gaosheng Cui 2021-12-18 8:58 ` [PATCH -next 1/3] arm-soc: exynos: replace open coded VA->PA conversions Gaosheng Cui 2021-12-18 8:58 ` Gaosheng Cui 2021-12-18 8:58 ` [PATCH -next 2/3] arm-soc: mvebu: replace open coded VA->PA conversion Gaosheng Cui 2021-12-18 8:58 ` Gaosheng Cui 2021-12-18 8:58 ` [PATCH -next 3/3] arm-soc: various: replace open coded VA->PA calculation Gaosheng Cui 2021-12-18 8:58 ` Gaosheng Cui 2021-12-20 15:39 ` [PATCH -next 0/3] " Arnd Bergmann 2021-12-20 15:39 ` Arnd Bergmann 2021-12-20 18:06 ` Andrew Lunn 2021-12-20 18:06 ` Andrew Lunn 2021-12-20 18:16 ` Ard Biesheuvel 2021-12-20 18:16 ` Ard Biesheuvel 2021-12-21 1:41 ` cuigaosheng 2021-12-21 1:41 ` cuigaosheng 2021-12-21 9:15 ` Arnd Bergmann 2021-12-21 9:15 ` Arnd Bergmann 2021-12-22 2:31 ` Linus Walleij 2021-12-22 2:31 ` Linus Walleij 2021-12-22 9:29 ` Ard Biesheuvel 2021-12-22 9:29 ` Ard Biesheuvel 2021-12-24 4:05 ` Linus Walleij [this message] 2021-12-24 4:05 ` Linus Walleij
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CACRpkdafoc_erHyfkby9X1LhkYgkBQsad=qNyXh+Tq_32zr_yg@mail.gmail.com' \ --to=linus.walleij@linaro.org \ --cc=andrew@lunn.ch \ --cc=ardb@kernel.org \ --cc=arnd@arndb.de \ --cc=cuigaosheng1@huawei.com \ --cc=gongruiqi1@huawei.com \ --cc=gregory.clement@bootlin.com \ --cc=krzysztof.kozlowski@canonical.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=sebastian.hesselbarth@gmail.com \ --cc=shiraz.linux.kernel@gmail.com \ --cc=soc@kernel.org \ --cc=vireshk@kernel.org \ --cc=wangweiyang2@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.