On Fri, Mar 19 2021 at 21:50, Tony Luck wrote:
>> What is the justifucation for making this rate limit per UID and not
>> per task, per process or systemwide?
>
> The concern is that a malicious user is running a workload that loops
> obtaining the buslock. This brings the whole system to its
On Fri, Mar 12 2021 at 10:20, Johan Hovold wrote:
> arch/x86/kernel/apic/apic.c | 5 +
> 1 file changed, 5 insertions(+)
>
> It's been over three months so resending.
Sorry, was probably lost in my post X-mas mark all mails read habit.
> Can someone please pick this up for 5.12 or -next?
On Sat, Mar 13 2021 at 05:49, Fenghua Yu wrote:
> + ratelimit:N -
> + Set rate limit to N bus locks per second
> + for bus lock detection. 0 < N.
> + Only applied to non-root users.
Of
On Sat, Mar 13 2021 at 05:49, Fenghua Yu wrote:
> Change Log:
> v5:
> Address all comments from Thomas:
> - Merge patch 2 and patch 3 into one patch so all "split_lock_detect="
> options are processed in one patch.
What? I certainly did not request that. I said:
"Why is this seperate and an
On Sat, Mar 13 2021 at 05:49, Fenghua Yu wrote:
> A bus lock is acquired though either split locked access to
s/though/through/
either a
> writeback (WB) memory or any locked access to non-WB memory. This is
> typically >1000 cycles slower than an atomic operation within a cache
> line. It also
On Fri, Mar 19 2021 at 17:17, Thomas Gleixner wrote:
> On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
>> +
>> +#define DEBUG_ENTRY_WARN_ONCE(condition, format...) do {} while (0)
>
> So we have a stub for !DEBUG
>
>> +static __always_inline void kentr
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> -/**
> - * exit_to_user_mode - Fixup state when exiting to user mode
> - *
> - * Syscall/interrupt exit enables interrupts, but the kernel state is
> - * interrupts disabled when this is invoked. Also tell RCU about it.
> - *
> - * 1) Trace
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> @@ -119,31 +119,12 @@ static inline __must_check int
> arch_syscall_enter_tracehook(struct pt_regs *regs
> void enter_from_user_mode(struct pt_regs *regs);
>
> /**
> + * kentry_syscall_begin - Prepare to invoke a syscall handler
> *
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> +
> +#define DEBUG_ENTRY_WARN_ONCE(condition, format...) do {} while (0)
So we have a stub for !DEBUG
> +static __always_inline void kentry_cpu_depth_add(unsigned int n) {}
> +static void kentry_cpu_depth_check(unsigned int n) {}
> +static
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> The new common syscall API had a large and confusing API surface. Simplify
> it. Now there is exactly one way to use it. It's a bit more verbose than
> the old way for the simple x86_64 native case, but it's much easier to use
> right,
and
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> ret_from_fork is written in asm, slightly differently, for x86_32 and
> x86_64. Convert it to C.
> +__visible void noinstr ret_from_fork(struct task_struct *prev,
> + int (*kernel_thread_fn)(void *),
> +
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: a501b048a95b79e1e34f03cac3c87ff1e9f229ad
Gitweb:
https://git.kernel.org/tip/a501b048a95b79e1e34f03cac3c87ff1e9f229ad
Author:Thomas Gleixner
AuthorDate:Thu, 18 Mar 2021 20:26:47 +01:00
g used.
>
> Change the configuration check to be correct.
>
> [1] https://lore.kernel.org/lkml/20210304083825.GB17830@xsang-OptiPlex-9020/
>
> Cc: Thomas Gleixner
> Cc: Oliver Sang
> Cc: Chaitanya Kulkarni
> Cc: David Sterba
> Cc: Andrew Mor
and treat it as non existent despite a routing entry claiming
otherwise.
Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain
interfaces")
Reported-by: Vitaly Kuznetsov
Signed-off-by: Thomas Gleixner
Tested-by: Vitaly Kuznetsov
Cc: sta...@vger.kernel.org
Link: htt
On Thu, Mar 18 2021 at 08:58, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>> There is a way more useful way to handle this. In such a case the bit is
>> NOT set in the alloc map. So:
>>
>> if (!WARN_ON_ONCE(test_and_clear_bit(bit, cm->alloc_map)))
>&
To prevent another incidental removal of the IRQ2 ignore logic in the
IO/APIC code going unnoticed add a sanity check. Add some commentry at the
other place which ignores IRQ2 while at it.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/vector.c | 13 +
1 file changed, 13
Cure for the IRQ2 ignore logic which got lost during the irqdomain
conversion and a related sanity check.
Thanks,
tglx
Manish,
On Mon, Mar 01 2021 at 19:49, Manish Varma wrote:
> All together, that will give us names like the following:
>
> 1) timerfd file descriptor: [timerfd14:system_server]
> 2) eventpoll top-level per-process wakesource: epoll:system_server
> 3) eventpoll-on-timerfd per-descriptor
On Thu, Mar 18 2021 at 09:29, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>> Out of paranoia I'd rather ignore that IO/APIC pin completely if it
>> claims to be IRQ2. I assume there is no device connected to it at all,
>> right?
>
> The original issue was obse
On Wed, Mar 17 2021 at 22:40, Thomas Gleixner wrote:
> af174783b925 ("x86: I/O APIC: Never configure IRQ2")
>
> has a very nice explanation why.
>
> Back then the logic was quite different. All legacy PIC interrupts
> (0-15) were bound to the legacy vectors
On Wed, Mar 17 2021 at 22:18, Thomas Gleixner wrote:
> On Wed, Mar 17 2021 at 21:14, Thomas Gleixner wrote:
>> On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
>> Even without looking at the machine I can tell you what's going on. MP
>> config or ACPI has a pin assigne
On Wed, Mar 17 2021 at 21:14, Thomas Gleixner wrote:
> On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
> Even without looking at the machine I can tell you what's going on. MP
> config or ACPI has a pin assigned to IRQ 2 which I've not seen before.
> The code there is ignoring I
On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
> When irq_matrix_assign()/irq_matrix_free() calls get unsynced, weird
> effects are possible, e.g. when cm->allocated goes negative CPU hotplug
> may get blocked. Add WARN_ON_ONCE() to simplify detecting such situations.
>
> Signed-off-by:
On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
> Trying to offline/online CPU0 seems to work only once:
>
> # echo 0 > /sys/devices/system/cpu/cpu0/online
> # echo 1 > /sys/devices/system/cpu/cpu0/online
> # echo 0 > /sys/devices/system/cpu/cpu0/online
> -bash: echo: write error: No
On Wed, Mar 17 2021 at 11:41, Mike Galbraith wrote:
> On Wed, 2021-03-17 at 10:46 +0100, Ingo Molnar wrote:
>> * Mike Galbraith wrote:
>>
>> > On Tue, 2021-03-16 at 19:20 +0800, Wang Qing wrote:
>> > > Why not just use wake_up_process().
>> >
>> > IMO this is not an improvement. There are other
On Wed, Mar 17 2021 at 12:38, tip-bot wrote:
> The following commit has been merged into the sched/core branch of tip:
>
> Commit-ID: 873d7c4c6a920d43ff82e44121e54053d4edba93
> Gitweb:
> https://git.kernel.org/tip/873d7c4c6a920d43ff82e44121e54053d4edba93
> Author:Nicholas
On Wed, Mar 17 2021 at 15:48, Sebastian Andrzej Siewior wrote:
> On 2021-03-17 15:38:52 [+0100], Thomas Gleixner wrote:
>> thread(irq_A)
>> irq_handler(A)
>> spin_lock(>lock);
>>
>> interrupt(irq_B)
>> irq_handler(B)
>> spin_l
The following commit has been merged into the irq/core branch of tip:
Commit-ID: d2da74d1278a1b51ef18beafa9da770f0db1c617
Gitweb:
https://git.kernel.org/tip/d2da74d1278a1b51ef18beafa9da770f0db1c617
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:04 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: b0cd02c2a9494dbf0a1cc7dc7a3b8b400c158d37
Gitweb:
https://git.kernel.org/tip/b0cd02c2a9494dbf0a1cc7dc7a3b8b400c158d37
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:07 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: ca5f625118955fc544c3cb3dee7055d33ecadafb
Gitweb:
https://git.kernel.org/tip/ca5f625118955fc544c3cb3dee7055d33ecadafb
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:06 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6951547a1399c8f56468ed93bea8f769b891aec3
Gitweb:
https://git.kernel.org/tip/6951547a1399c8f56468ed93bea8f769b891aec3
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:05 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: eb2dafbba8b824ee77f166629babd470dd0b1c0a
Gitweb:
https://git.kernel.org/tip/eb2dafbba8b824ee77f166629babd470dd0b1c0a
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:10 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6516b386d8a07102aac353daf9c0fe0045faeb74
Gitweb:
https://git.kernel.org/tip/6516b386d8a07102aac353daf9c0fe0045faeb74
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:54 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 728b478d2d358480b333b42d0e10e0fecb20114c
Gitweb:
https://git.kernel.org/tip/728b478d2d358480b333b42d0e10e0fecb20114c
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:53 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6fd4e861250b5c89ad460a9f265caeb1bbbfc323
Gitweb:
https://git.kernel.org/tip/6fd4e861250b5c89ad460a9f265caeb1bbbfc323
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:17 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 8b1c04acad082dec76f3f8f7e1fa13493d6cbb79
Gitweb:
https://git.kernel.org/tip/8b1c04acad082dec76f3f8f7e1fa13493d6cbb79
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:56 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: f02fc963e91160e7343933823e8b73a0b2ab0a16
Gitweb:
https://git.kernel.org/tip/f02fc963e91160e7343933823e8b73a0b2ab0a16
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:55 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 47c218dcae6587fb5bce30f1656b13e22391c8e3
Gitweb:
https://git.kernel.org/tip/47c218dcae6587fb5bce30f1656b13e22391c8e3
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:57 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: ba9e6cab49c1465c2c322dcb03d771d5cbecb692
Gitweb:
https://git.kernel.org/tip/ba9e6cab49c1465c2c322dcb03d771d5cbecb692
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:58 +01:00
ernels there is no issue.
Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading")
Reported-by: Johan Hovold
Signed-off-by: Thomas Gleixner
Cc: Eric Dumazet
Cc: Sebastian Andrzej Siewior
Cc: netdev
Cc: "David S. Miller"
Cc: Krzysztof Kozlowski
Cc: Greg Kroah-Hartma
On Wed, Mar 17 2021 at 15:00, Johan Hovold wrote:
> On Wed, Mar 17, 2021 at 02:24:04PM +0100, Thomas Gleixner wrote:
>> Something like the below.
>
> Looks good to me. Do you want to spin that into a patch or shall I do
> it after some testing?
I'll send one in a few
On Fri, Mar 12 2021 at 07:36, Ira Weiny wrote:
> On Fri, Mar 12, 2021 at 07:54:13AM +0100, Christoph Hellwig wrote:
>> So with the new kmap_local interface is it possible / advisable to
>> use local kmaps over code that might schedule(), e.g. to wait for I/O?
>
> It is possible yes. "Advisable" I
On Tue, Mar 16 2021 at 00:37, Ira Weiny wrote:
>
> I think I see the issue. I think this is an invalid configuration.
>
> 00:26:43 > grep DEBUG_KMAP config-5.11.0-rc7-2-g61b205f57991
> CONFIG_DEBUG_KMAP_LOCAL=y
> CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y
>
> 00:26:48 > grep DEBUG_HIGHMEM
Johan,
On Tue, Mar 16 2021 at 11:56, Johan Hovold wrote:
> We've gotten reports of lockdep splats correctly identifying a potential
> deadlock in serial drivers when running with forced interrupt threading.
>
> Typically, a serial driver takes the port spin lock in its interrupt
> handler, but
On Tue, Mar 16 2021 at 11:03, Davidlohr Bueso wrote:
> On Tue, 16 Mar 2021, Peter Zijlstra wrote:
>>IIRC we made the explicit choice to never loop here. That saves having
>>to worry about getting stuck in in-kernel loops.
>>
>>Userspace triggering the case where the futex goes corrupt is UB, after
On Tue, Mar 16 2021 at 19:10, Oleg Nesterov wrote:
> On 02/04, Oleg Nesterov wrote:
>>
>> It seems that nobody objects,
>>
>> Andrew, Andy, Thomas, how do you think this series should be routed?
>
> ping...
>
> What can I do to finally get this merged?
>
> Should I resend once again? Whom?
I'll
On Tue, Mar 16 2021 at 16:10, Eugeniu Rosca wrote:
> If no other comments in the next days, I will resubmit your proposal as
> v2, marked with 'Suggested-by: Thomas Gleixner '.
>
> Alternatively, feel free to author the patch and submit it with us in Cc.
Just send a v2 please
On Mon, Mar 15 2021 at 16:44, Eugeniu Rosca wrote:
> From: Dirk Behme
>
> In case this BUG() is hit, it helps debugging a lot to get an idea
> what tasklet is the root cause. So, be slightly more verbose here.
>
> Signed-off-by: Dirk Behme
> Signed-off-by: Eugeniu Rosca
> ---
>
On Sat, Mar 13 2021 at 17:49, Oleg Nesterov wrote:
> On 03/12, Thomas Gleixner wrote:
>>
>> On Fri, Mar 12 2021 at 20:26, Thomas Gleixner wrote:
>> > On Fri, Mar 12 2021 at 17:11, Oleg Nesterov wrote:
>> >> On 03/11, Thomas Gleixner wrote:
>> &
Linus,
please pull the latest sched/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-2021-03-14
up to: ce29ddc47b91: sched/membarrier: fix missing local execution of
ipi_sync_rq_state()
A set of scheduler updates:
- Prevent a NULL pointer
Linus,
please pull the latest timers/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-2021-03-14
up to: 46eb1701c046: hrtimer: Update softirq_expires_next correctly after
__hrtimer_get_next_event()
A single fix in for hrtimers to prevent an
Linus,
please pull the latest irq/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-2021-03-14
up to: b470ebc9e0e5: Merge tag 'irqchip-fixes-5.12-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
A set of irqchip
Linus,
please pull the latest objtool/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
objtool-urgent-2021-03-14
up to: ba08abca66d4: objtool,x86: Fix uaccess PUSHF/POPF validation
A single objtool fix to handle the PUSHF/POPF validation correctly for the
Linus,
please pull the latest locking/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2021-03-14
up to: 4817a52b3061: seqlock,lockdep: Fix seqcount_latch_init()
A couple of locking fixes:
- A fix for the static_call mechanism so it handles
From: Thomas Gleixner
Subject: signal: Allow tasks to cache one sigqueue struct
Date: Wed, 03 Mar 2021 15:20:25 +0100
From: Thomas Gleixner
The idea for this originates from the real time tree to make signal
delivery for realtime applications more efficient. In quite some of these
application
On Fri, Mar 12 2021 at 20:26, Thomas Gleixner wrote:
> On Fri, Mar 12 2021 at 17:11, Oleg Nesterov wrote:
>> On 03/11, Thomas Gleixner wrote:
>>>
>>> @@ -456,7 +460,12 @@ static void __sigqueue_free(struct sigqu
>>> return;
>>>
On Thu, Mar 11 2021 at 15:13, Eric W. Biederman wrote:
> Thomas Gleixner writes:
>
>> This is a follow up to the initial submission which can be found here:
>>
>> https://lore.kernel.org/r/20210303142025.wbbt2nnr6dtgw...@linutronix.de
>>
>> Signal send
On Fri, Mar 12 2021 at 17:11, Oleg Nesterov wrote:
> On 03/11, Thomas Gleixner wrote:
>>
>> @@ -456,7 +460,12 @@ static void __sigqueue_free(struct sigqu
>> return;
>> if (atomic_dec_and_test(>user->sigpending))
>> fre
On Fri, Mar 12 2021 at 17:18, Oleg Nesterov wrote:
> On 03/12, Sebastian Andrzej Siewior wrote:
>>
>> On 2021-03-11 14:20:39 [+0100], Thomas Gleixner wrote:
>> > --- a/kernel/signal.c
>> > +++ b/kernel/signal.c
>> > @@ -433,7 +433,11 @@ static
On Tue, Mar 09 2021 at 10:40, Xiangyang Yu wrote:
> In our performance tests, we find that the performance of
> sysbench is descend. Function call consumes too many instructions,
> change pi_state_update_owner() to an inline function.
Serioulsy? sysbench does not use PI futexes which means that
On Thu, Mar 11 2021 at 13:45, Thomas Gleixner wrote:
> On Thu, Mar 11 2021 at 00:56, Thomas Gleixner wrote:
>> Rant aside, there is no massive benefit of doing that caching in
>> general, but there is not much of a downside either and for particular
>> use cases it'
There is no point in having the conditional at the callsite.
Just hand in the allocation mode flag to __sigqueue_alloc() and use it to
initialize sigqueue::flags.
No functional change.
Signed-off-by: Thomas Gleixner
---
kernel/signal.c | 17 +++--
1 file changed, 7 insertions
From: Thomas Gleixner
The idea for this originates from the real time tree to make signal
delivery for realtime applications more efficient. In quite some of these
application scenarios a control tasks signals workers to start their
computations. There is usually only one signal per worker
To prepare for caching a sigqueue per task, implement a dedicated function
to flush the sigqueue of the exiting task.
No functional change.
Signed-off-by: Thomas Gleixner
---
include/linux/signal.h |1 +
kernel/exit.c |3 +--
kernel/signal.c|9 +
3 files
This is a follow up to the initial submission which can be found here:
https://lore.kernel.org/r/20210303142025.wbbt2nnr6dtgw...@linutronix.de
Signal sending requires a kmem cache allocation at the sender side and the
receiver hands it back to the kmem cache when consuming the signal.
This
On Thu, Mar 11 2021 at 00:56, Thomas Gleixner wrote:
> Rant aside, there is no massive benefit of doing that caching in
> general, but there is not much of a downside either and for particular
> use cases it's useful even outside of PREEMPT_RT.
>
> IMO, having it there unconditio
On Wed, Mar 10 2021 at 15:57, Eric W. Biederman wrote:
> Thomas Gleixner writes:
>> IMO, not bothering with an extra counter and rlimit plus the required
>> atomic operations is just fine and having this for all tasks
>> unconditionally looks like a clear win.
>>
>
On Thu, Mar 04 2021 at 21:58, Thomas Gleixner wrote:
> On Thu, Mar 04 2021 at 13:04, Eric W. Biederman wrote:
>> Thomas Gleixner writes:
>>>
>>> We could of course do the caching unconditionally for all tasks.
>>
>> Is there any advantage to only doing thi
On Tue, Mar 09 2021 at 13:01, Thomas Gleixner wrote:
> On Fri, Mar 05 2021 at 11:57, Oleg Nesterov wrote:
>> On 03/04, Thomas Gleixner wrote:
>>> On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
>>> >> +static bool sigqueue_add_cache(struct task_stru
On Tue, Mar 09 2021 at 16:21, Sebastian Andrzej Siewior wrote:
> On 2021-03-09 16:00:37 [+0100], To Thomas Gleixner wrote:
>> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
>> index 07c7329d21aa7..1c14ccd351091 100644
>> --- a/include/linux/interrupt.h
&
To allow reuse of the bulk of softirq processing code for RT and to avoid
#ifdeffery all over the place, split protections for various code sections
out into inline helpers so the RT variant can just replace them in one go.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
Soft interrupt disabled sections can legitimately be preempted or schedule
out when blocking on a lock on RT enabled kernels so the RCU preempt check
warning has to be disabled for RT kernels.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
Reviewed-by: Paul E. McKenney
is
temporarily blocked as well which means that such a warning is a false
positive.
To prevent that check the per CPU state which indicates that a scheduled
out task has soft interrupts disabled.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
Reviewed-by: Frederic Weisbecker
the relevant macros in
preempt.h.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
Reviewed-by: Frederic Weisbecker
---
include/linux/hardirq.h |1 +
include/linux/preempt.h |6 +-
include/linux/sched.h |3 +++
3 files changed, 9 insertions(+), 1 deletion
Provide a local lock based serialization for soft interrupts on RT which
allows the local_bh_disabled() sections and servicing soft interrupts to be
preemptible.
Provide the necessary inline helpers which allow to reuse the bulk of the
softirq processing code.
Signed-off-by: Thomas Gleixner
and$0x00,%eax
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
Reviewed-by: Frederic Weisbecker
---
kernel/sched/cputime.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/sched/cputime.c
+++ b
RT runs softirq processing always in thread context and it requires that
both the softirq execution and the BH disabled sections are preemptible.
This is achieved by serialization through per CPU local locks and
substituting a few parts of the existing softirq processing code with
helper
Siewior
Signed-off-by: Thomas Gleixner
Cc: Stefan Richter
Cc: linux1394-de...@lists.sourceforge.net
---
drivers/firewire/ohci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -2545,7 +2545,7 @@ static int
-- NOT FOR IMMEDIATE MERGING --
Now that all users of tasklet_disable() are invoked from sleepable context,
convert it to use tasklet_unlock_wait() which might sleep.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |3 +--
1 file changed, 1 insertion(+), 2 deletions
clear how that can be distangled, so use tasklet_disable_in_atomic()
for now. This allows tasklet_disable() to become sleepable once the
remaining atomic users are cleaned up.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: ath9k-de...@qca.qualcomm.com
Cc: Kalle Valo
C
driver, so use
tasklet_disable_in_atomic() which allows to make tasklet_disable()
sleepable once the remaining atomic users are addressed.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
C
tasklet_disable_in_atomic() which allows
tasklet_disable() to be made sleepable once the remaining atomic context
usage sites are cleaned up.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Chas Williams <3ch...@gmail.com>
Cc: linux-atm-gene...@lists.sourceforge.net
C
() to become sleeping.
Replace the linkch_task tasklet with a work.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
drivers/net/ethernet/jme.c | 10 +-
drivers/net/ethernet/jme.h |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/net
are converted.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Denis Kirjanov
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/dlink/sundance.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/d
is processed on a different CPU
then the local_bh_disable()/enable() pair is just a waste of processor
cycles.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
---
include/linux/interrupt.h |2 +-
kernel/softirq.c | 28 +++-
2 files changed, 28
is scheduled
out.
tasklet_kill() is used in teardown paths and not performance critical at
all. Replace the spin wait with wait_var_event().
Signed-off-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
---
kernel/softirq.c | 23 +++
1 file changed, 15 insertions(+), 8
To ease the transition use spin waiting in tasklet_disable() until all
usage sites from atomic context have been cleaned up.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/include/linux/interrupt.h
+++ b/include
are fixed up and will be
converted to the sleep wait variant later.
Signed-off-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h | 13 ++---
kernel/softirq.c | 18 ++
2 files changed, 20 insertions(+), 11 deletions(-)
--- a/include
Inlines exist for a reason.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
---
include/linux/interrupt.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -676,9 +676,9 @@ static inline void
() to
convert the few atomic use cases over, which allows to change
tasklet_disable() and tasklet_unlock_wait() in a later step.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h | 22 ++
1 file changed, 22 insertions(+)
--- a/include/linux/interrupt.h
+++ b
This is a follow up to the review comments of the series which makes
softirq processing PREEMPT_RT safe:
https://lore.kernel.org/r/20201207114743.gk3...@hirez.programming.kicks-ass.net
Peter suggested to replace the spin waiting in tasklet_disable() and
tasklet_kill() with wait_event(). This
A barrier() in a tight loop which waits for something to happen on a remote
CPU is a pointless exercise. Replace it with cpu_relax() which allows HT
siblings to make progress.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
---
include/linux/interrupt.h |3 ++-
1 file
On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
> On 03/03, Sebastian Andrzej Siewior wrote:
>> +static void __sigqueue_cache_or_free(struct sigqueue *q)
>> +{
>> +struct user_struct *up;
>> +
>> +if (q->flags & SIGQUEUE_PREALLOC)
>> +return;
>> +
>> +up = q->user;
>> +
On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
> On 03/03, Sebastian Andrzej Siewior wrote:
>>
>> +static struct sigqueue *sigqueue_from_cache(struct task_struct *t)
>> +{
>> +struct sigqueue *q = t->sigqueue_cache;
>> +
>> +if (q && cmpxchg(>sigqueue_cache, q, NULL) == q)
>> +
On Thu, Mar 04 2021 at 13:04, Eric W. Biederman wrote:
> Thomas Gleixner writes:
>>
>> We could of course do the caching unconditionally for all tasks.
>
> Is there any advantage to only doing this for realtime tasks?
It was mostly to avoid tons of cached entries ha
Dmitry,
On Thu, Mar 04 2021 at 11:57, Thomas Gleixner wrote:
> On Thu, Mar 04 2021 at 10:53, tip-bot wrote:
>
>> The following commit has been merged into the irq/core branch of tip:
>>
>> Commit-ID: e749df1bbd23f4472082210650514548d8a39e9b
>> Gitweb:
On Thu, Mar 04 2021 at 10:12, Mike Galbraith wrote:
> On Mon, 2021-03-01 at 18:29 +0100, Ben Hutchings wrote:
>
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -874,8 +874,12 @@ static void free_pi_state(struct futex_p
>* and has cleaned up the pi_state already
>*/
> if
From: Thomas Gleixner
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
From: Thomas Gleixner
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
From: Thomas Gleixner
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
201 - 300 of 29419 matches
Mail list logo
