All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Chuck Ebbert <chuckebbert.lk@gmail.com>,
	Jan Kratochvil <jan.kratochvil@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: ptrace && fpu_lazy_restore
Date: Mon, 16 Apr 2012 00:38:08 +0200	[thread overview]
Message-ID: <20120415223808.GA26214@redhat.com> (raw)
In-Reply-To: <CA+55aFxJykAy4=9WVOnUOy1PUBYLmPy9mJmydoYZpQEbSkfvJQ@mail.gmail.com>

On 04/14, Linus Torvalds wrote:
>
> So I actually think that I would prefer the patch that invalidates the
> FPU caches more aggressively. Sure, we don't really *need* to
> invalidate if we're just reading, but I'd almost prefer to just have
> it done once in "init_fpu()".

Agreed. I'll send your patch back to you tomorrow.

> The only case where we care about the FPU caches remaining is actually
> the nice normal "we just switched tasks through normal scheduling".

Yes. And there is another case when fpu_lazy_restore() returns the
false positive.

Suppose that fpu_owner_task exits on CPU_0, and then fork() reuses
its task_struct. The new child is still fpu_owner_task and this is
obviously wrong (unless of course another thread uses fpu).

Initially I thought this should be fixed too, but it seems that
"p->fpu_counter = 0" in copy_thread() saves us.

This looks a bit fragile... And could you confirm this is really
fine?


Btw, do we really need this "old->thread.fpu.last_cpu = ~0" in
the "else" branch of switch_fpu_prepare()? Just curious, I guees
this doesn't matter since we reset old->fpu_counter. But if we
can remove this line, then perhaps we can another optimization.

Oleg.


  reply	other threads:[~2012-04-15 22:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-14 23:52 ptrace && fpu_lazy_restore Oleg Nesterov
2012-04-14 23:59 ` Oleg Nesterov
2012-04-15  2:03 ` Linus Torvalds
2012-04-15 22:38   ` Oleg Nesterov [this message]
2012-04-15 23:42     ` Linus Torvalds
2012-04-15 23:46       ` Linus Torvalds
2012-04-16 20:47         ` [PATCH 0/1] i387: ptrace breaks the lazy-fpu-restore logic Oleg Nesterov
2012-04-16 20:48           ` [PATCH 1/1] " Oleg Nesterov
2012-04-16 22:09             ` Oleg Nesterov
2012-04-17  0:05             ` [tip:x86/urgent] " tip-bot for Oleg Nesterov

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=20120415223808.GA26214@redhat.com \
    --to=oleg@redhat.com \
    --cc=chuckebbert.lk@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jan.kratochvil@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.