Christophe Leroy writes:
> To be sure we are not in front of a long lasting bug, could you try
> CONFIG_KASAN=y on v5.9 ?
Indeed it started to fail somewhere between v5.6 and v5.7.
v5.7 fails early with few messages on the console with reboot, v5.8 and
later hang right at bootloader.
I'm
Le 03/11/2020 à 19:58, Serge Belyshev a écrit :
Would you mind checking that with that patch reverted, you are able to
boot a kernel built with CONFIG_KASAN ?
I can reproduce the same problem on a powerbook G4, and no,
CONFIG_KASAN=y kernel with that patch reverted also does not boot with
Hi Oliver,
I love your patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.10-rc2 next-20201103]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented
From: Nicholas Piggin
commit d53c3dfb23c45f7d4f910c3a3ca84bf0a99c6143 upstream.
Reading and modifying current->mm and current->active_mm and switching
mm should be done with irqs off, to prevent races seeing an intermediate
state.
This is similar to commit 38cf307c1f20 ("mm: fix
On Tue, Nov 03, 2020 at 07:42:56AM -0600, YiFei Zhu wrote:
> From: YiFei Zhu
>
> This patch series enables bitmap cache for the remaining arches with
> SECCOMP_FILTER, other than MIPS.
>
> I was unable to find any of the arches having subarch-specific NR_syscalls
> macros, so generic
The panic (on a call to malloc from static linked libcrypto) looks like
this:
Bad kernel stack pointer 7fffeac0 at 700
Oops: Bad kernel stack pointer, sig: 6 [#1]
SMP NR_CPUS=2048
NUMA
pSeries
Modules linked in: scsi_transport_iscsi af_packet xt_tcpudp ip6t_rpfilter
ip6t_REJECT ipt_REJECT
Hi Laurent, Christophe, Michael, all,
On 11/3/20 5:11 PM, Laurent Dufour wrote:
> Le 23/10/2020 à 14:28, Christophe Leroy a écrit :
[..]
That seems like it would work for CRIU and make sense in general?
>>>
>>> Sorry for the late answer, yes this would make more sense.
>>>
>>> Here is a
On Tue, Nov 03 2020 at 09:48, Linus Torvalds wrote:
> I have no complaints about the patch, but it strikes me that if people
> want to actually have much better debug coverage, this is where it
> should be (I like the "every other address" thing too, don't get me
> wrong).
>
> In particular,
On Sat, 2020-10-31 at 09:59 -0700, Jakub Kicinski wrote:
> On Tue, 27 Oct 2020 23:54:43 +0100 Sebastian Andrzej Siewior wrote:
> > mlx5_eq_async_int() uses in_irq() to decide whether eq::lock needs
> > to be
> > acquired and released with spin_[un]lock() or the irq
> > saving/restoring
> >
Le 03/11/2020 à 19:58, Segher Boessenkool a écrit :
On Tue, Nov 03, 2020 at 03:43:55PM +0100, Christophe Leroy wrote:
Le 03/11/2020 à 14:29, Michael Ellerman a écrit :
For now though let's just not use asm goto with GCC 4.9, to avoid this
bug and any other issues we haven't noticed yet.
> Would you mind checking that with that patch reverted, you are able to
> boot a kernel built with CONFIG_KASAN ?
I can reproduce the same problem on a powerbook G4, and no,
CONFIG_KASAN=y kernel with that patch reverted also does not boot with
the same symptom: white screen at the bootloader
On Tue, Nov 03, 2020 at 03:43:55PM +0100, Christophe Leroy wrote:
> Le 03/11/2020 à 14:29, Michael Ellerman a écrit :
> >For now though let's just not use asm goto with GCC 4.9, to avoid this
> >bug and any other issues we haven't noticed yet. Possibly in future we
> >can find a smaller
Le 23/10/2020 à 15:24, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
Le 17/09/2020 à 14:33, Michael Ellerman a écrit :
Christophe Leroy writes:
What is the status with the generic C vdso merge ?
In some mail, you mentionned having
Le 24/10/2020 à 12:07, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
Le 17/09/2020 à 14:33, Michael Ellerman a écrit :
Christophe Leroy writes:
What is the status with the generic C vdso merge ?
In some
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
>
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
On Tue, Nov 03 2020 at 10:27, Thomas Gleixner wrote:
> +struct kmap_ctrl {
> +#ifdef CONFIG_KMAP_LOCAL
> + int idx;
> + pte_t pteval[KM_TYPE_NR];
I'm a moron. Fixed it on the test machine ...
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for sh.
Signed-off-by: YiFei Zhu
---
arch/sh/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls.
This will
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for xtensa.
Signed-off-by: YiFei Zhu
---
arch/xtensa/include/asm/Kbuild| 1 -
arch/xtensa/include/asm/seccomp.h | 11 +++
2
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for riscv.
Signed-off-by: YiFei Zhu
---
arch/riscv/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for s390.
Signed-off-by: YiFei Zhu
---
arch/s390/include/asm/seccomp.h | 9 +
1 file changed, 9 insertions(+)
diff --git
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for parisc.
Signed-off-by: YiFei Zhu
---
arch/parisc/include/asm/Kbuild| 1 -
arch/parisc/include/asm/seccomp.h | 22
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for powerpc.
Signed-off-by: YiFei Zhu
---
arch/powerpc/include/asm/seccomp.h | 21 +
1 file changed, 21 insertions(+)
From: YiFei Zhu
This patch series enables bitmap cache for the remaining arches with
SECCOMP_FILTER, other than MIPS.
I was unable to find any of the arches having subarch-specific NR_syscalls
macros, so generic NR_syscalls is used. SH's syscall_get_arch seems to
only have the 32-bit subarch
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for csky.
Signed-off-by: YiFei Zhu
---
arch/csky/include/asm/Kbuild| 1 -
arch/csky/include/asm/seccomp.h | 11 +++
2 files
On Tue, Nov 3, 2020 at 10:27 AM Thomas Gleixner wrote:
>
> kmap_types.h is a misnomer because the old atomic MAP based array does not
> exist anymore and the whole indirection of architectures including
> kmap_types.h is inconinstent and does not allow to provide guard page
> debugging for this
On Tue, Nov 03, 2020 at 10:27:15AM +0100, Thomas Gleixner wrote:
> Historical leftovers from the time where kmap() had fixed slots.
>
> Signed-off-by: Thomas Gleixner
> Cc: Alexander Viro
> Cc: Benjamin LaHaise
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-...@kvack.org
> Cc: Chris Mason
>
Provides __kernel_clock_gettime64() on vdso32. This is the
64 bits version of __kernel_clock_gettime() which is
y2038 compliant.
Signed-off-by: Christophe Leroy
---
v12: Added missing prototype
---
arch/powerpc/include/asm/vdso/gettimeofday.h | 2 ++
arch/powerpc/kernel/vdso32/gettimeofday.S
For VDSO32 on PPC64, we create a fake 32 bits config, on the same
principle as MIPS architecture, in order to get the correct parts of
the different asm header files.
With the C VDSO, the performance is slightly lower, but it is worth
it as it will ease maintenance and evolution, and also brings
Prepare for switching VDSO to generic C implementation in following
patch. Here, we:
- Prepare the helpers to call the C VDSO functions
- Prepare the required callbacks for the C VDSO functions
- Prepare the clocksource.h files to define VDSO_ARCH_CLOCKMODES
- Add the C trampolines to the generic
On PPC64, the TOC pointer needs to be saved and restored.
Suggested-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
v13: Using __powerpc64__ instead of CONFIG_PPC64 to exclude it from VDSO32
build on PPC64.
v9: New.
I'm not sure this is really needed, I can't see the VDSO C code
In order to easily use get_tb() from C VDSO, move timebase
functions into a new header named asm/timebase.h
Signed-off-by: Christophe Leroy
---
v13: new
---
arch/powerpc/include/asm/time.h | 30 +
arch/powerpc/include/asm/timebase.h | 42 +
2
This is a series to switch powerpc VDSO to generic C implementation.
Changes in v13:
- Reorganised headers to avoid the need for a fake 32 bits config for building
VDSO32 on PPC64
- Rebased after the removal of powerpc 601
- Using DOTSYM() macro to call functions directly without using OPD
-
On 8xx, we get the following features:
[0.00] cpu_features = 0x0100
[0.00] possible= 0x0120
[0.00] always = 0x
This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all
other configurations, the
cpu_relax() need to be in asm/vdso/processor.h to be used by
the C VDSO generic library.
Move it there.
Signed-off-by: Christophe Leroy
---
v9: Forgot to remove cpu_relax() from processor.h in v8
---
arch/powerpc/include/asm/processor.h | 13 ++---
In order to build VDSO32 for PPC64, we need to have CPU_FTRS_POSSIBLE
and CPU_FTRS_ALWAYS independant of whether we are building the
32 bits VDSO or the 64 bits VDSO.
Use #ifdef CONFIG_PPC64 instead of #ifdef __powerpc64__
Signed-off-by: Christophe Leroy
---
v13: new
---
The check introduced by the commit 83d3f0e90c6c ("powerpc/mm: tracking vDSO
remap") is wrong and is missing some partial unmaps of the VDSO.
To be complete the check needs the base and end address of the
VDSO. Currently only the base is available in the mm_context of a task, but
the end address
Le 23/10/2020 à 14:28, Christophe Leroy a écrit :
Hi Laurent
Le 07/05/2019 à 18:35, Laurent Dufour a écrit :
Le 01/05/2019 à 12:32, Michael Ellerman a écrit :
Laurent Dufour writes:
Le 23/04/2019 à 18:04, Dave Hansen a écrit :
On 4/23/19 4:16 AM, Laurent Dufour wrote:
...
There are 2
Quoting Christophe Leroy :
Le 03/11/2020 à 14:29, Michael Ellerman a écrit :
Andreas reported that commit ee0a49a6870e ("powerpc/uaccess: Switch
__put_user_size_allowed() to __put_user_asm_goto()") broke
CLONE_CHILD_SETTID.
Further inspection showed that the put_user() in schedule_tail()
From: Mike Rapoport
For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
verify that a page is mapped in the kernel direct map can be useful
regardless of hibernation.
Add RISC-V implementation of kernel_page_present(), update its forward
declarations and stubs to be a part
From: Mike Rapoport
The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never
fail. With this assumption is wouldn't be safe to allow general usage of
this function.
Moreover, some architectures that implement __kernel_map_pages() have this
function guarded by #ifdef
From: Mike Rapoport
When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
not present in the direct map and has to be explicitly mapped before it
could be copied.
Introduce hibernate_map_page() that will explicitly use
set_direct_map_{default,invalid}_noflush() for
From: Mike Rapoport
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded with with debug_pagealloc_enabled().
The
From: Mike Rapoport
Hi,
During recent discussion about KVM protected memory, David raised a concern
about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1].
Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is
possible that __kernel_map_pages() would
On Tue, 3 Nov 2020 15:10:43 +0100
Petr Mladek wrote:
> BTW: What is actually the purpose of paranoid_test, please?
>
> It prevents nested ftrace_record_recursion() calls on the same CPU
> (recursion, nesting from IRQ, NMI context).
>
> Parallel calls from different CPUs are still possible:
>
On Tue, Nov 03, 2020 at 05:39:16PM +0300, Kirill A. Shutemov wrote:
> On Tue, Nov 03, 2020 at 02:13:50PM +0200, Mike Rapoport wrote:
> > > > +
> > > > + if (WARN_ON(ret))
> > >
> > > _ONCE?
> >
> > I've changed it to pr_warn() after David said people enable panic on
> > warn in
Fixes the following W=1 kernel build warning(s):
drivers/soc/fsl/qbman/qman.c: In function ‘qman_shutdown_fq’:
drivers/soc/fsl/qbman/qman.c:2700:8: warning: variable ‘dequeue_wq’ set but
not used [-Wunused-but-set-variable]
Cc: Li Yang
Cc: YueHaibing
Cc: linuxppc-dev@lists.ozlabs.org
Fixes the following W=1 kernel build warning(s):
drivers/soc/fsl/qe/qe_common.c:237: warning: Function parameter or member
'addr' not described in 'cpm_muram_dma'
drivers/soc/fsl/qe/qe_common.c:237: warning: Excess function parameter
'offset' description in 'cpm_muram_dma'
Cc: Qiang Zhao
Fixes the following W=1 kernel build warning(s):
drivers/soc/fsl/dpio/qbman-portal.c:430: warning: Function parameter or member
'inhibit' not described in 'qbman_swp_interrupt_set_inhibit'
drivers/soc/fsl/dpio/qbman-portal.c:430: warning: Excess function parameter
'mask' description in
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (25):
soc: bcm: brcmstb: pm: pm-arm: Provide prototype for
brcmstb_pm_s3_finish()
soc: qcom: qcom_aoss: Remove set but unused
On Wed 28 Oct 09:23 CDT 2020, Mauro Carvalho Chehab wrote:
[..]
> .../ABI/testing/sysfs-class-remoteproc| 14 +-
for this:
Acked-by: Bjorn Andersson
Thanks,
Bjorn
Le 03/11/2020 à 14:29, Michael Ellerman a écrit :
Andreas reported that commit ee0a49a6870e ("powerpc/uaccess: Switch
__put_user_size_allowed() to __put_user_asm_goto()") broke
CLONE_CHILD_SETTID.
Further inspection showed that the put_user() in schedule_tail() was
missing entirely, the
On Tue, Nov 03, 2020 at 02:13:50PM +0200, Mike Rapoport wrote:
> On Tue, Nov 03, 2020 at 02:08:16PM +0300, Kirill A. Shutemov wrote:
> > On Sun, Nov 01, 2020 at 07:08:13PM +0200, Mike Rapoport wrote:
> > > diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> > > index
On Mon 2020-11-02 14:23:14, Steven Rostedt wrote:
> From c532ff6b048dd4a12943b05c7b8ce30666c587c8 Mon Sep 17 00:00:00 2001
> From: "Steven Rostedt (VMware)"
> Date: Thu, 29 Oct 2020 15:27:06 -0400
> Subject: [PATCH] ftrace: Add recording of functions that caused recursion
>
> This adds
Andreas reported that commit ee0a49a6870e ("powerpc/uaccess: Switch
__put_user_size_allowed() to __put_user_asm_goto()") broke
CLONE_CHILD_SETTID.
Further inspection showed that the put_user() in schedule_tail() was
missing entirely, the store not emitted by the compiler.
<.schedule_tail>:
Andreas Schwab writes:
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/powerpc 5.10.0-rc1 Kernel Configuration
> #
> CONFIG_CC_VERSION_TEXT="gcc-4.9 (SUSE Linux) 4.9.3"
So it seems to be a combination of GCC 4.9 and ...
> # CONFIG_PPC_RADIX_MMU is not set
That ^, which
On Tue, Nov 03, 2020 at 02:08:16PM +0300, Kirill A. Shutemov wrote:
> On Sun, Nov 01, 2020 at 07:08:13PM +0200, Mike Rapoport wrote:
> > diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> > index 46b1804c1ddf..054c8cce4236 100644
> > --- a/kernel/power/snapshot.c
> > +++
On Fri, 30 Oct 2020 17:31:47 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> If a ftrace callback does not supply its own recursion protection and
> does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will
> make a helper trampoline to do so before calling the
On Sun, Nov 01, 2020 at 07:08:11PM +0200, Mike Rapoport wrote:
> Mike Rapoport (4):
> mm: introduce debug_pagealloc_map_pages() helper
> PM: hibernate: make direct map manipulations more explicit
> arch, mm: restore dependency of __kernel_map_pages() of DEBUG_PAGEALLOC
> arch, mm: make
On Sun, Nov 01, 2020 at 07:08:13PM +0200, Mike Rapoport wrote:
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 46b1804c1ddf..054c8cce4236 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -76,6 +76,32 @@ static inline void
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Yes, reverting this commit (on top of -rc1) makes the G4 boot again. Did not
try -rc2 though.
--
You are receiving this mail because:
You are watching the assignee of the bug.
No more users. Get rid of it and remove the traces in documentation.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
Documentation/driver-api/io-mapping.rst | 22 +---
include/linux/io-mapping.h | 42 +---
2 files changed, 9
None of these mapping requires the side effect of disabling pagefaults and
preemption.
Use io_mapping_map_local_wc() instead, and clean up gtt_user_read() and
gtt_user_write() to use a plain copy_from_user() as the local maps are not
disabling pagefaults.
Signed-off-by: Thomas Gleixner
Cc: Jani
Neither fbmem_peek() nor fbmem_poke() require to disable pagefaults and
preemption as a side effect of io_mapping_map_atomic_wc().
Use io_mapping_map_local_wc() instead.
Signed-off-by: Thomas Gleixner
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc:
None of these mapping requires the side effect of disabling pagefaults and
preemption.
Use io_mapping_map_local_wc() instead, rename the related functions
accordingly and clean up qxl_process_single_command() to use a plain
copy_from_user() as the local maps are not disabling pagefaults.
There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().
Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.
Remove the NULL pointer check for the map. These functions return a valid
address for valid
No more users.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem-internal.h | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
--- a/include/linux/highmem-internal.h
+++ b/include/linux/highmem-internal.h
@@ -87,16 +87,11 @@ static inline void
There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().
Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.
Remove the NULL pointer check for the map. These functions return a valid
address for valid
No more users.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem-internal.h | 12
1 file changed, 12 deletions(-)
--- a/include/linux/highmem-internal.h
+++ b/include/linux/highmem-internal.h
@@ -99,13 +99,6 @@ static inline void *kmap_atomic(struct p
There is no requirement to disable pagefaults and preemption for these
cache management mappings.
Replace kmap_atomic_pfn() with kmap_local_pfn(). This allows to remove
kmap_atomic_pfn() in the next step.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Replace kmap_atomic_pfn() with kmap_local_pfn() which is preemptible and
can take page faults.
Remove the indirection of the dump page and the related cruft which is not
longer required.
Signed-off-by: Thomas Gleixner
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
V3: New patch
---
Similar to kmap local provide a iomap local variant which only disables
migration, but neither disables pagefaults nor preemption.
Signed-off-by: Thomas Gleixner
---
V3: Restrict migrate disable to the 32bit mapping case and update documentation.
V2: Split out from the large combo patch and add
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
Replace kmap_atomic_pfn() with kmap_local_pfn() which is preemptible and
can take page faults.
Remove the indirection of the dump page and the related cruft which is not
longer required.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
arch/x86/kernel/crash_dump_32.c | 48
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
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.
Move the gory details of kmap & al into a private header and only document
the interfaces which are usable by drivers.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem-internal.h | 174 +
include/linux/highmem.h | 270
The implementation details in the documentation are outdated and not really
helpful. Remove them.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
Documentation/driver-api/io-mapping.rst | 22 --
1 file changed, 22 deletions(-)
---
All users gone.
Signed-off-by: Thomas Gleixner
---
include/linux/highmem.h | 63 +++-
mm/highmem.c|7 -
2 files changed, 5 insertions(+), 65 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -86,31
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
The header is not longer used and on alpha, ia64, openrisc, parisc and um
it was completely unused anyway as these architectures have no highmem
support.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
arch/alpha/include/asm/kmap_types.h | 15 ---
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
---
V3: Remove the kmap types cruft
---
arch/xtensa/Kconfig |1
arch/xtensa/include/asm/fixmap.h |4 +--
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
V3: Remove the kmap types cruft
---
arch/mips/Kconfig |1
arch/mips/include/asm/fixmap.h |4 -
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: linux-c...@vger.kernel.org
---
V3: Does not compile with gcc 10
---
arch/csky/Kconfig |1
arch/csky/include/asm/fixmap.h |4 +-
arch/csky/include/asm/highmem.h |6 ++-
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
---
V3: Remove the kmap types cruft
---
arch/arm/Kconfig |1
arch/arm/include/asm/fixmap.h |4 -
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: Michal Simek
---
V3: Remove the kmap types cruft
---
arch/microblaze/Kconfig |1
arch/microblaze/include/asm/fixmap.h |4 -
arch/microblaze/include/asm/highmem.h |6 ++
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-dev@lists.ozlabs.org
---
V3: Remove the kmap types cruft
---
arch/powerpc/Kconfig |1
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
---
V3: Remove the kmap types cruft
---
arch/sparc/Kconfig |1
arch/sparc/include/asm/highmem.h|8 +-
The mapping code is odd and looks broken. See FIXME in the comment.
Also fix the harmless off by one in the FIX_KMAP_END define.
Signed-off-by: Thomas Gleixner
Cc: Nick Hu
Cc: Greentime Hu
Cc: Vincent Chen
---
V3: Remove the kmap types cruft
---
arch/nds32/Kconfig.cpu |1
Adopt the map ordering to match the other architectures and the generic
code. Also make the maximum entries limited and not dependend on the number
of CPUs. With the original implementation did the following calculation:
nr_slots = mapsize >> PAGE_SHIFT;
The results in either 512 or 1024
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
---
V3: Remove the kmap_types cruft
---
arch/x86/Kconfig |3 +
arch/x86/include/asm/fixmap.h
For some obscure reason when CONFIG_DEBUG_HIGHMEM is enabled the stack
depth is increased from 20 to 41. But the only thing DEBUG_HIGHMEM does is
to enable a few BUG_ON()'s in the mapping code.
That's a leftover from the historical mapping code which had fixed entries
for various purposes.
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
---
V3: Do not reuse the
kmap_types.h is a misnomer because the old atomic MAP based array does not
exist anymore and the whole indirection of architectures including
kmap_types.h is inconinstent and does not allow to provide guard page
debugging for this misfeature.
Add a common header file which defines the mapping
For whatever reasons SH has highmem bits all over the place but does
not enable it via Kconfig. Remove the bitrot.
Signed-off-by: Thomas Gleixner
---
arch/sh/include/asm/fixmap.h |8
arch/sh/include/asm/kmap_types.h | 15 ---
arch/sh/mm/init.c|
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523...@linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is
Historical leftovers from the time where kmap() had fixed slots.
Signed-off-by: Thomas Gleixner
Cc: Alexander Viro
Cc: Benjamin LaHaise
Cc: linux-fsde...@vger.kernel.org
Cc: linux-...@kvack.org
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-bt...@vger.kernel.org
---
fs/aio.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
Nothing uses totalhigh_pages_dec() and totalhigh_pages_set().
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem.h | 10 --
1 file changed, 10 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -104,21 +104,11 @@ static inline void
1 - 100 of 108 matches
Mail list logo
