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
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
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
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
Adopt the map ordering to match the other architectures and the generic
code.
Signed-off-by: Thomas Gleixner
Cc: Vineet Gupta
Cc: linux-snps-...@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
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
.
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
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
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
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,
>
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
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,
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()" (
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'
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
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
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
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)
>{
&
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
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_
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
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.
>
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
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
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
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
Signed-off-by: Thomas Gleixner
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
Note: Completely untested
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/highmem.h |6 ++-
arch/powerpc/mm/Makefile
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
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
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
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
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
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
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
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
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
Adopt the map ordering to match the other architectures and the generic
code.
Signed-off-by: Thomas Gleixner
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
---
Note: Completely untested
---
arch/arc/Kconfig |1
arch/arc/include/asm/highmem.h |8 ++-
arch/arc
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
Andy,
On Wed, Sep 02 2020 at 09:49, Andy Lutomirski wrote:
> On Wed, Sep 2, 2020 at 1:29 AM Thomas Gleixner wrote:
>>
>> But you might tell me where exactly you want to inject the SIGTRAP in
>> the syscall exit code flow.
>
> It would be a bit complicated. Defini
On Tue, Sep 01 2020 at 17:09, Andy Lutomirski wrote:
> On Tue, Sep 1, 2020 at 4:50 PM Thomas Gleixner wrote:
>> > I think that they almost work for x86, but not quite as
>> > indicated by this bug. Even if we imagine we can somehow hack around
>> > this bug, I ima
On Sun, Aug 30 2020 at 08:52, Andy Lutomirski wrote:
>> > [RUN]SYSCALL
>> > [FAIL]Initial args are wrong (nr=29, args=0 0 0 0 0 4289172732)
>> > [RUN]SYSCALL
>> > [OK]Args after SIGUSR1 are correct (ax = -514)
>> > [OK]Child got SIGUSR1
>> > [RUN]Step again
>> > [OK]
"Paul E. McKenney" writes:
> On Thu, May 21, 2020 at 02:51:24PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Tue, 19 May 2020 17:23:16 +1000 Stephen Rothwell
>> wrote:
>> >
>> > Today's linux-next merge of the rcu tree got a conflict in:
>> >
>> > arch/powerpc/kernel/traps.c
>> >
>>
of that the following updates are done:
- Add pseudo code to document the spinlock state preserving mechanism on
PREEMPT_RT
- Wordsmith the bitspinlock and lock nesting sections
Co-developed-by: Paul McKenney
Signed-off-by: Paul McKenney
Signed-off-by: Thomas Gleixner
---
Documentation/locking
Paul,
"Paul E. McKenney" writes:
> On Sat, Mar 21, 2020 at 12:25:57PM +0100, Thomas Gleixner wrote:
> In the normal case where the task sleeps through the entire lock
> acquisition, the sequence of events is as follows:
>
> state = UNINTERRUPTIBLE
>
Joel Fernandes writes:
>> +rwlock_t
>> +
>> +
>> +rwlock_t is a multiple readers and single writer lock mechanism.
>> +
>> +On a non PREEMPT_RT enabled kernel rwlock_t is implemented as a spinning
>> +lock and the suffix rules of spinlock_t apply accordingly. The
>> +implementation is
Davidlohr Bueso writes:
> On Sat, 21 Mar 2020, Thomas Gleixner wrote:
>
>>This is the third and hopefully final version of this work. The second one
>>can be found here:
>
> Would you rather I send in a separate series with the kvm changes, or
> should I just send a v
Thomas Gleixner writes:
> From: Thomas Gleixner
That's obviously bogus and wants to be:
From: Peter Zijlstra (Intel)
Guo Ren writes:
> Tested and Acked by me.
>
> Queued for next pull request, thx
Can we please route that with the rcuwait changes to avoid breakage
unless you ship it to Linus right away?
Thanks,
tglx
the config option ]
Requested-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
V2: Fix the LOCKDEP=y && LOCK_PROVE=n case
---
include/linux/irqflags.h|8 ++
include/linux/lockdep.h
From: Thomas Gleixner
completion uses a wait_queue_head_t to enqueue waiters.
wait_queue_head_t contains a spinlock_t to protect the list of waiters
which excludes it from being used in truly atomic context on a PREEMPT_RT
enabled kernel.
The spinlock in the wait queue head cannot be replaced
.
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
V3: New patch
---
arch/ia64/include/asm/uaccess.h | 1 -
arch/ia64/kernel/process.c | 1 +
arch/ia64/mm/ioremap.c
ked to expire in hard interrupt context then the timer callback is not
supposed to acquire a regular spinlock instead of a raw_spinlock in the
expiry callback.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/irqflags.h | 15 +++
include/li
quot;MicroSemi Switchtec management interface driver")
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Logan Gunthorpe
Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
Cc: Kurt Schwemmer
Cc: linux-...@vger.kernel.org
Link: https://lkml.kernel.org/r/20200313183608.2646-1-
From: Peter Zijlstra (Intel)
Extend rcuwait_wait_event() with a state variable so that it is not
restricted to UNINTERRUPTIBLE waits.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Cc: Linus Torvalds
Cc: Davidlohr Bueso
---
include/linux/rcuwait.h | 12
From: Thomas Gleixner
ep_io() uses a completion on stack and open codes the waiting with:
wait_event_interruptible (done.wait, done.done);
and
wait_event (done.wait, done.done);
This waits in non-exclusive mode for complete(), but there is no reason to
do so because the completion can only
include.
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Michal Simek
---
V3; New patch
---
arch/microblaze/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/microblaze/include/asm/uaccess.h
b/arch
irq
context so lockdep knows that these can safely acquire a spinlock_t.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/irq_work.h |2 ++
include/linux/irqflags.h | 13 +
kernel/irq_work.c|2 ++
kernel/rcu/tree.c|
From: Peter Zijlstra
In order to avoid future header hell, remove the inclusion of
proc_fs.h from acpi_bus.h. All it needs is a forward declaration of a
struct.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Cc: Darren Hart
Cc: Andy Shevchenko
Cc: platform-driver
From: Thomas Gleixner
The kernel provides a variety of locking primitives. The nesting of these
lock types and the implications of them on RT enabled kernels is nowhere
documented.
Add initial documentation.
Signed-off-by: Thomas Gleixner
Cc: "Paul E . McKenney"
Cc: Jonathan
From: Thomas Gleixner
seqlock consists of a sequence counter and a spinlock_t which is used to
serialize the writers. spinlock_t is substituted by a "sleeping" spinlock
on PREEMPT_RT enabled kernels which breaks the usage in the timekeeping
code as the writers are executed in hard
From: Thomas Gleixner
The completion usage in this driver is interesting:
- it uses a magic complete function which according to the comment was
implemented by invoking complete() four times in a row because
complete_all() was not exported at that time.
- it uses an open coded wait
From: Thomas Gleixner
As a preparation to use simple wait queues for completions:
- Provide swake_up_all_locked() to support complete_all()
- Make __prepare_to_swait() public available
This is done to enable the usage of complete() within truly atomic contexts
on a PREEMPT_RT enabled
include.
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Brian Cain
Cc: linux-hexa...@vger.kernel.org
---
V3: New patch
---
arch/hexagon/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/hexagon/include/asm
on
changing the internal implementation of completions.
Replace it with a regular wait queue and store the state in struct
switchtec_user.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Reviewed-by: Logan Gunthorpe
Acked-by: Peter Zijlstra (Intel)
Acked-by: Bjorn Helgaas
Cc
include.
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Nick Hu
Cc: Greentime Hu
Cc: Vincent Chen
---
V3: New patch
---
arch/nds32/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/nds32/include/asm/uaccess.h b
.
Reported-by: kbuild test robot
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Guo Ren
Cc: linux-c...@vger.kernel.org
---
V3: New patch
---
arch/csky/include/asm/uaccess.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/csky/include/asm/uaccess.h b/arch
From: Thomas Gleixner
The PS3 notification interrupt and kthread use a hacked up completion to
communicate. Since we're wanting to change the completion implementation and
this is abuse anyway, replace it with a simple rcuwait since there is only ever
the one waiter.
AFAICT the kthread uses
This is the third and hopefully final version of this work. The second one
can be found here:
https://lore.kernel.org/r/20200318204302.693307...@linutronix.de
Changes since V2:
- Included the arch/XXX fixups for the rcuwait changes (Sebastian)
- Folded the init fix for the PS3 change
k is
acquried. This will be removed once the split is completed.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/irqflags.h | 12
kernel/time/posix-cpu-timers.c |6 +-
2 files changed, 17 insertions(+), 1 deletion(-)
--- a/
Christoph Hellwig writes:
> On Wed, Mar 18, 2020 at 09:43:09PM +0100, Thomas Gleixner wrote:
>> The PS3 notification interrupt and kthread use a hacked up completion to
>> communicate. Since we're wanting to change the completion implementation and
>> this is
"Paul E. McKenney" writes:
> On Fri, Mar 20, 2020 at 11:36:03PM +0100, Thomas Gleixner wrote:
>> I agree that what I tried to express is hard to parse, but it's at least
>> halfways correct :)
>
> Apologies! That is what I get for not looking it up in the sour
"Paul E. McKenney" writes:
> On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
>> "Paul E. McKenney" writes:
>> >
>> > - The soft interrupt related suffix (_bh()) still disables softirq
>> >handlers. However, unlike
"Paul E. McKenney" writes:
>
> - The soft interrupt related suffix (_bh()) still disables softirq
>handlers. However, unlike non-PREEMPT_RT kernels (which disable
>preemption to get this effect), PREEMPT_RT kernels use a per-CPU
>lock to exclude softirq handlers.
I've made that:
Borislav Petkov writes:
> On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
>> TBH, I don't see how
>>
>> if (force_dma_decrypted(dev))
>> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
>>
>> m
Jonathan Corbet writes:
> On Wed, 18 Mar 2020 21:43:10 +0100
> Thomas Gleixner wrote:
>> Add initial documentation.
>
> ...time to add a a couple of nits...:)
...time
Is that valid RST?
>> +++ b/Documentation/locking/locktypes.rst
>> @@ -0,0 +1,298 @@
&g
Paul,
"Paul E. McKenney" writes:
> On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
>
> Mostly native-English-speaker services below, so please feel free to
> ignore. The one place I made a substantive change, I marked it "@@@".
> I o
Borislav Petkov writes:
> On Thu, Mar 19, 2020 at 11:06:15AM +, Robin Murphy wrote:
>> Let me add another vote from a native English speaker that "unencrypted" is
>> the appropriate term to imply the *absence* of encryption, whereas
>> "decrypted" implies the *reversal* of applied
Joel,
Joel Fernandes writes:
> On Wed, Mar 18, 2020 at 09:43:13PM +0100, Thomas Gleixner wrote:
>> The spinlock in the wait queue head cannot be replaced by a raw_spinlock
>> because:
>>
>> - wait queues can have custom wakeup callbacks, which acquire other
>&
From: Thomas Gleixner
completion uses a wait_queue_head_t to enqueue waiters.
wait_queue_head_t contains a spinlock_t to protect the list of waiters
which excludes it from being used in truly atomic context on a PREEMPT_RT
enabled kernel.
The spinlock in the wait queue head cannot be replaced
From: Thomas Gleixner
As a preparation to use simple wait queues for completions:
- Provide swake_up_all_locked() to support complete_all()
- Make __prepare_to_swait() public available
This is done to enable the usage of complete() within truly atomic contexts
on a PREEMPT_RT enabled
From: Thomas Gleixner
The kernel provides a variety of locking primitives. The nesting of these
lock types and the implications of them on RT enabled kernels is nowhere
documented.
Add initial documentation.
Signed-off-by: Thomas Gleixner
---
V2: Addressed review comments from Randy
for by the task itself and
complete() wakes exactly one exlusive waiter.
Replace the open coded implementation with the corresponding
wait_for_completion*() functions.
No functional change.
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc
In order to avoid future header hell, remove the inclusion of
proc_fs.h from acpi_bus.h. All it needs is a forward declaration of a
struct.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
---
drivers/platform/x86/dell-smo8800.c |1 +
drivers
From: Sebastian Andrzej Siewior
The poll callback is using the completion wait queue and sticks it into
poll_wait() to wake up pollers after a command has completed.
This works to some extent, but cannot provide EPOLLEXCLUSIVE support
because the waker side uses complete_all() which
From: Thomas Gleixner
The completion usage in this driver is interesting:
- it uses a magic complete function which according to the comment was
implemented by invoking complete() four times in a row because
complete_all() was not exported at that time.
- it uses an open coded wait
From: Thomas Gleixner
seqlock consists of a sequence counter and a spinlock_t which is used to
serialize the writers. spinlock_t is substituted by a "sleeping" spinlock
on PREEMPT_RT enabled kernels which breaks the usage in the timekeeping
code as the writers are executed in hard
Extend rcuwait_wait_event() with a state variable so that it is not
restricted to UNINTERRUPTIBLE waits.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Cc: Oleg Nesterov
Cc: Davidlohr Bueso
---
include/linux/rcuwait.h | 12 ++--
kernel/locking/percpu
This is the second version of this work. The first one can be found here:
https://lore.kernel.org/r/20200313174701.148376-1-bige...@linutronix.de
Changes since V1:
- Split the PCI/switchtec patch (picked up the fix from Logan) and
reworked the change log.
- Addressed Linus feedback
The PS3 notification interrupt and kthread use a hacked up completion to
communicate. Since we're wanting to change the completion implementation and
this is abuse anyway, replace it with a simple rcuwait since there is only ever
the one waiter.
AFAICT the kthread uses TASK_INTERRUPTIBLE to not
quot;MicroSemi Switchtec management interface driver")
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Logan Gunthorpe
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r/20200313183608.2646-1-log...@deltatee.com
---
drivers/pci/switch/switchtec.c | 2 +-
1 file changed
Borislav Petkov writes:
> On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
>> On 3/17/20 4:18 AM, Borislav Petkov wrote:
>> > Back then when the whole SME machinery started getting mainlined, it
>> > was agreed that for simplicity, clarity and sanity's sake, the terms
>> > denoting
Afzal,
afzal mohammed writes:
> While trying to understand internals of irq handling, came across a
> thread [1] in which tglx was referring to avoid usage of setup_irq().
> Existing callers of setup_irq() reached mostly via 'init_IRQ()' &
> 'time_init()', while memory allocators are ready by
Alexey Budankov writes:
> On 22.01.2020 17:25, Alexey Budankov wrote:
>> On 22.01.2020 17:07, Stephen Smalley wrote:
It keeps the implementation simple and readable. The implementation is more
performant in the sense of calling the API - one capable() call for
CAP_PERFMON
Andy Lutomirski writes:
> On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote:
>>
>> Andy Lutomirski writes:
>> > On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
>> >
>> > Would mul_u64_u64_shr() be a good alternative? Could we adjust i
Andy Lutomirski writes:
> On Thu, Jan 16, 2020 at 12:14 PM Thomas Gleixner wrote:
>> Some architectures have a fixed clocksource which is known at compile
>> time and cannot be replaced or disabled at runtime, e.g. timebase on
>> PowerPC. For such cases the clock mode c
Christophe Leroy writes:
Can you please adjust the prefix for future patches to lib/vdso: and
start the sentence after the colon with an uppercase letter?
> On arches like POWERPC, the clock is always the timebase, it
Please spell out architectures. Changelogs are not space constraint.
>
Andy Lutomirski writes:
> On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
>
> Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
> assume the shift is less than 32? That function exists to benefit
> 32-bit arches.
We'd want mul_u64_u32_shr() for this. The rules for mult and
Hsin-Yi Wang writes:
> On Thu, Jan 16, 2020 at 8:30 AM Thomas Gleixner wrote:
> We saw this issue on regular reboot (not panic) on arm64: If tick
> broadcast and smp_send_stop() happen together and the first broadcast
> arrives to some idled CPU that hasn't already executed reboot
Christophe Leroy writes:
> Le 15/01/2020 à 07:15, Christophe Leroy a écrit :
> From your point of view, what should I do:
> A/ __arch_get_vdso_data() handled entirely at arch level and arches
> handing over the vdso data pointer to generic C VDSO functions all the
> time (as in my v2 series) ?
301 - 400 of 766 matches
Mail list logo
