linux-kernel - RE: x86, mce, Use user return notifier in mce

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 23 Jan 2012 23:00:16 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	"Huang, Ying" <ying.huang@...el.com>, Tejun Heo <tj@...nel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...64.org>,
	Chen Gong <gong.chen@...ux.intel.com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Subject: RE: x86, mce, Use user return notifier in mce

> This is a performance issue.  So maybe we need to measure the actual
> latency firstly.  The first step can be using WQ_HIGHPRI as you
> suggested.

To clarify "performance issue" a bit.  The situation is that h/w has
found some error in a piece of memory that is not currently being
accessed by any processor - we don't have to take any action right
away - but we'd like to run the work queue that will hunt down which
processes are using this page sooner, rather than later. If some
process does access the memory, it will be a fatal error on some
systems - but if we get there first, we can mark the page, kill the
process(es) and keep the system running.

So we are looking for a solution where there isn't an unbounded time
before the work queue gets run.

-Tony