[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210108224715.GB2453@worktop.programming.kicks-ass.net>
Date: Fri, 8 Jan 2021 23:47:15 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Tony Luck <tony.luck@...el.com>
Cc: Borislav Petkov <bp@...en8.de>, x86@...nel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Darren Hart <dvhart@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
linux-kernel@...r.kernel.org, linux-edac@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 2/2] futex, x86/mce: Avoid double machine checks
On Fri, Jan 08, 2021 at 02:22:51PM -0800, Tony Luck wrote:
> futex_wait_setup() first tries to read the user value with page faults
> disabled (because it holds a lock, and so cannot sleep). If that read
> fails it drops the lock and tries again.
>
> But there are now two reasons why the user space read can fail. Either:
> 1) legacy case of a page fault, in which case it is reasonable to retry
> 2) machine check on the user address, bad idea to re-read
>
> Add some infrastructure to differentiate these cases.
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2658,6 +2658,9 @@ static int futex_wait_setup(u32 __user *uaddr, u32 val, unsigned int flags,
> if (ret) {
> queue_unlock(*hb);
>
> + if (arch_memory_failure(uaddr))
> + return ret;
> +
> ret = get_user(uval, uaddr);
> if (ret)
> return ret;
I think this is horrid; why can't we have it return something different
then -EFAULT instead?
Powered by blists - more mailing lists