linux-kernel - [PATCH v2 0/2] Make life miserable for split lockers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220310204854.31752-1-tony.luck@intel.com>
Date:   Thu, 10 Mar 2022 12:48:52 -0800
From:   Tony Luck <tony.luck@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Fenghua Yu <fenghua.yu@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
        Tony Luck <tony.luck@...el.com>
Subject: [PATCH v2 0/2] Make life miserable for split lockers

See part 0001 commit message for what & why.

Changes since v1(RFC) based on feedback from Thomas:

1) No longer implemented as new sub-option of split_lock_detect boot
   option.  Just update the existing (default) "warn" mode.
2) Use the (more appropriate) "schedule_delayed_work_on() instead of
   schedule_delayed_work() to re-enable split lock detection.
3) Add msleep for extra misery before disabling split lock detection
   on a core.

Next two aren't from Thomas.
4) Drop the TIF_SLD bit and associated code. No longer needed. This
   part is done as clean up in patch 0002.
5) Add a bit in task structure to make sure each split-locking task
   only tries to print a warn message to the console once. Need this
   to preserve existing behavior that was previously controlled by the
   TIF_SLD bit.

Testing notes. I checked this out by running 2,000 processes that
each looped executing 10,000 split locks. System remains very
responsive while this test is running (compared with unusable
without these patches). When each process gets the semaphore
and two jiffies of time to execute split locks it manages to
complete ~430 before the delayed work thread re-enables detection.

The semaphore gives nice round-robin access to the 2,000 tasks.
So each ends up blocking for 24ish seconds while the other 1,999
task take their turn.

Tony Luck (2):
  x86/split_lock: Make life miserable for split lockers
  x86/split-lock: Remove unused TIF_SLD bit

 arch/x86/include/asm/cpu.h         |  2 -
 arch/x86/include/asm/thread_info.h |  4 +-
 arch/x86/kernel/cpu/intel.c        | 77 +++++++++++++++++++++---------
 arch/x86/kernel/process.c          |  3 --
 include/linux/sched.h              |  3 ++
 kernel/fork.c                      |  5 ++
 6 files changed, 64 insertions(+), 30 deletions(-)

-- 
2.35.1