[patch V2 08/18] microblaze/mm/highmem: Switch to generic kmap atomic

No reason having the same code in every architecture. Signed-off-by: Thomas Gleixner Cc: Michal Simek diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index d262ac0c8714..186a0526564c 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -170,6 +170,7 @@ config

[patch V2 06/18] ARM: highmem: Switch to generic kmap atomic

No reason having the same code in every architecture. Signed-off-by: Thomas Gleixner Cc: Russell King Cc: Arnd Bergmann Cc: linux-arm-ker...@lists.infradead.org diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e00d94b16658..410235e350cc 100644 --- a/arch/arm/Kconfig +++

[patch V2 07/18] csky/mm/highmem: Switch to generic kmap atomic

No reason having the same code in every architecture. Signed-off-by: Thomas Gleixner Acked-by: Guo Ren Cc: linux-c...@vger.kernel.org --- arch/csky/Kconfig |1 arch/csky/include/asm/highmem.h |4 +- arch/csky/mm/highmem.c | 75

[patch V2 10/18] nds32/mm/highmem: Switch to generic kmap atomic

The mapping code is odd and looks broken. See FIXME in the comment. Signed-off-by: Thomas Gleixner Cc: Nick Hu Cc: Greentime Hu Cc: Vincent Chen diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu index f88a12fdf0f3..c7add11ea36e 100644 --- a/arch/nds32/Kconfig.cpu +++

[patch V2 05/18] arc/mm/highmem: Use generic kmap atomic implementation

Adopt the map ordering to match the other architectures and the generic code. Signed-off-by: Thomas Gleixner Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org --- arch/arc/Kconfig |1 arch/arc/include/asm/highmem.h |8 ++- arch/arc/mm/highmem.c | 44

[patch V2 03/18] highmem: Provide generic variant of kmap_atomic*

The kmap_atomic* interfaces in all architectures are pretty much the same except for post map operations (flush) and pre- and post unmap operations. Provide a generic variant for that. Signed-off-by: Thomas Gleixner Cc: Andrew Morton Cc: linux...@kvack.org --- V2: Address review comments from

[patch V2 16/18] sched: highmem: Store local kmaps in task struct

Instead of storing the map per CPU provide and use per task storage. That prepares for local kmaps which are preemptible. The context switch code is preparatory and not yet in use because kmap_atomic() runs with preemption disabled. Will be made usable in the next step. The context switch logic

[patch V2 04/18] x86/mm/highmem: Use generic kmap atomic implementation

Convert X86 to the generic kmap atomic implementation and make the iomap_atomic() naming convention consistent while at it. Signed-off-by: Thomas Gleixner Cc: x...@kernel.org --- arch/x86/Kconfig |3 +- arch/x86/include/asm/fixmap.h |1 arch/x86/include/asm/highmem.h |

[patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266...@linutronix.de and the initial version of this: https://lore.kernel.org/r/20200919091751.06...@linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. Now that

[patch V2 02/18] mm/highmem: Un-EXPORT __kmap_atomic_idx()

Nothing in modules can use that. Signed-off-by: Thomas Gleixner Reviewed-by: Christoph Hellwig Cc: Andrew Morton Cc: linux...@kvack.org --- mm/highmem.c |2 -- 1 file changed, 2 deletions(-) --- a/mm/highmem.c +++ b/mm/highmem.c @@ -108,8 +108,6 @@ static inline wait_queue_head_t

[patch V2 01/18] sched: Make migrate_disable/enable() independent of RT

Now that the scheduler can deal with migrate disable properly, there is no real compelling reason to make it only available for RT. There are quite some code pathes which needlessly disable preemption in order to prevent migration and some constructs like kmap_atomic() enforce it implicitly.

[PATCH] arc: add support for TIF_NOTIFY_SIGNAL

Wire up TIF_NOTIFY_SIGNAL handling for arc. Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Jens Axboe --- 5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting for details: https://lore.kernel.org/io-uring/20201026203230.386348-1-ax...@kernel.dk/ As part of that work,

[PATCH] ARC: [plat-hsdk] Remap CCMs super early in asm boot trampoline

ARC HSDK platform stopped booting on released v5.10-rc1, getting stuck in startup of non master SMP cores. This was bisected to upstream commit 7fef431be9c9ac25 "(mm/page_alloc: place pages to tail in __free_pages_core())" That commit itself is harmless, it just exposed a subtle assumption in our

[patch V2 18/18] io-mapping: Provide iomap_local variant

Similar to kmap local provide a iomap local variant which only disables migration, but neither disables pagefaults nor preemption. Signed-off-by: Thomas Gleixner --- V2: Split out from the large combo patch and add the !IOMAP_ATOMIC variants --- include/linux/io-mapping.h | 34

[patch V2 13/18] xtensa/mm/highmem: Switch to generic kmap atomic

No reason having the same code in every architecture Signed-off-by: Thomas Gleixner Cc: Chris Zankel Cc: Max Filippov Cc: linux-xte...@linux-xtensa.org --- arch/xtensa/Kconfig |1 arch/xtensa/include/asm/highmem.h |9 +++ arch/xtensa/mm/highmem.c | 44

[patch V2 17/18] mm/highmem: Provide kmap_local*

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

[patch V2 11/18] powerpc/mm/highmem: Switch to generic kmap atomic

No reason having the same code in every architecture Signed-off-by: Thomas Gleixner Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-...@lists.ozlabs.org --- arch/powerpc/Kconfig |1 arch/powerpc/include/asm/highmem.h |6 ++-

[patch V2 12/18] sparc/mm/highmem: Switch to generic kmap atomic

No reason having the same code in every architecture Signed-off-by: Thomas Gleixner Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org --- arch/sparc/Kconfig |1 arch/sparc/include/asm/highmem.h |7 +- arch/sparc/mm/Makefile |3 - arch/sparc/mm/highmem.c

[patch V2 15/18] io-mapping: Cleanup atomic iomap

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 --- V2: New patch to make review

[patch V2 14/18] mm/highmem: Remove the old kmap_atomic cruft

All users gone. Signed-off-by: Thomas Gleixner --- include/linux/highmem.h | 61 ++-- mm/highmem.c| 28 ++ 2 files changed, 27 insertions(+), 62 deletions(-) --- a/include/linux/highmem.h +++

[patch V2 09/18] mips/mm/highmem: Switch to generic kmap atomic

No reason having the same code in every architecture Signed-off-by: Thomas Gleixner Cc: Thomas Bogendoerfer Cc: linux-m...@vger.kernel.org diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 8f328298f8cc..ed6b3de944a8 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2654,6

Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends

On Thu, Oct 29, 2020 at 3:32 PM Thomas Gleixner 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

Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends

On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote: > On Thu, Oct 29, 2020 at 3:32 PM Thomas Gleixner 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