[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4D41AE51020000780002ED8F@vpn.id2.novell.com>
Date: Thu, 27 Jan 2011 16:41:37 +0000
From: "Jan Beulich" <JBeulich@...ell.com>
To: "Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc: "Jeremy Fitzhardinge" <jeremy@...p.org>, <fanhenglong@...wei.com>,
"Kaushik Barde" <kbarde@...wei.com>,
"Kenneth Lee" <liguozhu@...wei.com>,
"linqaingmin" <linqiangmin@...wei.com>, <wangzhenguo@...wei.com>,
"Xiaowei Yang" <xiaowei.yang@...wei.com>,
"Wu Fengguang" <fengguang.wu@...el.com>,
"Nick Piggin" <npiggin@...nel.dk>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
<linux-kernel@...r.kernel.org>
Subject: Re: One (possible) x86 get_user_pages bug
>>> On 27.01.11 at 17:25, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> On Thu, 2011-01-27 at 16:07 +0000, Jan Beulich wrote:
>>
>> Nick, based on your doing of the initial implementation, would
>> you be able to estimate whether disabling get_user_pages_fast()
>> altogether for Xen would be performing measurably worse than
>> adding the locks (but continuing to avoid acquiring mm->mmap_sem)
>> as suggested by Xiaowei? That's of course only if the latter is correct
>> at all, of which I haven't fully convinced myself yet.
>
> Adding the lock will result in deadlocks, __get_user_pages_fast() is
> used from NMI context.
>
> Then again, I've got no clue if Xen even has NMIs..
It does, but not in a way that would be usable for perf events
afaict, so that code path should be dead under Xen. (We don't
even build the offending source file in our kernels, but I'm not
sure how pv-ops deals with situations like this - Jeremy?)
Jan
--
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/
Powered by blists - more mailing lists