On 2019-01-31 17:52:28 [+0100], Heiko Carstens wrote:
> ...nevertheless Stefan and I looked through the lovely disassembly of
> _pthread_mutex_lock_full() to verify if the compiler barriers are
> actually doing what they are supposed to do. The generated code
> however does look correct.
> So, it m
On 2019-01-30 18:56:54 [+0100], Thomas Gleixner wrote:
> TBH, no clue. Below are some more traceprintks which hopefully shed some
> light on that mystery. See kernel/futex.c line 30 ...
The robust list it somehow buggy. In the last trace we had the
handle_futex_death() of uaddr 3ff9e880140 as the
On 2019-01-30 13:59:55 [+0100], Heiko Carstens wrote:
> Last lines of trace below (full log attached):
<...>-56956 [005] 658.931364: handle_futex_death: uaddr:
3ff9e880c58 pi: 1
…
<...>-56956 [005] 658.931369: handle_futex_death: uaddr:
3ff9e8808c0 success
On 2019-01-29 16:10:58 [+0100], Heiko Carstens wrote:
> Finally... the trace output is quite large with 26 MB... Therefore an
> xz compressed attachment. Hope that's ok.
>
> The kernel used was linux-next 20190129 + your patch.
|ld64.so.1-10237 [006] 14232.031726: sys_futex(uaddr: 3ff
On 2018-01-26 14:09:17 [-0800], Paul E. McKenney wrote:
> find this one. ;-) But it did pass rcutorture testing for a great many
> years, didn't it? :-/
It started to trigger better (or at all) on our test box with
modprobe kvm_intel preemption_timer=n
on the host kernel so maybe a com
On 2017-06-06 18:28:15 [+0200], Peter Zijlstra wrote:
> Subject: sched: Remove TASK_ALL
>
> It's unused:
>
> $ git grep "\" | wc -l
> 1
>
> And dangerous, kill the bugger.
>
> Signed-off-by: Peter Zijlstra (Intel)
Applied for RT but please take this upstream, too.
Sebastian
On 2017-06-06 14:20:37 [+0200], Thomas Gleixner wrote:
> Mathias and others reported GDB failures on RT.
>
> The following scenario leads to task state corruption:
>
> CPU0 CPU1
>
> T1->state = TASK_XXX;
> spin_lock(&lock)
> rt_spin_lock_slowlock(&lock-
extract_crng() will use sleeping locks while in a preempt_disable()
section due to get_cpu_var().
Work around it with local_locks.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/char/random.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/char/rand
On 2017-05-11 11:54:47 [-0400], Steven Rostedt wrote:
> This is the same patch that Thomas wrote, right? Shouldn't this start
> with:
>
> From: Thomas Gleixner
>
> ?
correct. It made its way properly into the patch queue, I just managed
to get it wrong while sending it to the list…
> -- Steve
RT has a problem when the wait on a futex/rtmutex got interrupted by a
timeout or a signal. task->pi_blocked_on is still set when returning from
rt_mutex_wait_proxy_lock(). The task must acquire the hash bucket lock
after this.
If the hash bucket lock is contended then the
BUG_ON(rt_mutex_real_wai
From: Dan Murphy
When CONFIG_MODULES is not set then it fails to compile in lockdep:
|kernel/locking/lockdep.c: In function 'look_up_lock_class':
|kernel/locking/lockdep.c:684:12: error: implicit declaration of function
| '__is_module_percpu_address' [-Werror=implicit-function-declaration]
If C
From: Thomas Gleixner
If a PER_CPU struct which contains a spin_lock is statically initialized
via:
DEFINE_PER_CPU(struct foo, bla) = {
.lock = __SPIN_LOCK_UNLOCKED(bla.lock)
};
then lockdep assigns a seperate key to each lock because the logic for
assigning a key to statically initiali
12 matches
Mail list logo
