1) call_function.lock used in smp_call_function_many() is just to protect
call_function.queue and &data->refs, cpu_online_mask is outside of the
lock. And it's not necessary to protect cpu_online_mask,
because data->cpumask is pre-calculate and even if a cpu is brougt up
when calling arch_send_call_function_ipi_mask(), it's harmless because
validation test in generic_smp_call_function_interrupt() will take care
of it.
2) For cpu down issue, stop_machine() will guarantee that no concurrent
smp_call_fuction() is processing.
Signed-off-by: Yong Zhang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
We can't trust userspace to pass signed-extend arguments. Not correctly
sign-extended arguments to futex-wait result in architecturally undefined
operation of 32-bit arithmetic instructions.
For example, if 'val' is too big and bit-31 is 1, the caller may enter
endless loop at:
futex_wait_setup()
{
...
if (uval != val) {
queue_unlock(q, *hb);
ret = -EWOULDBLOCK;
...
}
Signed-off-by: Yong Zhang <[email protected]>
To: [email protected]
To: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/2714/
Signed-off-by: Ralf Baechle <[email protected]>
Actually we have used del_timer_sync() in softirq context for a long time,
e.g. in __dst_free()::cancel_delayed_work().
So change the comments of it to warn on hardirq context only, and make
lockdep know about this change.
Signed-off-by: Yong Zhang <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
On UP try_to_del_timer_sync() is mapped to del_timer() which does not
take the running timer callback into account, so it has different
semantics.
Remove the SMP dependency of try_to_del_timer_sync() by using
base->running_timer in the UP case as well.
[ tglx: Removed set_running_timer() inline and tweaked the changelog ]
Signed-off-by: Yong Zhang <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
When calling check_prevs_add(), if all validations passed
add_lock_to_list() will add new lock to dependency tree and
alloc stack_trace for each list_entry.
But at this time, we are always on the same stack, so stack_trace
for each list_entry has the same value. This is redundant and eats
up lots of memory which could lead to warning on low
MAX_STACK_TRACE_ENTRIES.
Use one copy of stack_trace instead.
V2: As suggested by Peter Zijlstra, move save_trace() from
check_prevs_add() to check_prev_add().
Add tracking for trylock dependence which is also redundant.
Signed-off-by: Yong Zhang <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
If an o32 process generates a core dump on a 64 bit kernel, the core file
will not be correctly recognized. This is because ELF_CORE_COPY_REGS and
ELF_CORE_COPY_TASK_REGS are not correctly defined for o32 and will use
the default register set which would be CONFIG_64BIT in asm/elf.h.
So we'll switch to use the right register defines in this situation by
checking for WANT_COMPAT_REG_H and use the right defines of
ELF_CORE_COPY_REGS and ELF_CORE_COPY_TASK_REGS.
[Ralf: made ELF_CORE_COPY_TASK_REGS() bullet-proof against funny arguments.]
Signed-off-by: Yong Zhang <[email protected]>
Signed-off-by: Ralf Baechle <[email protected]>
Yong Zhang