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

2020-09-24 Thread Thomas Gleixner
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

2020-09-24 Thread Thomas Gleixner
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

2020-09-23 Thread Thomas Gleixner
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

2020-09-23 Thread Thomas Gleixner
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

2020-09-23 Thread Thomas Gleixner
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

2020-09-23 Thread Thomas Gleixner
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

2020-09-21 Thread Thomas Gleixner
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

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

2020-09-21 Thread Thomas Gleixner
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 RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Thomas Gleixner
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

2020-09-20 Thread Thomas Gleixner
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

2020-09-20 Thread Thomas Gleixner
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

2020-09-20 Thread Thomas Gleixner
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

2020-09-20 Thread Thomas Gleixner
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. >

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

2020-09-19 Thread Thomas Gleixner
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 07/15] microblaze/mm/highmem: Switch to generic kmap atomic

2020-09-19 Thread Thomas Gleixner
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

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

2020-09-19 Thread Thomas Gleixner
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 09/15] nds32/mm/highmem: Switch to generic kmap atomic

2020-09-19 Thread Thomas Gleixner
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 15/15] mm/highmem: Provide kmap_temporary*

2020-09-19 Thread Thomas Gleixner
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

2020-09-19 Thread Thomas Gleixner
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 14/15] sched: highmem: Store temporary kmaps in task struct

2020-09-19 Thread Thomas Gleixner
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 12/15] xtensa/mm/highmem: Switch to generic kmap atomic

2020-09-19 Thread Thomas Gleixner
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 10/15] powerpc/mm/highmem: Switch to generic kmap atomic

2020-09-19 Thread Thomas Gleixner
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 02/15] highmem: Provide generic variant of kmap_atomic*

2020-09-19 Thread Thomas Gleixner
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 06/15] csky/mm/highmem: Switch to generic kmap atomic

2020-09-19 Thread Thomas Gleixner
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 05/15] ARM: highmem: Switch to generic kmap atomic

2020-09-19 Thread Thomas Gleixner
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 03/15] x86/mm/highmem: Use generic kmap atomic implementation

2020-09-19 Thread Thomas Gleixner
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

2020-09-19 Thread Thomas Gleixner
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 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-19 Thread Thomas Gleixner
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 01/15] mm/highmem: Un-EXPORT __kmap_atomic_idx()

2020-09-19 Thread Thomas Gleixner
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

Re: [PATCH 08/21] x86: Clean up ioremap()

2019-10-30 Thread Thomas Gleixner
On Tue, 29 Oct 2019, Christoph Hellwig wrote: > Use ioremap() as the main implemented function, and defines > ioremap_nocache() as a deprecated alias of ioremap() in > preparation of removing ioremap_nocache() entirely. > > Signed-off-by: Christoph Hellwig Reviewed-by:

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

2019-10-21 Thread Thomas Gleixner
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 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

2019-04-04 Thread Thomas Gleixner
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

2019-04-04 Thread Thomas Gleixner
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] devres: Really align data field to unsigned long long

2018-07-06 Thread Thomas Gleixner
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 v3 03/11] ARC: Allow irq threading

2017-08-25 Thread Thomas Gleixner
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 v3 03/11] ARC: Allow irq threading

2017-08-25 Thread Thomas Gleixner
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 v2 1/1] futex: remove duplicated code and fix UB

2017-08-25 Thread Thomas Gleixner
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 1/1] futex: remove duplicated code and fix UB

2017-07-03 Thread Thomas Gleixner
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 1/1] futex: remove duplicated code and fix UB

2017-06-23 Thread Thomas Gleixner
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 V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

2017-06-20 Thread Thomas Gleixner
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 V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

2017-06-20 Thread Thomas Gleixner
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 1/1] futex: remove duplicated code

2017-05-22 Thread Thomas Gleixner
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: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Thomas Gleixner
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: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Thomas Gleixner
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: update timer frequencies

2017-03-10 Thread Thomas Gleixner
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] irqchip: nps: add 64BIT dependency

2016-05-17 Thread Thomas Gleixner
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: [PATCH v2 3/3] irqchip: add nps Internal and external irqchips

2016-02-02 Thread Thomas Gleixner
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