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
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 issu
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 to
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
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 +++
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 easi
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
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 ++-
arch/powerpc/
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
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
+++ b/include/linux/highme
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 +2654,
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 i
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
+++ b/arch/arm/Kconfi
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 -
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
+++ b/arch/nds32/K
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 XIL
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 |
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 -
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 C
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 *get_pkm
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.
Maki
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 the
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, I'm
23 matches
Mail list logo