linux-kernel - Re: [PATCH 08/10] NOTIFIER: Take over TIF_MCE_NOTIFY and implement task return notifier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Jun 2011 10:59:38 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Tony Luck <tony.luck@...el.com>
CC:	Borislav Petkov <bp@...64.org>, Ingo Molnar <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Huang, Ying" <ying.huang@...el.com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Subject: Re: [PATCH 08/10] NOTIFIER: Take over TIF_MCE_NOTIFY and implement
 task return notifier

On 06/13/2011 08:31 AM, Tony Luck wrote:
> On Sun, Jun 12, 2011 at 3:38 PM, Borislav Petkov<bp@...64.org>  wrote:
> >  On Thu, Jun 09, 2011 at 05:36:42PM -0400, Luck, Tony wrote:
> >>  From: Tony Luck<tony.luck@...el.com>
> >>
> >>  Existing user return notifier mechanism is designed to catch a specific
> >>  cpu just as it returns to run any task in user mode.  We also need a
> >>  mechanism to catch a specific task.
> >
> >  Why do we need that? I mean, in the remaining patches we end up either
> >  running memory_failure() or sending signals to a task. Can't we do it
> >  all in the user return notifier and not have a different notifier for
> >  each policy?
>
> Unless I'm mis-reading the user-return-notifier code, it is possible that
> we'll context switch before we get to the notifier. At that point the
> user-return-notifier TIF bit is passed on from our task to the newly
> run-able task. But our task is still viable, so another cpu could grab
> it and start running it ... then we have a race ... will the new task
> that inherited the notifier unmap the page fast enough, or will there
> be a loud BANG as the original task runs right into the machine
> check again.

Right.  user-return-notifiers are really a per-cpu notifier, unrelated 
to any specific task.  The use of per-task flags was an optimization.

If running into the MCE again is really bad, then you need something 
more, since other threads (or other processes) could run into the same 
page as well.  If not, do we care?  Let it hit the MCE again, as long as 
we'll catch it eventually.

-- 
error compiling committee.c: too many arguments to function

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