Subject: Re: [PATCH 1/3] coredump: flush the fpu exit state for proper
 multi-threaded core dump
From: Suresh Siddha <suresh.b.siddha@intel.com>
Reply-To: Suresh Siddha <suresh.b.siddha@intel.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: torvalds@linux-foundation.org, hpa@zytor.com, mingo@elte.hu,
        linux-kernel@vger.kernel.org, suresh@aristanetworks.com
Date: Wed, 09 May 2012 14:32:03 -0700
In-Reply-To: <20120509210551.GB334@redhat.com>
References: <1336421341.19423.4.camel@sbsiddha-desk.sc.intel.com>
	 <1336519085-27450-1-git-send-email-suresh.b.siddha@intel.com>
	 <1336519085-27450-2-git-send-email-suresh.b.siddha@intel.com>
	 <20120509210551.GB334@redhat.com>
Organization: Intel Corp
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Message-ID: <1336599123.4634.42.camel@sbsiddha-desk.sc.intel.com>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1677
Lines: 47

On Wed, 2012-05-09 at 23:05 +0200, Oleg Nesterov wrote:
> On 05/08, Suresh Siddha wrote:
> >
> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> > @@ -656,6 +656,11 @@ static void exit_mm(struct task_struct * tsk)
> >  		struct core_thread self;
> >  		up_read(&mm->mmap_sem);
> >
> > +		/*
> > +		 * Flush the live extended register state to memory.
> > +		 */
> > +		prepare_to_copy(tsk);
> 
> This doesn't look very nice imho, but I guess you understand this...
> 
> Perhaps we need an arch-dependent helper which saves the FPU regs
> if needed.
> 
> I can be easily wrong, but I did the quick grep and I am not sure
> we can rely on prepare_to_copy(). For example, it is a nop in
> arch/sh/include/asm/processor_64.h. But at the same time it has
> save_fpu().
> 
> OTOH, I am not sure it is safe to use prepare_to_copy() in exit_mm(),
> at least in theory. God knows what it can do...

There is an explicit schedule() just few lines below. And the schedule()
also will do the same thing. The thing is we want the user-specific
extended registers to be flushed to memory (used also in the fork path)
before we notify the core dumping thread that we reached the serializing
point, for the dumping thread to continue the dump process.

And to make this coredump specific, I really need to move it there as I
need to reliably find out if the core dump is in progress for this
thread.

Linus/Peter/Ingo, any comments?

thanks,
suresh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/