Re: [PATCH v2 3/3] irqchip: add nps Internal and external irqchips

On Tue, 2 Feb 2016, Noam Camus wrote: > +#include > +#include > +#include > +#include > +#include > +#include > + > +#undef NR_CPU_IRQS What's that #undef for? > +#define NR_CPU_IRQS 8 /* number of interrupt lines of NPS400 CPU */ > +#define TIMER0_IRQ 3 > +static void

Re: [PATCH] irqchip: nps: add 64BIT dependency

On Fri, 13 May 2016, Vineet Gupta wrote: > On Friday 13 May 2016 03:55 PM, Marc Zyngier wrote: > > On 13/05/16 10:51, Arnd Bergmann wrote: > >> On Friday 13 May 2016 14:05:41 Vineet Gupta wrote: > >>> On Friday 13 May 2016 01:54 PM, Marc Zyngier wrote: > On 12/05/16 22:03, Arnd Bergmann

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Wed, 15 Mar 2017, Till Smejkal wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > > VAS segments on the other side would provide a functionality to > > > achieve the same without the need of any mounted filesystem. However, > > > I agree, that this is just a small advantage compared to

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Thu, 16 Mar 2017, Till Smejkal wrote: > On Thu, 16 Mar 2017, Thomas Gleixner wrote: > > Why do we need yet another mechanism to represent something which looks > > like a file instead of simply using existing mechanisms and extend them? > > You are right. I a

Re: update timer frequencies

Vlad, On Fri, 10 Mar 2017, Vlad Zakharov wrote: > > I am trying to implement a cpufreq driver for ARC CPUs. The point is > that ARC timers (including those are used for timekeeping) are driven by > the same clock as ARC CPU core(s). To be honest: That's broken by design and you really should

Re: [PATCH 1/1] futex: remove duplicated code and fix UB

On Mon, 26 Jun 2017, Jiri Slaby wrote: > On 06/23/2017, 09:51 AM, Thomas Gleixner wrote: > > On Wed, 21 Jun 2017, Jiri Slaby wrote: > >> diff --git a/arch/arm64/include/asm/futex.h > >> b/arch/arm64/include/asm/futex.h > >> index f32b42e8725d..5bb2fd4674e7 1006

Re: [PATCH V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Mon, 12 Jun 2017, Daniel Lezcano wrote: > But, the API request_percpu_irq does not allow to pass a flag, hence > specifying > if the interrupt type is a timer. > > Add a function request_percpu_irq_flags() where we can specify the flags. The > request_percpu_irq() function is changed to be a

Re: [PATCH V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Tue, 20 Jun 2017, Daniel Lezcano wrote: > On Tue, Jun 20, 2017 at 04:05:07PM +0200, Thomas Gleixner wrote: > > On Mon, 12 Jun 2017, Daniel Lezcano wrote: > > > But, the API request_percpu_irq does not allow to pass a flag, hence > > > specifying > > &

Re: [PATCH 1/1] futex: remove duplicated code and fix UB

On Wed, 21 Jun 2017, Jiri Slaby wrote: > diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h > index f32b42e8725d..5bb2fd4674e7 100644 > --- a/arch/arm64/include/asm/futex.h > +++ b/arch/arm64/include/asm/futex.h > @@ -48,20 +48,10 @@ do {

Re: [PATCH 1/1] futex: remove duplicated code

On Mon, 15 May 2017, Will Deacon wrote: > Hi Jiri, > > On Mon, May 15, 2017 at 03:07:42PM +0200, Jiri Slaby wrote: > > There is code duplicated over all architecture's headers for > > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr, > > and comparison of the result. > > > >

Re: [PATCH v3 03/11] ARC: Allow irq threading

On Fri, 25 Aug 2017, Thomas Gleixner wrote: > On Fri, 25 Aug 2017, Vineet Gupta wrote: > > On 06/15/2017 01:43 AM, Noam Camus wrote: > > > From: Noam Camus <no...@ezchip.com> > > > > > > Working with NPS400 we noticed that there is a possibility of L

Re: [PATCH v2 1/1] futex: remove duplicated code and fix UB

On Thu, 24 Aug 2017, Will Deacon wrote: > On Thu, Aug 24, 2017 at 09:31:05AM +0200, Jiri Slaby wrote: > > +static int futex_atomic_op_inuser(unsigned int encoded_op, u32 __user > > *uaddr) > > +{ > > + unsigned int op = (encoded_op & 0x7000) >> 28; > > + unsigned int cmp =

Re: [PATCH v3 03/11] ARC: Allow irq threading

On Fri, 25 Aug 2017, Vineet Gupta wrote: > On 06/15/2017 01:43 AM, Noam Camus wrote: > > From: Noam Camus > > > > Working with NPS400 we noticed that there is a possibility of L1 > > interrupt nesting that may run out kernel stack. > > The scenario include serving

Re: [PATCH] devres: Really align data field to unsigned long long

On Fri, 6 Jul 2018, Alexey Brodkin wrote: > It looks like on most of architectures "data" member of devres struture > gets aligned to 8-byte "unsigned long long" boundary as one may expect: > if we don't explicitly pack a structure then natural alignment > (which matches each member data type) is

Re: [PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

l_set_arguments(). But we are told that > there will be soon. But for now, at least make it consistent with > syscall_get_arguments(). > > Link: http://lkml.kernel.org/r/20190327222014.ga32...@altlinux.org For x86: Reviewed-by: Thomas Gleixner __

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

ver used, simply rewrite it to return the first 6 > arguments of a system call. > > This should help out the performance of tracing system calls by ptrace, > ftrace and perf. > > Link: http://lkml.kernel.org/r/20161107213233.754809

Re: [PATCH 08/21] x86: clean up ioremap

On Thu, 17 Oct 2019, Christoph Hellwig wrote: Please change the subject to: x86/mm: Cleanup ioremap() > Use ioremap as the main implemented function, and defined ioremap() please s/defined/define/ > ioremap_nocache to it as a deprecated alias. ioremap_nocache() as a deprecated alias

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, Sep 23 2020 at 12:19, peterz wrote: > On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote: >> Alternatively this could of course be solved with per CPU page tables >> which will come around some day anyway I fear. > > Previously (with PTI) we looked at mak

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, Sep 23 2020 at 10:40, peterz wrote: > Right, so I'm concerned. migrate_disable() wrecks pretty much all > Real-Time scheduler theory we have, and PREEMPRT_RT bringing it in is > somewhat ironic. It's even more ironic that the approach of PREEMPT_RT has been 'pragmatic ignorance of theory'

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Mon, Sep 21 2020 at 21:27, Thomas Gleixner wrote: > On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote: >> On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: >> Maybe we really *could* call this new kmap functionality something >> like "kmap_percpu()" (

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, Sep 23 2020 at 11:52, Steven Rostedt wrote: > On Wed, 23 Sep 2020 10:40:32 +0200 > pet...@infradead.org wrote: > >> However, with migrate_disable() we can have each task preempted in a >> migrate_disable() region, worse we can stack them all on the _same_ CPU >> (super ridiculous odds,

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, Sep 23 2020 at 17:12, Steven Rostedt wrote: > On Wed, 23 Sep 2020 22:55:54 +0200 > Then scratch the idea of having anonymous local_lock() and just bring > local_lock in directly? Then have a kmap local lock, which would only > block those that need to do a kmap. That's still going to end

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > On Thu, 24 Sep 2020 08:57:52 +0200 > Thomas Gleixner wrote: > >> > Now as for migration disabled nesting, at least now we would have >> > groupings of this, and perhaps the theorists can handle that. I mean, >

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote: > On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: >> >> If a task is migrated to a different CPU then the mapping address will >> change which will explode in colourful ways. > > Right you are. > > Mayb

[patch RFC 12/15] xtensa/mm/highmem: Switch to generic kmap atomic

Signed-off-by: Thomas Gleixner Cc: Chris Zankel Cc: Max Filippov Cc: linux-xte...@linux-xtensa.org --- Note: Completely untested --- arch/xtensa/Kconfig |1 arch/xtensa/include/asm/highmem.h |9 +++ arch/xtensa/mm/highmem.c | 44

[patch RFC 14/15] sched: highmem: Store temporary kmaps in task struct

Instead of storing the map per CPU provide and use per task storage. That prepares for temporary 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. Signed-off-by: Thomas

[patch RFC 08/15] mips/mm/highmem: Switch to generic kmap atomic

Signed-off-by: Thomas Gleixner Cc: Thomas Bogendoerfer Cc: linux-m...@vger.kernel.org --- Note: Completely untested --- arch/mips/Kconfig |1 arch/mips/include/asm/highmem.h |4 +- arch/mips/mm/highmem.c | 77 arch/mips

[patch RFC 13/15] mm/highmem: Remove the old kmap_atomic cruft

Signed-off-by: Thomas Gleixner --- include/linux/highmem.h | 65 ++-- mm/highmem.c| 28 +--- 2 files changed, 28 insertions(+), 65 deletions(-) --- a/include/linux/highmem.h +++ b/include/linux/highmem.h @@ -94,27 +94,6

[patch RFC 15/15] mm/highmem: Provide kmap_temporary*

be invoked from both preemptible and atomic context. 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 per CPUness. Needs to be done on a case by case basis. Signed-off-by: Thomas

[patch RFC 11/15] sparc/mm/highmem: Switch to generic kmap atomic

Signed-off-by: Thomas Gleixner Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org --- Note: Completely untested --- arch/sparc/Kconfig |1 arch/sparc/include/asm/highmem.h |7 +- arch/sparc/mm/Makefile |3 - arch/sparc/mm/highmem.c

[patch RFC 02/15] 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 --- include/linux/highmem.h | 87 --- mm

[patch RFC 10/15] powerpc/mm/highmem: Switch to generic kmap atomic

Signed-off-by: Thomas Gleixner Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-...@lists.ozlabs.org --- Note: Completely untested --- arch/powerpc/Kconfig |1 arch/powerpc/include/asm/highmem.h |6 ++- arch/powerpc/mm/Makefile

[patch RFC 06/15] csky/mm/highmem: Switch to generic kmap atomic

Signed-off-by: Thomas Gleixner Cc: Guo Ren Cc: linux-c...@vger.kernel.org --- Note: Completely untested --- arch/csky/Kconfig |1 arch/csky/include/asm/highmem.h |4 +- arch/csky/mm/highmem.c | 75 3 files changed, 5

[patch RFC 03/15] x86/mm/highmem: Use generic kmap atomic implementation

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

[patch RFC 04/15] 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 --- Note: Completely untested --- arch/arc/Kconfig |1 arch/arc/include/asm/highmem.h |8 ++- arch/arc

[patch RFC 05/15] ARM: highmem: Switch to generic kmap atomic

Signed-off-by: Thomas Gleixner Cc: Russell King Cc: Arnd Bergmann Cc: linux-arm-ker...@lists.infradead.org --- Note: Completely untested --- arch/arm/Kconfig |1 arch/arm/include/asm/highmem.h | 30 +++--- arch/arm/mm/Makefile |1 arch/arm/mm/highmem.c

[patch RFC 01/15] mm/highmem: Un-EXPORT __kmap_atomic_idx()

Nothing in modules can use that. Signed-off-by: Thomas Gleixner --- 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 atomic_long_t _totalhigh_pages __read_mostly; EXPORT_SYMBOL

[patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

First of all, sorry for the horribly big Cc list! Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266...@linutronix.de this provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Consolidating all kmap atomic implementations

[patch RFC 09/15] 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 --- Note: Completely untested --- arch/nds32/Kconfig.cpu |1 arch/nds32/include/asm/highmem.h | 21 + arch/nds32

[patch RFC 07/15] microblaze/mm/highmem: Switch to generic kmap atomic

Signed-off-by: Thomas Gleixner Cc: Michal Simek --- Note: Completely untested --- arch/microblaze/Kconfig |1 arch/microblaze/include/asm/highmem.h |6 ++ arch/microblaze/mm/Makefile |1 arch/microblaze/mm/highmem.c | 78

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sat, Sep 19 2020 at 10:18, Linus Torvalds wrote: > On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote: >> >> this provides a preemptible variant of kmap_atomic & related >> interfaces. This is achieved by: > > Ack. This looks really nice, even apart from t

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20 2020 at 08:41, Thomas Gleixner wrote: > On Sat, Sep 19 2020 at 10:18, Linus Torvalds wrote: >> Maybe I've missed something. Is it because the new interface still >> does "pagefault_disable()" perhaps? >> >> But does it even need the pagefault_

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote: > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote: >> I think it should be the case, but I want to double check: Will >> copy_*_user be allowed within a kmap_temporary section? This would >> allow us to ditch an absolute pile of slowpaths. >

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20 2020 at 10:23, Daniel Vetter wrote: > On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote: >> On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote: >> > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote: >> >> I think it should be the ca

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20 2020 at 09:57, Linus Torvalds wrote: > On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote: > Btw, looking at the stack code, Ithink your new implementation of it > is a bit scary: > >static inline int kmap_atomic_idx_push(void) >{ &

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20 2020 at 10:42, Linus Torvalds wrote: > On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote: >> >> I think the more obvious solution is to split the whole exercise: >> >> schedule() >> prepare_switch() >> unmap() >&g

Re: [patch V3 10/37] ARM: highmem: Switch to generic kmap atomic

Marek, On Thu, Nov 12 2020 at 09:10, Marek Szyprowski wrote: > On 03.11.2020 10:27, Thomas Gleixner wrote: > > I can do more tests to help fixing this issue. Just let me know what to do. Just sent out the fix before I saw your report. https://lore.kernel.org/r/8

[patch V3 25/37] mm/highmem: Provide kmap_local*

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 --- V3: Move migrate disable into the actual highmem mapping code so it only affects real highmem mappings. V2: Make it more consistent

[patch V3 09/37] arc/mm/highmem: Use generic kmap atomic implementation

ot fit. Randomly failing at runtime is not a really good option. Signed-off-by: Thomas Gleixner Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org --- V3: Make it actually more correct. --- arch/arc/Kconfig |1 arch/arc/include/asm/highmem.h| 26 ++

[patch V3 21/37] Documentation/io-mapping: Remove outdated blurb

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(-) --- a/Documentation/driver-api/io

[patch V3 14/37] nds32/mm/highmem: Switch to generic kmap atomic

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

[patch V3 20/37] 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 V3 06/37] 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 --- V3: Do not reuse

[patch V3 17/37] 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 --- V3: Remove the kmap types cruft --- arch/xtensa/Kconfig |1 arch/xtensa/include/asm/fixmap.h |4 +-- arch/xtensa

[patch V3 08/37] 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 --- V3: Remove the kmap_types cruft --- arch/x86/Kconfig |3 + arch/x86/include/asm/fixmap.h

[patch V3 16/37] 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 --- V3: Remove the kmap types cruft --- arch/sparc/Kconfig |1 arch/sparc/include/asm/highmem.h|8 +- arch/sparc/i

[patch V3 12/37] 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 --- V3: Remove the kmap types cruft --- arch/microblaze/Kconfig |1 arch/microblaze/include/asm/fixmap.h |4 - arch/microblaze/include/asm/highmem.h |6 ++ arch

[patch V3 37/37] io-mapping: Remove io_mapping_map_atomic_wc()

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

[patch V3 19/37] mm/highmem: Remove the old kmap_atomic cruft

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

[patch V3 11/37] csky/mm/highmem: Switch to generic kmap atomic

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 ++- arch/csky

[patch V3 10/37] 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 --- V3: Remove the kmap types cruft --- arch/arm/Kconfig |1 arch/arm/include/asm/fixmap.h |4 - arch

[patch V3 13/37] 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 --- V3: Remove the kmap types cruft --- arch/mips/Kconfig |1 arch/mips/include/asm/fixmap.h |4 - arch/mips/include/asm

[patch V3 31/37] drm/ttm: Replace kmap_atomic() usage

pages and the return was bogus anyway as it would have left preemption and pagefaults disabled. Signed-off-by: Thomas Gleixner Cc: Christian Koenig Cc: Huang Rui Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org --- V3: New patch --- drivers/gpu/drm/ttm/ttm_bo_util.c

[patch V3 34/37] drm/qxl: Replace io_mapping_map_atomic_wc()

-off-by: Thomas Gleixner Cc: Dave Airlie Cc: Gerd Hoffmann Cc: David Airlie Cc: Daniel Vetter Cc: virtualizat...@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org --- V3: New patch --- drivers/gpu/drm/qxl/qxl_image.c | 18 +- drivers/gpu/drm/qxl/qxl_ioctl.c

[patch V3 30/37] highmem: Remove kmap_atomic_pfn()

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

[patch V3 28/37] mips/crashdump: Simplify copy_oldmem_page()

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

[patch V3 27/37] x86/crashdump/32: Simplify copy_oldmem_page()

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

[patch V3 22/37] highmem: High implementation details and document API

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 |

[patch V3 32/37] drm/vmgfx: Replace kmap_atomic()

pages and the return was bogus anyway as it would have left preemption and pagefaults disabled. Signed-off-by: Thomas Gleixner Cc: VMware Graphics Cc: Roland Scheidegger Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org --- V3: New patch --- drivers/gpu/drm/vmwgfx

[patch V3 36/37] drm/i915: Replace io_mapping_map_atomic_wc()

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

[patch V3 00/37] 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 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

[patch V3 04/37] sh/highmem: Remove all traces of unused cruft

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

[patch V3 03/37] fs: Remove asm/kmap_types.h includes

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

[patch V3 35/37] drm/nouveau/device: Replace io_mapping_map_atomic_wc()

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

[patch V3 02/37] highmem: Remove unused functions

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

[patch V3 05/37] asm-generic: Provide kmap_size.h

nesting for the upcoming reemptible version would be: 2 maps in task context and a fault inside 2 maps in the fault handler 3 maps in softirq 2 maps in interrupt So a total of 16 is sufficient and probably overestimated. Signed-off-by: Thomas Gleixner --- V3: New patch

[patch V3 15/37] 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 --- V3: Remove the kmap types cruft --- arch/powerpc/Kconfig |1 arch/powerpc/include

[patch V3 29/37] ARM: mm: Replace kmap_atomic_pfn()

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

[patch V3 07/37] highmem: Make DEBUG_HIGHMEM functional

to the generic kmap_local* implementation. Signed-off-by: Thomas Gleixner --- V3: New patch --- mm/highmem.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/mm/highmem.c +++ b/mm/highmem.c @@ -374,9 +374,19 @@ EXPORT_SYMBOL(kunmap_high); static DEFINE_PER_CPU(int

[patch V3 26/37] 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 --- V3: Restrict migrate disable to the 32bit mapping case and update documentation. V2: Split out from the large combo patch and add

[patch V3 18/37] highmem: Get rid of kmap_types.h

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 --- arch/ia64/include/asm

[patch V3 33/37] highmem: Remove kmap_atomic_prot()

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

[patch V3 23/37] sched: Make migrate_disable/enable() independent of RT

. Making it available independent of RT allows to provide a preemptible variant of kmap_atomic() and makes the code more consistent in general. FIXME: Rework the comment in preempt.h Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar

[patch V3 24/37] sched: highmem: Store local kmaps in task struct

. Going back to user space with an active kmap local is a nono. Signed-off-by: Thomas Gleixner --- V3: Handle the debug case correctly --- include/linux/highmem-internal.h | 10 +++ include/linux/sched.h|9 +++ kernel/entry/common.c|2 kernel/fork.c

[patch V3 01/37] 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

Re: [patch V3 24/37] sched: highmem: Store local kmaps in task struct

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

[patch V4 24/37] sched: highmem: Store local kmaps in task struct

. Going back to user space with an active kmap local is a nono. Signed-off-by: Thomas Gleixner --- V4: Use the version which actually compiles and works V3: Handle the debug case correctly --- include/linux/highmem-internal.h | 10 +++ include/linux/sched.h|9 +++ kernel/entry

Re: [patch V3 22/37] highmem: High implementation details and document API

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,

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

On Fri, Oct 30 2020 at 08:25, Christoph Hellwig wrote: > On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote: >> - Consolidating all kmap atomic implementations in generic code > > I think the consolidation is a winner no matter where we go next. Maybe > split it ou

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

On Fri, Oct 30 2020 at 00:41, Thomas Gleixner wrote: > On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote: > No, you're not misreading it, but doing it conditionally would be a > complete semantical disaster. kmap_atomic*() also disables preemption > and pagefaults un

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

On Fri, Oct 30 2020 at 13:06, Matthew Wilcox wrote: > On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote: >> This series provides kmap_local.* iomap_local variants which only disable >> migration to keep the virtual mapping address stable accross preemption, >> b

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

On Fri, Oct 30 2020 at 13:28, Linus Torvalds wrote: > On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote: >> >> But then we really should not name it kmap_local. 'local' suggests >> locality, think local_irq*, local_bh* ... kmap_task would be more >> accurate then.

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

On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote: > On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote: > To me, your patch series has two big advantages: > > - more common code > > - kmap_local() becomes more of a no-op > > and the last thing we want is to expa

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

On Sat, Oct 31 2020 at 00:26, Thomas Gleixner wrote: > On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote: >> On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote: >> To me, your patch series has two big advantages: >> >> - more common code >> >>

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

On Thu, Oct 29 2020 at 23:18, Thomas Gleixner wrote: > > There is also a still to be investigated question from Linus on the initial > posting versus the per cpu / per task mapping stack depth which might need > to be made larger due to the ability to take page faults within a mapping

[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 +++ b/arch/arm

[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 +++ b/arch/nds32

[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

  1   2   >