Kernel-hardening archive on
 help / color / Atom feed
From: Linus Torvalds <>
To: "Eric W. Biederman" <>
Cc: Jann Horn <>,
	Alan Stern <>,
	 Andrea Parri <>,
	Will Deacon <>,
	 Peter Zijlstra <>,
	Boqun Feng <>,
	 Nicholas Piggin <>,
	David Howells <>,
	 Jade Alglave <>,
	Luc Maranget <>,
	 "Paul E. McKenney" <>,
	Akira Yokosawa <>,
	 Daniel Lustig <>,
	Adam Zabrocki <>,
	 kernel list <>,
	 Kernel Hardening <>,
	Oleg Nesterov <>,
	 Andy Lutomirski <>,
	Bernd Edlinger <>,
	 Kees Cook <>,
	Andrew Morton <>,
	 stable <>, Marco Elver <>,
	 Dmitry Vyukov <>,
	kasan-dev <>
Subject: Re: [PATCH] signal: Extend exec_id to 64bits
Date: Thu, 2 Apr 2020 11:06:02 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Apr 2, 2020 at 6:14 AM Eric W. Biederman <> wrote:
> Linus Torvalds <> writes:
> > tasklist_lock is aboue the hottest lock there is in all of the kernel.
> Do you know code paths you see tasklist_lock being hot?

It's generally not bad enough to show up on single-socket machines.

But the problem with tasklist_lock is that it's one of our remaining
completely global locks. So it scales like sh*t in some circumstances.

On single-socket machines, most of the truly nasty hot paths aren't a
huge problem, because they tend to be mostly readers. So you get the
cacheline bounce, but you don't (usually) get much busy looping. The
cacheline bounce is "almost free" on a single socket.

But because it's one of those completely global locks, on big
multi-socket machines people have reported it as a problem forever.
Even just readers can cause problems (because of the cacheline
bouncing even when you just do the reader increment), but you also end
up having more issues with writers scaling badly.

Don't get me wrong - you can get bad scaling on other locks too, even
when they aren't really global - we had that with just the reference
counter increment for the user signal accounting, after all. Neither
of the reference counts were actually global, but they were just
effectively single counters under that particular load (ie the count
was per-user, but the load ran as a single user).

The reason tasklist_lock probably doesn't come up very much is that
it's _always_ been expensive. It has also caused some fundamental
issues (I think it's the main reason we have that rule that
reader-writer locks are unfair to readers, because we have readers
from interrupt context too, but can't afford to make normal readers
disable interrupts).

A lot of the tasklist lock readers end up looping quite a bit inside
the lock (looping over threads etc), which is why it can then be a big
deal when the rare reader shows up.

We've improved a _lot_ of those loops. That has definitely helped for
the common cases. But we've never been able to really fix the lock


  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 21:50 Curiosity around 'exec_id' and some problems associated with it Adam Zabrocki
2020-03-29 22:43 ` Kees Cook
2020-03-30  8:34   ` Oleg Nesterov
2020-03-31  4:29   ` Adam Zabrocki
2020-04-01 20:47   ` [PATCH] signal: Extend exec_id to 64bits Eric W. Biederman
2020-04-01 20:55     ` Linus Torvalds
2020-04-01 21:03       ` Eric W. Biederman
2020-04-01 23:37     ` Jann Horn
2020-04-01 23:51       ` Linus Torvalds
2020-04-01 23:55         ` Linus Torvalds
2020-04-02  1:35           ` Jann Horn
2020-04-02  2:05             ` Linus Torvalds
2020-04-02 13:11               ` Eric W. Biederman
2020-04-02 18:06                 ` Linus Torvalds [this message]
2020-04-02  4:46     ` Jann Horn
2020-04-02 14:14       ` Eric W. Biederman
2020-04-03  2:11       ` Adam Zabrocki
2020-04-02  7:19     ` Kees Cook
2020-04-02  7:22     ` Bernd Edlinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel-hardening archive on

Archives are clonable:
	git clone --mirror kernel-hardening/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernel-hardening kernel-hardening/ \
	public-inbox-index kernel-hardening

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone