All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Jann Horn <jann@thejh.net>, Peter Zijlstra <peterz@infradead.org>,
	Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Brian Gerst <brgerst@gmail.com>, Borislav Petkov <bp@alien8.de>,
	Linux API <linux-api@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Tycho Andersen <tycho.andersen@canonical.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat
Date: Fri, 30 Sep 2016 21:22:08 -0700	[thread overview]
Message-ID: <CA+55aFxZkzC4uCXgL3BEGbbobtm0-n8FoNnswx5s=+8PNsGo2w@mail.gmail.com> (raw)
In-Reply-To: <CALCETrUBmsoUK5Shkjwo6n=BGaHFtZhhUZ=2uOcAzWUend-BXg@mail.gmail.com>

On Fri, Sep 30, 2016 at 7:01 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> Peter, how nasty would it be to add some lightish-weight lock that
> lets us pin a task in a non-running state?  Maybe we could take the rq
> lock, do something to the task to make it sleepy (steal it off the
> queue?), unlock the lock, do whatever we're going, then take the lock
> again and put it back.

No. Don't do this. Forcing some sleeping lock in the core task state
/proc stuff is a nightmare. That thing ends up being used very heavily
under some loads. No _way_ is it ok to synchronize with the target
task.

> Or if we had a seqlock-like thing, we could maybe arrange for
> get_wchan to abort if the task get scheduled between when it starts
> and when it finishes.

seq_lock might be ok, but do we even need it? What's the worst that
can happen? An odd symbol name showing up in a race condition? Sounds
like a non-issue to me.

        Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
Cc: Jann Horn <jann-XZ1E9jl8jIdeoWH0uzbU5w@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	X86 ML <x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Brian Gerst <brgerst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Tycho Andersen
	<tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Tetsuo Handa
	<penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org>
Subject: Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat
Date: Fri, 30 Sep 2016 21:22:08 -0700	[thread overview]
Message-ID: <CA+55aFxZkzC4uCXgL3BEGbbobtm0-n8FoNnswx5s=+8PNsGo2w@mail.gmail.com> (raw)
In-Reply-To: <CALCETrUBmsoUK5Shkjwo6n=BGaHFtZhhUZ=2uOcAzWUend-BXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, Sep 30, 2016 at 7:01 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>
> Peter, how nasty would it be to add some lightish-weight lock that
> lets us pin a task in a non-running state?  Maybe we could take the rq
> lock, do something to the task to make it sleepy (steal it off the
> queue?), unlock the lock, do whatever we're going, then take the lock
> again and put it back.

No. Don't do this. Forcing some sleeping lock in the core task state
/proc stuff is a nightmare. That thing ends up being used very heavily
under some loads. No _way_ is it ok to synchronize with the target
task.

> Or if we had a seqlock-like thing, we could maybe arrange for
> get_wchan to abort if the task get scheduled between when it starts
> and when it finishes.

seq_lock might be ok, but do we even need it? What's the worst that
can happen? An odd symbol name showing up in a race condition? Sounds
like a non-issue to me.

        Linus

  reply	other threads:[~2016-10-01  4:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-30 17:58 [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Andy Lutomirski
2016-09-30 17:58 ` Andy Lutomirski
2016-09-30 17:58 ` [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat Andy Lutomirski
2016-09-30 17:58   ` Andy Lutomirski
2016-09-30 18:56   ` Jann Horn
2016-09-30 18:56     ` Jann Horn
2016-10-01  2:01     ` Andy Lutomirski
2016-10-01  2:01       ` Andy Lutomirski
2016-10-01  4:22       ` Linus Torvalds [this message]
2016-10-01  4:22         ` Linus Torvalds
2016-10-01 10:37       ` Jann Horn
2016-10-01 10:37         ` Jann Horn
2016-10-14 18:25         ` Andy Lutomirski
2016-10-14 18:25           ` Andy Lutomirski
2016-10-14 20:01           ` Tycho Andersen
2016-10-20 11:13   ` [tip:mm/urgent] fs/proc: " tip-bot for Andy Lutomirski
2016-11-01 14:36   ` [4.9-rc3] BUG: unable to handle kernel paging request at ffffc900144dfc60 Tetsuo Handa
2016-11-01 23:47     ` Linus Torvalds
2016-11-02 10:50       ` Tetsuo Handa
2016-11-02 14:05         ` Andy Lutomirski
2016-11-02 14:05           ` Andy Lutomirski
2016-11-02 14:54         ` Linus Torvalds
2016-11-03  6:32           ` Ingo Molnar
2016-11-03  7:09         ` [tip:sched/urgent] sched/core: Fix oops in sched_show_task() tip-bot for Tetsuo Handa
2016-11-03  7:10       ` [tip:sched/urgent] sched/core: Remove pointless printout " tip-bot for Linus Torvalds
2016-09-30 17:58 ` [PATCH 2/3] proc: Stop trying to report thread stacks Andy Lutomirski
2016-10-20 11:13   ` [tip:mm/urgent] fs/proc: " tip-bot for Andy Lutomirski
2016-09-30 17:58 ` [PATCH 3/3] mm: Change vm_is_stack_for_task() to vm_is_stack_for_current() Andy Lutomirski
2016-09-30 17:58   ` Andy Lutomirski
2016-10-20 11:14   ` [tip:mm/urgent] " tip-bot for Andy Lutomirski
2016-10-03 23:08 ` [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Andy Lutomirski
2016-10-03 23:08   ` Andy Lutomirski
2016-10-03 23:17   ` Linus Torvalds
2016-10-03 23:17     ` Linus Torvalds
2016-10-04  7:06     ` Raymond Jennings
2016-10-04  7:06       ` Raymond Jennings
2016-10-14 18:26     ` Andy Lutomirski
2016-10-14 18:26       ` Andy Lutomirski

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CA+55aFxZkzC4uCXgL3BEGbbobtm0-n8FoNnswx5s=+8PNsGo2w@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=jann@thejh.net \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=peterz@infradead.org \
    --cc=tycho.andersen@canonical.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.