* [PATCH] mm: allow page_cache_get_speculative in interrupt context
@ 2017-08-01 17:39 kan.liang
2017-08-01 19:49 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: kan.liang @ 2017-08-01 17:39 UTC (permalink / raw)
To: linux-kernel, akpm, axboe, viro, kirill.shutemov, ying.huang,
npiggin, mingo
Cc: Kan Liang
From: Kan Liang <kan.liang@intel.com>
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().
Signed-off-by: Kan Liang <kan.liang@intel.com>
---
include/linux/pagemap.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index baa9344..79b36f5 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -163,8 +163,6 @@ void release_pages(struct page **pages, int nr, bool cold);
*/
static inline int page_cache_get_speculative(struct page *page)
{
- VM_BUG_ON(in_interrupt());
-
#ifdef CONFIG_TINY_RCU
# ifdef CONFIG_PREEMPT_COUNT
VM_BUG_ON(!in_atomic() && !irqs_disabled());
--
2.4.3
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: allow page_cache_get_speculative in interrupt context
2017-08-01 17:39 [PATCH] mm: allow page_cache_get_speculative in interrupt context kan.liang
@ 2017-08-01 19:49 ` Andrew Morton
2017-08-01 20:31 ` Liang, Kan
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2017-08-01 19:49 UTC (permalink / raw)
To: kan.liang
Cc: linux-kernel, axboe, viro, kirill.shutemov, ying.huang, npiggin, mingo
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?
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [PATCH] mm: allow page_cache_get_speculative in interrupt context
2017-08-01 19:49 ` Andrew Morton
@ 2017-08-01 20:31 ` Liang, Kan
2017-08-01 20:51 ` Kirill A. Shutemov
0 siblings, 1 reply; 4+ messages in thread
From: Liang, Kan @ 2017-08-01 20:31 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, axboe, viro, kirill.shutemov, Huang, Ying, npiggin, mingo
>
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: allow page_cache_get_speculative in interrupt context
2017-08-01 20:31 ` Liang, Kan
@ 2017-08-01 20:51 ` Kirill A. Shutemov
0 siblings, 0 replies; 4+ messages in thread
From: Kirill A. Shutemov @ 2017-08-01 20:51 UTC (permalink / raw)
To: Liang, Kan
Cc: Andrew Morton, linux-kernel, axboe, viro, kirill.shutemov, Huang,
Ying, npiggin, mingo
On Tue, Aug 01, 2017 at 08:31:14PM +0000, Liang, Kan wrote:
> >
> > 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.
I don't think so.
It's 2+ year in and nobody stepped onto this until you with your patchset.
There is no real reason to get it backported.
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-08-01 20:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-01 17:39 [PATCH] mm: allow page_cache_get_speculative in interrupt context kan.liang
2017-08-01 19:49 ` Andrew Morton
2017-08-01 20:31 ` Liang, Kan
2017-08-01 20:51 ` Kirill A. Shutemov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.