Messages in this thread | | | From | "Liang, Kan" <> | Subject | RE: [PATCH] mm: allow page_cache_get_speculative in interrupt context | Date | Tue, 1 Aug 2017 20:31:14 +0000 |
| |
> > On Tue, 1 Aug 2017 13:39:06 -0400 kan.liang@intel.com wrote: > > > Kernel panic when calling the IRQ-safe __get_user_pages_fast in NMI > > handler. > > > > The bug was introduced by commit: > > > > 2947ba054a4d ("x86/mm/gup: Switch GUP to the generic > > get_user_page_fast() implementation") > > > > The original x86 __get_user_page_fast used plain get_page() or > > page_ref_add(). However, the generic __get_user_page_fast uses > > page_cache_get_speculative(), which has VM_BUG_ON(in_interrupt()). > > > > There is no reason to prevent page_cache_get_speculative from using in > > interrupt context. According to the author, putting a BUG_ON there is > > just because the code is not verifying correctness of interrupt races. > > I did some tests in interrupt context. There is no issue found. > > Removing VM_BUG_ON(in_interrupt()) for page_cache_get_speculative(). > > What code calls page_cache_get_speculative() from NMI context? >
The code I'm implementing will call __get_user_page_fast from NMI context. __get_user_page_fast will eventually call page_cache_get_speculative().
> I'm trying to work out which kernel versions need this fix, but there isn't > enough info in the changelog for this. Please don't do that.
Sorry for the confusion.
According to the comments, __get_user_page_fast should be IRQ-safe. But it's not. This patch could be used to resolve the inconsistencies between the comments and implementations for now. The generic __get_user_page_fast was introduced by the commit 2667f50e8b81457fcb4a3dbe6aff3e81ea009e13 mm: introduce a general RCU get_user_pages_fast() I think the kernel after the commit should be fixed.
Thanks, Kan
| |