* Re: [PATCH] powerpc: add support for TIF_NOTIFY_SIGNAL
From: Michael Ellerman @ 2020-10-30 0:48 UTC (permalink / raw)
To: Jens Axboe, linuxppc-dev
In-Reply-To: <7adea1eb-d193-9d31-6244-e8cd5b2084b2@kernel.dk>
Jens Axboe <axboe@kernel.dk> writes:
> Wire up TIF_NOTIFY_SIGNAL handling for powerpc.
>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> ---
>
> 5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting
> for details:
>
> https://lore.kernel.org/io-uring/20201026203230.386348-1-axboe@kernel.dk/
>
> As part of that work, I'm adding TIF_NOTIFY_SIGNAL support to all archs,
> as that will enable a set of cleanups once all of them support it. I'm
> happy carrying this patch if need be, or it can be funelled through the
> arch tree. Let me know.
Happy for you to take it along with the rest of the series.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
> diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
> index 46a210b03d2b..53115ae61495 100644
> --- a/arch/powerpc/include/asm/thread_info.h
> +++ b/arch/powerpc/include/asm/thread_info.h
> @@ -90,6 +90,7 @@ void arch_setup_new_exec(void);
> #define TIF_SYSCALL_TRACE 0 /* syscall trace active */
> #define TIF_SIGPENDING 1 /* signal pending */
> #define TIF_NEED_RESCHED 2 /* rescheduling necessary */
> +#define TIF_NOTIFY_SIGNAL 3 /* signal notifications exist */
> #define TIF_SYSCALL_EMU 4 /* syscall emulation active */
> #define TIF_RESTORE_TM 5 /* need to restore TM FP/VEC/VSX */
> #define TIF_PATCH_PENDING 6 /* pending live patching update */
> @@ -115,6 +116,7 @@ void arch_setup_new_exec(void);
> #define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
> #define _TIF_SIGPENDING (1<<TIF_SIGPENDING)
> #define _TIF_NEED_RESCHED (1<<TIF_NEED_RESCHED)
> +#define _TIF_NOTIFY_SIGNAL (1<<TIF_NOTIFY_SIGNAL)
> #define _TIF_POLLING_NRFLAG (1<<TIF_POLLING_NRFLAG)
> #define _TIF_32BIT (1<<TIF_32BIT)
> #define _TIF_RESTORE_TM (1<<TIF_RESTORE_TM)
> @@ -136,7 +138,8 @@ void arch_setup_new_exec(void);
>
> #define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
> _TIF_NOTIFY_RESUME | _TIF_UPROBE | \
> - _TIF_RESTORE_TM | _TIF_PATCH_PENDING)
> + _TIF_RESTORE_TM | _TIF_PATCH_PENDING | \
> + _TIF_NOTIFY_SIGNAL)
> #define _TIF_PERSYSCALL_MASK (_TIF_RESTOREALL|_TIF_NOERROR)
>
> /* Bits in local_flags */
> diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
> index d2c356f37077..a8bb0aca1d02 100644
> --- a/arch/powerpc/kernel/signal.c
> +++ b/arch/powerpc/kernel/signal.c
> @@ -318,7 +318,7 @@ void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)
> if (thread_info_flags & _TIF_PATCH_PENDING)
> klp_update_patch_state(current);
>
> - if (thread_info_flags & _TIF_SIGPENDING) {
> + if (thread_info_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) {
> BUG_ON(regs != current->thread.regs);
> do_signal(current);
> }
> --
> 2.29.0
>
> --
> Jens Axboe
^ permalink raw reply
* Test Results: RE: [V2,03/18] highmem: Provide generic variant of kmap_atomic*
From: snowpatch @ 2020-10-29 23:46 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222650.910901973@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2, 05/18] arc/mm/highmem: Use generic kmap atomic implementation
From: snowpatch @ 2020-10-29 23:44 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.114375025@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2, 07/18] csky/mm/highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:42 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.303553207@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
From: Thomas Gleixner @ 2020-10-29 23:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: Juri Lelli, linux-xtensa, Peter Zijlstra,
Sebastian Andrzej Siewior, linux-mips, Ben Segall, Linux-MM,
Guo Ren, linux-sparc, Vincent Chen, Ingo Molnar, linux-arch,
Vincent Guittot, Herbert Xu, the arch/x86 maintainers,
Russell King, linux-csky, Christoph Hellwig, David Airlie,
Mel Gorman, open list:SYNOPSYS ARC ARCHITECTURE, Ard Biesheuvel,
Paul McKenney, linuxppc-dev, Steven Rostedt, Greentime Hu,
Dietmar Eggemann, Linux ARM, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Nick Hu, Max Filippov, Vineet Gupta, LKML,
Arnd Bergmann, Daniel Vetter, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller
In-Reply-To: <CAHk-=wiFxxGapdOyZHE-7LbFPk+jdfoqdeeJg0zWNQ86WvJGXg@mail.gmail.com>
On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote:
> On Thu, Oct 29, 2020 at 3:32 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> Though I wanted to share the current state of affairs before investigating
>> that further. If there is consensus in going forward with this, I'll have a
>> deeper look into this issue.
>
> Me likee. I think this looks like the right thing to do.
>
> I didn't actually apply the patches, but just from reading them it
> _looks_ to me like you do the migrate_disable() unconditionally, even
> if it's not a highmem page..
>
> That sounds like it might be a good thing for debugging, but not
> necessarily great in general.
>
> Or am I misreading things?
No, you're not misreading it, but doing it conditionally would be a
complete semantical disaster. kmap_atomic*() also disables preemption
and pagefaults unconditionaly. If that wouldn't be the case then every
caller would have to have conditionals like 'if (CONFIG_HIGHMEM)' or
worse 'if (PageHighMem(page)'.
Let's not go there.
Migrate disable is a less horrible plague than preempt and pagefault
disable even if the scheduler people disagree due to the lack of theory
backing that up :)
The charm of the new interface is that users still can rely on per
cpuness independent of being on a highmem plagued system. For non
highmem systems the extra migrate disable/enable is really a minor
nuissance.
Thanks,
tglx
^ permalink raw reply
* Test Results: RE: [V2,06/18] ARM: highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:40 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.209698448@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,08/18] microblaze/mm/highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:38 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.395482379@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2, 09/18] mips/mm/highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:36 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.490984112@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,10/18] nds32/mm/highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:33 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.586549209@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,11/18] powerpc/mm/highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:31 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.695446198@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,12/18] sparc/mm/highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:29 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.790791701@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,13/18] xtensa/mm/highmem: Switch to generic kmap atomic
From: snowpatch @ 2020-10-29 23:26 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.885593433@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,16/18] sched: highmem: Store local kmaps in task struct
From: snowpatch @ 2020-10-29 23:24 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222652.194349374@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,14/18] mm/highmem: Remove the old kmap_atomic cruft
From: snowpatch @ 2020-10-29 23:22 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222651.992069499@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,15/18] io-mapping: Cleanup atomic iomap
From: snowpatch @ 2020-10-29 23:20 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222652.084086429@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Re: [PATCH 0/4] arch, mm: improve robustness of direct map manipulation
From: Edgecombe, Rick P @ 2020-10-29 23:19 UTC (permalink / raw)
To: will@kernel.org, rppt@kernel.org
Cc: david@redhat.com, peterz@infradead.org, catalin.marinas@arm.com,
dave.hansen@linux.intel.com, linux-mm@kvack.org, paulus@samba.org,
pavel@ucw.cz, hpa@zytor.com, sparclinux@vger.kernel.org,
cl@linux.com, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, x86@kernel.org, rppt@linux.ibm.com,
borntraeger@de.ibm.com, mingo@redhat.com, rientjes@google.com,
Brown, Len, aou@eecs.berkeley.edu, gor@linux.ibm.com,
linux-pm@vger.kernel.org, hca@linux.ibm.com, bp@alien8.de,
luto@kernel.org, paul.walmsley@sifive.com, kirill@shutemov.name,
tglx@linutronix.de, iamjoonsoo.kim@lge.com,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, penberg@kernel.org,
palmer@dabbelt.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20201029081225.GK1428094@kernel.org>
On Thu, 2020-10-29 at 10:12 +0200, Mike Rapoport wrote:
> This series goal was primarily to separate dependincies and make it
> clearer what DEBUG_PAGEALLOC and what SET_DIRECT_MAP are. As it
> turned
> out, there is also some lack of consistency between architectures
> that
> implement either of this so I tried to improve this as well.
>
> Honestly, I don't know if a thread can be paused at the time
> __vunmap()
> left invalid pages, but it could, there is an issue on arm64 with
> DEBUG_PAGEALLOC=n and this set fixes it.
Ah, ok. So from this and the other thread, this is about the logic in
arm's cpa for when it will try the un/map operations. I think the logic
actually works currently. And this series introduces a problem on ARM
similar to the one you are saying preexists. I put the details in the
other thread.
^ permalink raw reply
* Re: [PATCH 2/4] PM: hibernate: improve robustness of mapping pages in the direct map
From: Edgecombe, Rick P @ 2020-10-29 23:19 UTC (permalink / raw)
To: rppt@kernel.org
Cc: david@redhat.com, peterz@infradead.org, catalin.marinas@arm.com,
dave.hansen@linux.intel.com, linux-mm@kvack.org, paulus@samba.org,
pavel@ucw.cz, hpa@zytor.com, sparclinux@vger.kernel.org,
cl@linux.com, will@kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, x86@kernel.org, rppt@linux.ibm.com,
borntraeger@de.ibm.com, mingo@redhat.com, rientjes@google.com,
Brown, Len, aou@eecs.berkeley.edu, gor@linux.ibm.com,
linux-pm@vger.kernel.org, hca@linux.ibm.com, bp@alien8.de,
luto@kernel.org, paul.walmsley@sifive.com, kirill@shutemov.name,
tglx@linutronix.de, iamjoonsoo.kim@lge.com,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, penberg@kernel.org,
palmer@dabbelt.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20201029075416.GJ1428094@kernel.org>
On Thu, 2020-10-29 at 09:54 +0200, Mike Rapoport wrote:
> __kernel_map_pages() on arm64 will also bail out if rodata_full is
> false:
> void __kernel_map_pages(struct page *page, int numpages, int enable)
> {
> if (!debug_pagealloc_enabled() && !rodata_full)
> return;
>
> set_memory_valid((unsigned long)page_address(page), numpages,
> enable);
> }
>
> So using set_direct_map() to map back pages removed from the direct
> map
> with __kernel_map_pages() seems safe to me.
Heh, one of us must have some simple boolean error in our head. I hope
its not me! :) I'll try on more time.
__kernel_map_pages() will bail out if rodata_full is false **AND**
debug page alloc is off. So it will only bail under conditions where
there could be nothing unmapped on the direct map.
Equivalent logic would be:
if (!(debug_pagealloc_enabled() || rodata_full))
return;
Or:
if (debug_pagealloc_enabled() || rodata_full)
set_memory_valid(blah)
So if either is on, the existing code will try to re-map. But the
set_direct_map_()'s will only work if rodata_full is on. So switching
hibernate to set_direct_map() will cause the remap to be missed for the
debug page alloc case, with !rodata_full.
It also breaks normal debug page alloc usage with !rodata_full for
similar reasons after patch 3. The pages would never get unmapped.
^ permalink raw reply
* Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
From: Linus Torvalds @ 2020-10-29 23:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Juri Lelli, linux-xtensa, Peter Zijlstra,
Sebastian Andrzej Siewior, linux-mips, Ben Segall, Linux-MM,
Guo Ren, linux-sparc, Vincent Chen, Ingo Molnar, linux-arch,
Vincent Guittot, Herbert Xu, the arch/x86 maintainers,
Russell King, linux-csky, Christoph Hellwig, David Airlie,
Mel Gorman, open list:SYNOPSYS ARC ARCHITECTURE, Ard Biesheuvel,
Paul McKenney, linuxppc-dev, Steven Rostedt, Greentime Hu,
Dietmar Eggemann, Linux ARM, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Nick Hu, Max Filippov, Vineet Gupta, LKML,
Arnd Bergmann, Daniel Vetter, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller
In-Reply-To: <20201029221806.189523375@linutronix.de>
On Thu, Oct 29, 2020 at 3:32 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
>
> Though I wanted to share the current state of affairs before investigating
> that further. If there is consensus in going forward with this, I'll have a
> deeper look into this issue.
Me likee. I think this looks like the right thing to do.
I didn't actually apply the patches, but just from reading them it
_looks_ to me like you do the migrate_disable() unconditionally, even
if it's not a highmem page..
That sounds like it might be a good thing for debugging, but not
necessarily great in general.
Or am I misreading things?
Linus
^ permalink raw reply
* Test Results: RE: [V2,17/18] mm/highmem: Provide kmap_local*
From: snowpatch @ 2020-10-29 23:18 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222652.302358281@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Test Results: RE: [V2,18/18] io-mapping: Provide iomap_local variant
From: snowpatch @ 2020-10-29 23:16 UTC (permalink / raw)
To: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201029222652.396632514@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
Thanks for your contribution, unfortunately we've found some issues.
Your patch failed to apply to any branch.
^ permalink raw reply
* Re: [PATCH 12/13] PCI: dwc: Move dw_pcie_setup_rc() to DWC common code
From: Jingoo Han @ 2020-10-29 22:29 UTC (permalink / raw)
To: Rob Herring, Lorenzo Pieralisi
Cc: Kunihiko Hayashi, Neil Armstrong, linux-pci@vger.kernel.org,
Binghui Wang, Bjorn Andersson, linux-tegra@vger.kernel.org,
Thierry Reding, linux-arm-kernel@axis.com, Thomas Petazzoni,
Jonathan Chocron, Shawn Guo, Jonathan Hunter, Fabio Estevam,
Jerome Brunet, Jesper Nilsson, linux-samsung-soc@vger.kernel.org,
Minghuan Lian, Kevin Hilman, Pratyush Anand, Krzysztof Kozlowski,
Kishon Vijay Abraham I, Kukjin Kim, NXP Linux Team, Xiaowei Song,
Richard Zhu, Martin Blumenstingl, linux-arm-msm@vger.kernel.org,
Sascha Hauer, Yue Wang, Murali Karicheri, Bjorn Helgaas,
linux-amlogic@lists.infradead.org, linux-omap@vger.kernel.org,
Mingkai Hu, Roy Zang, Masahiro Yamada, Gustavo Pimentel,
Andy Gross, Stanimir Varbanov, Pengutronix Kernel Team,
Han Jingoo, linuxppc-dev@lists.ozlabs.org, Lucas Stach
In-Reply-To: <20201028204646.356535-13-robh@kernel.org>
On 10/28/20, 4:47 PM, Rob Herring wrote:
>
> All RC complex drivers must call dw_pcie_setup_rc(). The ordering of the
> call shouldn't be too important other than being after any RC resets.
>
> There's a few calls of dw_pcie_setup_rc() left as drivers implementing
> suspend/resume need it.
>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Jingoo Han <jingoohan1@gmail.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Murali Karicheri <m-karicheri2@ti.com>
> Cc: Minghuan Lian <minghuan.Lian@nxp.com>
> Cc: Mingkai Hu <mingkai.hu@nxp.com>
> Cc: Roy Zang <roy.zang@nxp.com>
> Cc: Yue Wang <yue.wang@Amlogic.com>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Jesper Nilsson <jesper.nilsson@axis.com>
> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
> Cc: Xiaowei Song <songxiaowei@hisilicon.com>
> Cc: Binghui Wang <wangbinghui@hisilicon.com>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
> Cc: Pratyush Anand <pratyush.anand@gmail.com>
> Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: linux-omap@vger.kernel.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-amlogic@lists.infradead.org
> Cc: linux-arm-kernel@axis.com
> Cc: linux-arm-msm@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/pci/controller/dwc/pci-dra7xx.c | 1 -
> drivers/pci/controller/dwc/pci-exynos.c | 1 -
> drivers/pci/controller/dwc/pci-imx6.c | 1 -
> drivers/pci/controller/dwc/pci-keystone.c | 2 --
> drivers/pci/controller/dwc/pci-layerscape.c | 2 --
> drivers/pci/controller/dwc/pci-meson.c | 2 --
> drivers/pci/controller/dwc/pcie-armada8k.c | 2 --
> drivers/pci/controller/dwc/pcie-artpec6.c | 1 -
> drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
> drivers/pci/controller/dwc/pcie-designware-plat.c | 8 --------
> drivers/pci/controller/dwc/pcie-histb.c | 3 ---
> drivers/pci/controller/dwc/pcie-kirin.c | 2 --
> drivers/pci/controller/dwc/pcie-qcom.c | 1 -
> drivers/pci/controller/dwc/pcie-spear13xx.c | 2 --
> drivers/pci/controller/dwc/pcie-uniphier.c | 2 --
> 15 files changed, 1 insertion(+), 30 deletions(-)
[...]
^ permalink raw reply
* [patch V2 18/18] io-mapping: Provide iomap_local variant
From: Thomas Gleixner @ 2020-10-29 22:18 UTC (permalink / raw)
To: LKML
Cc: Juri Lelli, linux-xtensa, Peter Zijlstra,
Sebastian Andrzej Siewior, Ben Segall, linux-mm, Guo Ren,
sparclinux, Vincent Chen, Ingo Molnar, linux-arch,
Vincent Guittot, Herbert Xu, x86, Russell King, linux-csky,
Christoph Hellwig, David Airlie, Mel Gorman, linux-snps-arc,
Ard Biesheuvel, Paul McKenney, linuxppc-dev, Steven Rostedt,
Linus Torvalds, Greentime Hu, Dietmar Eggemann, linux-arm-kernel,
Chris Zankel, Michal Simek, Thomas Bogendoerfer, Nick Hu,
Max Filippov, Vineet Gupta, linux-mips, Arnd Bergmann,
Daniel Vetter, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller
In-Reply-To: <20201029221806.189523375@linutronix.de>
Similar to kmap local provide a iomap local variant which only disables
migration, but neither disables pagefaults nor preemption.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
V2: Split out from the large combo patch and add the !IOMAP_ATOMIC variants
---
include/linux/io-mapping.h | 34 ++++++++++++++++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -83,6 +83,23 @@ io_mapping_unmap_atomic(void __iomem *va
}
static inline void __iomem *
+io_mapping_map_local_wc(struct io_mapping *mapping, unsigned long offset)
+{
+ resource_size_t phys_addr;
+
+ BUG_ON(offset >= mapping->size);
+ phys_addr = mapping->base + offset;
+ migrate_disable();
+ return __iomap_local_pfn_prot(PHYS_PFN(phys_addr), mapping->prot);
+}
+
+static inline void io_mapping_unmap_local(void __iomem *vaddr)
+{
+ kunmap_local_indexed((void __force *)vaddr);
+ migrate_enable();
+}
+
+static inline void __iomem *
io_mapping_map_wc(struct io_mapping *mapping,
unsigned long offset,
unsigned long size)
@@ -101,7 +118,7 @@ io_mapping_unmap(void __iomem *vaddr)
iounmap(vaddr);
}
-#else
+#else /* HAVE_ATOMIC_IOMAP */
#include <linux/uaccess.h>
@@ -166,7 +183,20 @@ io_mapping_unmap_atomic(void __iomem *va
preempt_enable();
}
-#endif /* HAVE_ATOMIC_IOMAP */
+static inline void __iomem *
+io_mapping_map_local_wc(struct io_mapping *mapping, unsigned long offset)
+{
+ migrate_disable();
+ return io_mapping_map_wc(mapping, offset, PAGE_SIZE);
+}
+
+static inline void io_mapping_unmap_local(void __iomem *vaddr)
+{
+ io_mapping_unmap(vaddr);
+ migrate_enable();
+}
+
+#endif /* !HAVE_ATOMIC_IOMAP */
static inline struct io_mapping *
io_mapping_create_wc(resource_size_t base,
^ permalink raw reply
* [patch V2 17/18] mm/highmem: Provide kmap_local*
From: Thomas Gleixner @ 2020-10-29 22:18 UTC (permalink / raw)
To: LKML
Cc: Juri Lelli, linux-xtensa, Peter Zijlstra,
Sebastian Andrzej Siewior, Ben Segall, linux-mm, Guo Ren,
sparclinux, Vincent Chen, Ingo Molnar, linux-arch,
Vincent Guittot, Herbert Xu, x86, Russell King, linux-csky,
Christoph Hellwig, David Airlie, Mel Gorman, linux-snps-arc,
Ard Biesheuvel, Paul McKenney, linuxppc-dev, Steven Rostedt,
Linus Torvalds, Greentime Hu, Dietmar Eggemann, linux-arm-kernel,
Chris Zankel, Michal Simek, Thomas Bogendoerfer, Nick Hu,
Max Filippov, Vineet Gupta, linux-mips, Arnd Bergmann,
Daniel Vetter, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller
In-Reply-To: <20201029221806.189523375@linutronix.de>
Now that the kmap atomic index is stored in task struct provide a
preemptible variant. On context switch the maps of an outgoing task are
removed and the map of the incoming task are restored. That's obviously
slow, but highmem is slow anyway.
The kmap_local.*() functions can be invoked from both preemptible and
atomic context. kmap local sections disable migration to keep the resulting
virtual mapping address correct, but disable neither pagefaults nor
preemption.
A wholesale conversion of kmap_atomic to be fully preemptible is not
possible because some of the usage sites might rely on the preemption
disable for serialization or on the implicit pagefault disable. Needs to be
done on a case by case basis.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
V2: Make it more consistent and add commentry
---
include/linux/highmem.h | 115 +++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 100 insertions(+), 15 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -86,17 +86,56 @@ static inline void kunmap(struct page *p
}
/*
- * kmap_atomic/kunmap_atomic is significantly faster than kmap/kunmap because
- * no global lock is needed and because the kmap code must perform a global TLB
- * invalidation when the kmap pool wraps.
- *
- * However when holding an atomic kmap it is not legal to sleep, so atomic
- * kmaps are appropriate for short, tight code paths only.
- *
- * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
- * gives a more generic (and caching) interface. But kmap_atomic can
- * be used in IRQ contexts, so in some (very limited) cases we need
- * it.
+ * For highmem systems it is required to temporarily map pages
+ * which reside in the portion of memory which is not covered
+ * by the permanent kernel mapping.
+ *
+ * This comes in three flavors:
+ *
+ * 1) kmap/kunmap:
+ *
+ * An interface to acquire longer term mappings with no restrictions
+ * on preemption and migration. This comes with an overhead as the
+ * mapping space is restricted and protected by a global lock. It
+ * also requires global TLB invalidation when the kmap pool wraps.
+ *
+ * kmap() might block when the mapping space is fully utilized until a
+ * slot becomes available. Only callable from preemptible thread
+ * context.
+ *
+ * 2) kmap_local.*()/kunmap_local.*()
+ *
+ * An interface to acquire short term mappings. Can be invoked from any
+ * context including interrupts. The mapping is per thread, CPU local
+ * and not globaly visible. It can only be used in the context which
+ * acquried the mapping. Nesting kmap_local.*() and kmap_atomic.*()
+ * mappings is allowed to a certain extent (up to KMAP_TYPE_NR).
+ *
+ * Nested kmap_local.*() and kunmap_local.*() invocations have to be
+ * strictly ordered because the map implementation is stack based.
+ *
+ * kmap_local.*() disables migration, but keeps preemption enabled. It's
+ * valid to take pagefaults in a kmap_local region unless the context in
+ * which the local kmap is acquired does not allow it for other reasons.
+ *
+ * If a task holding local kmaps is preempted, the maps are removed on
+ * context switch and restored when the task comes back on the CPU. As
+ * the maps are strictly CPU local it is guaranteed that the task stays
+ * on the CPU and the CPU cannot be unplugged until the local kmaps are
+ * released.
+ *
+ * 3) kmap_atomic.*()/kunmap_atomic.*()
+ *
+ * Based on the same mechanism as kmap local. Atomic kmap disables
+ * preemption and pagefaults. Only use if absolutely required, use
+ * the corresponding kmap_local variant if possible.
+ *
+ * Local and atomic kmaps are faster than kmap/kunmap, but impose
+ * restrictions. Only use them when required.
+ *
+ * For !HIGHMEM enabled systems the kmap flavours are not doing any mapping
+ * operation and kmap() won't sleep, but the kmap local and atomic variants
+ * still disable migration resp. pagefaults and preemption.
*/
static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
{
@@ -122,6 +161,28 @@ static inline void __kunmap_atomic(void
kunmap_local_indexed(addr);
}
+static inline void *kmap_local_page_prot(struct page *page, pgprot_t prot)
+{
+ migrate_disable();
+ return __kmap_local_page_prot(page, prot);
+}
+
+static inline void *kmap_local_page(struct page *page)
+{
+ return kmap_local_page_prot(page, kmap_prot);
+}
+
+static inline void *kmap_local_pfn(unsigned long pfn)
+{
+ migrate_disable();
+ return __kmap_local_pfn_prot(pfn, kmap_prot);
+}
+
+static inline void __kunmap_local(void *vaddr)
+{
+ kunmap_local_indexed(vaddr);
+}
+
/* declarations for linux/mm/highmem.c */
unsigned int nr_free_highpages(void);
extern atomic_long_t _totalhigh_pages;
@@ -201,10 +262,27 @@ static inline void *kmap_atomic_pfn(unsi
static inline void __kunmap_atomic(void *addr)
{
- /*
- * Mostly nothing to do in the CONFIG_HIGHMEM=n case as kunmap_atomic()
- * handles re-enabling faults and preemption
- */
+ __kunmap_local(addr);
+}
+
+static inline void *kmap_local_page(struct page *page)
+{
+ migrate_disable();
+ return page_address(page);
+}
+
+static inline void *kmap_local_page_prot(struct page *page, pgprot_t prot)
+{
+ return kmap_local_page(page);
+}
+
+static inline void *kmap_local_pfn(unsigned long pfn)
+{
+ return kmap_local_page(pfn_to_page(pfn));
+}
+
+static inline void __kunmap_local(void *addr)
+{
#ifdef ARCH_HAS_FLUSH_ON_KUNMAP
kunmap_flush_on_unmap(addr);
#endif
@@ -226,6 +304,13 @@ do { \
preempt_enable(); \
} while (0)
+#define kunmap_local(__addr) \
+do { \
+ BUILD_BUG_ON(__same_type((__addr), struct page *)); \
+ __kunmap_local(__addr); \
+ migrate_enable(); \
+} while (0)
+
/* when CONFIG_HIGHMEM is not set these will be plain clear/copy_page */
#ifndef clear_user_highpage
static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
^ permalink raw reply
* [patch V2 15/18] io-mapping: Cleanup atomic iomap
From: Thomas Gleixner @ 2020-10-29 22:18 UTC (permalink / raw)
To: LKML
Cc: Juri Lelli, linux-xtensa, Peter Zijlstra,
Sebastian Andrzej Siewior, Ben Segall, linux-mm, Guo Ren,
sparclinux, Vincent Chen, Ingo Molnar, linux-arch,
Vincent Guittot, Herbert Xu, x86, Russell King, linux-csky,
Christoph Hellwig, David Airlie, Mel Gorman, linux-snps-arc,
Ard Biesheuvel, Paul McKenney, linuxppc-dev, Steven Rostedt,
Linus Torvalds, Greentime Hu, Dietmar Eggemann, linux-arm-kernel,
Chris Zankel, Michal Simek, Thomas Bogendoerfer, Nick Hu,
Max Filippov, Vineet Gupta, linux-mips, Arnd Bergmann,
Daniel Vetter, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller
In-Reply-To: <20201029221806.189523375@linutronix.de>
Switch the atomic iomap implementation over to kmap_local and stick the
preempt/pagefault mechanics into the generic code similar to the
kmap_atomic variants.
Rename the x86 map function in preparation for a non-atomic variant.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
V2: New patch to make review easier
---
arch/x86/include/asm/iomap.h | 9 +--------
arch/x86/mm/iomap_32.c | 6 ++----
include/linux/io-mapping.h | 8 ++++++--
3 files changed, 9 insertions(+), 14 deletions(-)
--- a/arch/x86/include/asm/iomap.h
+++ b/arch/x86/include/asm/iomap.h
@@ -13,14 +13,7 @@
#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
-void __iomem *iomap_atomic_pfn_prot(unsigned long pfn, pgprot_t prot);
-
-static inline void iounmap_atomic(void __iomem *vaddr)
-{
- kunmap_local_indexed((void __force *)vaddr);
- pagefault_enable();
- preempt_enable();
-}
+void __iomem *__iomap_local_pfn_prot(unsigned long pfn, pgprot_t prot);
int iomap_create_wc(resource_size_t base, unsigned long size, pgprot_t *prot);
--- a/arch/x86/mm/iomap_32.c
+++ b/arch/x86/mm/iomap_32.c
@@ -44,7 +44,7 @@ void iomap_free(resource_size_t base, un
}
EXPORT_SYMBOL_GPL(iomap_free);
-void __iomem *iomap_atomic_pfn_prot(unsigned long pfn, pgprot_t prot)
+void __iomem *__iomap_local_pfn_prot(unsigned long pfn, pgprot_t prot)
{
/*
* For non-PAT systems, translate non-WB request to UC- just in
@@ -60,8 +60,6 @@ void __iomem *iomap_atomic_pfn_prot(unsi
/* Filter out unsupported __PAGE_KERNEL* bits: */
pgprot_val(prot) &= __default_kernel_pte_mask;
- preempt_disable();
- pagefault_disable();
return (void __force __iomem *)__kmap_local_pfn_prot(pfn, prot);
}
-EXPORT_SYMBOL_GPL(iomap_atomic_pfn_prot);
+EXPORT_SYMBOL_GPL(__iomap_local_pfn_prot);
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -69,13 +69,17 @@ io_mapping_map_atomic_wc(struct io_mappi
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
- return iomap_atomic_pfn_prot(PHYS_PFN(phys_addr), mapping->prot);
+ preempt_disable();
+ pagefault_disable();
+ return __iomap_local_pfn_prot(PHYS_PFN(phys_addr), mapping->prot);
}
static inline void
io_mapping_unmap_atomic(void __iomem *vaddr)
{
- iounmap_atomic(vaddr);
+ kunmap_local_indexed((void __force *)vaddr);
+ pagefault_enable();
+ preempt_enable();
}
static inline void __iomem *
^ permalink raw reply
* [patch V2 14/18] mm/highmem: Remove the old kmap_atomic cruft
From: Thomas Gleixner @ 2020-10-29 22:18 UTC (permalink / raw)
To: LKML
Cc: Juri Lelli, linux-xtensa, Peter Zijlstra,
Sebastian Andrzej Siewior, Ben Segall, linux-mm, Guo Ren,
sparclinux, Vincent Chen, Ingo Molnar, linux-arch,
Vincent Guittot, Herbert Xu, x86, Russell King, linux-csky,
Christoph Hellwig, David Airlie, Mel Gorman, linux-snps-arc,
Ard Biesheuvel, Paul McKenney, linuxppc-dev, Steven Rostedt,
Linus Torvalds, Greentime Hu, Dietmar Eggemann, linux-arm-kernel,
Chris Zankel, Michal Simek, Thomas Bogendoerfer, Nick Hu,
Max Filippov, Vineet Gupta, linux-mips, Arnd Bergmann,
Daniel Vetter, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller
In-Reply-To: <20201029221806.189523375@linutronix.de>
All users gone.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
include/linux/highmem.h | 61 ++----------------------------------------------
mm/highmem.c | 28 ++++++++++++++++++----
2 files changed, 27 insertions(+), 62 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -88,31 +88,16 @@ static inline void kunmap(struct page *p
* be used in IRQ contexts, so in some (very limited) cases we need
* it.
*/
-
-#ifndef CONFIG_KMAP_LOCAL
-void *kmap_atomic_high_prot(struct page *page, pgprot_t prot);
-void kunmap_atomic_high(void *kvaddr);
-
static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
{
preempt_disable();
pagefault_disable();
- if (!PageHighMem(page))
- return page_address(page);
- return kmap_atomic_high_prot(page, prot);
-}
-
-static inline void __kunmap_atomic(void *vaddr)
-{
- kunmap_atomic_high(vaddr);
+ return __kmap_local_page_prot(page, prot);
}
-#else /* !CONFIG_KMAP_LOCAL */
-static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
+static inline void *kmap_atomic(struct page *page)
{
- preempt_disable();
- pagefault_disable();
- return __kmap_local_page_prot(page, prot);
+ return kmap_atomic_prot(page, kmap_prot);
}
static inline void *kmap_atomic_pfn(unsigned long pfn)
@@ -127,13 +112,6 @@ static inline void __kunmap_atomic(void
kunmap_local_indexed(addr);
}
-#endif /* CONFIG_KMAP_LOCAL */
-
-static inline void *kmap_atomic(struct page *page)
-{
- return kmap_atomic_prot(page, kmap_prot);
-}
-
/* declarations for linux/mm/highmem.c */
unsigned int nr_free_highpages(void);
extern atomic_long_t _totalhigh_pages;
@@ -226,39 +204,6 @@ static inline void __kunmap_atomic(void
#endif /* CONFIG_HIGHMEM */
-#if defined(CONFIG_HIGHMEM) || defined(CONFIG_X86_32)
-
-DECLARE_PER_CPU(int, __kmap_atomic_idx);
-
-static inline int kmap_atomic_idx_push(void)
-{
- int idx = __this_cpu_inc_return(__kmap_atomic_idx) - 1;
-
-#ifdef CONFIG_DEBUG_HIGHMEM
- WARN_ON_ONCE(in_irq() && !irqs_disabled());
- BUG_ON(idx >= KM_TYPE_NR);
-#endif
- return idx;
-}
-
-static inline int kmap_atomic_idx(void)
-{
- return __this_cpu_read(__kmap_atomic_idx) - 1;
-}
-
-static inline void kmap_atomic_idx_pop(void)
-{
-#ifdef CONFIG_DEBUG_HIGHMEM
- int idx = __this_cpu_dec_return(__kmap_atomic_idx);
-
- BUG_ON(idx < 0);
-#else
- __this_cpu_dec(__kmap_atomic_idx);
-#endif
-}
-
-#endif
-
/*
* Prevent people trying to call kunmap_atomic() as if it were kunmap()
* kunmap_atomic() should get the return value of kmap_atomic, not the page.
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -32,10 +32,6 @@
#include <linux/vmalloc.h>
#include <asm/fixmap.h>
-#if defined(CONFIG_HIGHMEM) || defined(CONFIG_X86_32)
-DEFINE_PER_CPU(int, __kmap_atomic_idx);
-#endif
-
/*
* Virtual_count is not a pure "count".
* 0 means that it is not mapped, and has not been mapped
@@ -370,6 +366,30 @@ EXPORT_SYMBOL(kunmap_high);
#endif /* CONFIG_HIGHMEM */
#ifdef CONFIG_KMAP_LOCAL
+
+static DEFINE_PER_CPU(int, __kmap_atomic_idx);
+
+static inline int kmap_atomic_idx_push(void)
+{
+ int idx = __this_cpu_inc_return(__kmap_atomic_idx) - 1;
+
+ WARN_ON_ONCE(in_irq() && !irqs_disabled());
+ BUG_ON(idx >= KM_TYPE_NR);
+ return idx;
+}
+
+static inline int kmap_atomic_idx(void)
+{
+ return __this_cpu_read(__kmap_atomic_idx) - 1;
+}
+
+static inline void kmap_atomic_idx_pop(void)
+{
+ int idx = __this_cpu_dec_return(__kmap_atomic_idx);
+
+ BUG_ON(idx < 0);
+}
+
#ifndef arch_kmap_local_post_map
# define arch_kmap_local_post_map(vaddr, pteval) do { } while (0)
#endif
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox