mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Suresh Siddha <suresh.b.siddha@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	hpa@zytor.com, mingo@elte.hu, linux-kernel@vger.kernel.org,
	suresh@aristanetworks.com, dhowells@redhat.com,
	yasutake.koichi@jp.panasonic.com, benh@kernel.crashing.org,
	paulus@samba.org, lethal@linux-sh.org, chris@zankel.net
Subject: Re: [PATCH 1/3] coredump: flush the fpu exit state for proper multi-threaded core dump
Date: Thu, 10 May 2012 16:48:04 -0700	[thread overview]
Message-ID: <1336693684.1153.30.camel@sbsiddha-desk.sc.intel.com> (raw)
In-Reply-To: <CA+55aFwNST_Lhou1h9JWkg348BET7CbqNX50XYPOFNbXioXdxg@mail.gmail.com>

On Thu, 2012-05-10 at 10:04 -0700, Linus Torvalds wrote:
> On Thu, May 10, 2012 at 9:55 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > My point was, there is no any guarantee prepare_to_copy() does the flush.
> > An architecture can do this in copy_thread() or arch_dup_task_struct(),
> > for example. In fact I do not understand why x86 doesn't do this.
> 
> I agree that it would actually make more sense to do in
> arch_dup_task_struct(). I had trouble finding where the heck the
> fork() code did the FPU fixes back when I was fighting the FPU
> corruption thing.
> 
> The prepare_to_copy() thing is, I think, purely historical, and I
> think we should in fact get rid of it. Everybody else makes it a
> no-op, I think, with a *few* exceptions that seem to have copied the
> x86 model of flushing the FPU there.
> 
> So if somebody sends me a patch to remove that thing, and move the few
> existing users to arch_dup_task_struct(), I'd take it.

ok. Just sent the v2 version of the patchset which includes this. I
didn't compile, test all the architectures. I copied the relevant arch
maintainers who were using prepare_to_copy(). I will be glad if they can
review/test that patch and Ack.

> I think it would be a mistake to use it in the exit path. Make an
> explicit "drop_thread_state()" or similar macro, which can undo FPU
> state and possibly other architecture state.

In my previous/current patchset, I am using arch specific exit_thread()
to call drop_fpu() (changed the name to drop_fpu() from flush_fpu() in
the v2 patchset) during normal exit.

But in the case of coredump, all the other threads are waiting in
exit_mm() as part of the coredump_wait() and this is where we hit the
bug_on, when the main thread finds the other thread is still active on
the runqueue. So based on the discussion with Oleg, I added
wait_task_inactive() check in coredump_wait() to ensure all the other
threads are really off the rq, so that their most recent fpu state is
copied to the memory, which will be copied to the core file by the
dumping thread. Hope this is ok.

thanks,
suresh


  parent reply	other threads:[~2012-05-10 23:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 19:07 [PATCH 1/2] " Suresh Siddha
2012-05-07 19:07 ` [PATCH 2/2] x86, xsave: remove thread_has_fpu() bug check in __sanitize_i387_state() Suresh Siddha
2012-05-07 19:15 ` [PATCH 1/2] coredump: flush the fpu exit state for proper multi-threaded core dump Linus Torvalds
2012-05-07 20:09   ` Suresh Siddha
2012-05-08 23:18     ` Suresh Siddha
2012-05-08 23:18       ` [PATCH 1/3] " Suresh Siddha
2012-05-09 21:05         ` Oleg Nesterov
2012-05-09 21:32           ` Suresh Siddha
2012-05-10 16:55             ` Oleg Nesterov
2012-05-10 17:04               ` Linus Torvalds
2012-05-10 23:33                 ` [PATCH v2 1/4] fork: move the real prepare_to_copy() users to arch_dup_task_struct() Suresh Siddha
2012-05-10 23:33                   ` [PATCH v2 2/4] coredump: ensure the fpu state is flushed for proper multi-threaded core dump Suresh Siddha
2012-05-11 16:51                     ` Oleg Nesterov
2012-05-11 19:05                       ` Suresh Siddha
2012-05-13 16:11                         ` Oleg Nesterov
2012-05-15 18:03                           ` Suresh Siddha
2012-05-15 18:55                             ` Oleg Nesterov
2012-05-17  0:17                     ` [tip:x86/fpu] " tip-bot for Suresh Siddha
2012-05-10 23:33                   ` [PATCH v2 3/4] x86, xsave: remove thread_has_fpu() bug check in __sanitize_i387_state() Suresh Siddha
2012-05-17  0:18                     ` [tip:x86/fpu] " tip-bot for Suresh Siddha
2012-05-10 23:33                   ` [PATCH v2 4/4] x86, fpu: drop the fpu state during thread exit Suresh Siddha
2012-05-17  0:19                     ` [tip:x86/fpu] " tip-bot for Suresh Siddha
2012-05-11  0:17                   ` [PATCH v2 1/4] fork: move the real prepare_to_copy() users to arch_dup_task_struct() Benjamin Herrenschmidt
2012-05-17  0:16                   ` [tip:x86/fpu] " tip-bot for Suresh Siddha
2012-05-10 23:48                 ` Suresh Siddha [this message]
2012-05-08 23:18       ` [PATCH 2/3] x86, xsave: remove thread_has_fpu() bug check in __sanitize_i387_state() Suresh Siddha
2012-05-09 20:30         ` Oleg Nesterov
2012-05-09 21:18           ` Suresh Siddha
2012-05-10 16:36             ` Oleg Nesterov
2012-05-08 23:18       ` [PATCH 3/3] x86, fpu: clear the fpu state during thread exit Suresh Siddha

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=1336693684.1153.30.camel@sbsiddha-desk.sc.intel.com \
    --to=suresh.b.siddha@intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=chris@zankel.net \
    --cc=dhowells@redhat.com \
    --cc=hpa@zytor.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=paulus@samba.org \
    --cc=suresh@aristanetworks.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yasutake.koichi@jp.panasonic.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®