lkml.org 
[lkml]   [2020]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH 0/3] membarrier fixes
Date
Hi all-

x86's sync_core_before_usermode() was bogus. Without the other
patches applied, it would never be called in a problematic context,
but that's about to change. In any event, sync_core_before_usermode()
should be correct.

The second patch fixes a minor issue, but it also makes the third patch
nicer.

The third patch is the biggie. The old code looped over all CPUs
without disabling migration, and it skipped the current CPU. There
were comments about how the scheduler's barriers made this okay. This
may well be true, but it was a mess, and it's considerably simpler to
treat the current CPU just like all other CPUs.

The messy skip-the-current-CPU code masked what seems to be a couple
of much bigger issues: if the membarrier() syscall ran all the way
through _without_ being preempted, it completely failed to operate on
the calling thread. The smp_mb() calls sprinkled through the function
would mask this problem for the normal barrier mode, but they wouldn't
help for the core-serializing mode or rseq_preempt mode. In other
words, modifying some code, calling
membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE, 0), and running
that modified code was not actually safe. This seems to rather defeat
the purpose.

Some or all of this might be -stable material.

The global_expedited code looks similarly nasty. Any volunteers to
clean it up?

Andy Lutomirski (3):
x86/membarrier: Get rid of a dubious optimization
membarrier: Add an actual barrier before rseq_preempt()
membarrier: Propagate SYNC_CORE and RSEQ actions more carefully

arch/x86/include/asm/sync_core.h | 9 +--
arch/x86/mm/tlb.c | 6 +-
kernel/sched/membarrier.c | 102 ++++++++++++++++++++++---------
3 files changed, 83 insertions(+), 34 deletions(-)

--
2.28.0

\
 
 \ /
  Last update: 2020-11-30 18:53    [W:0.106 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site