linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm/gup: Make __gup_device_* require THP
@ 2017-06-26  6:38 Oliver O'Halloran
  2017-07-21 23:13 ` Andrew Morton
  0 siblings, 1 reply; 4+ messages in thread
From: Oliver O'Halloran @ 2017-06-26  6:38 UTC (permalink / raw)
  To: linux-mm; +Cc: Oliver O'Halloran

These functions are the only bits of generic code that use
{pud,pmd}_pfn() without checking for CONFIG_TRANSPARENT_HUGEPAGE.
This works fine on x86, the only arch with devmap support, since the
*_pfn() functions are always defined there, but this isn't true for
every architecture.

Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
 mm/gup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/gup.c b/mm/gup.c
index d9e6fddcc51f..04cf79291321 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1287,7 +1287,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
 }
 #endif /* __HAVE_ARCH_PTE_SPECIAL */
 
-#ifdef __HAVE_ARCH_PTE_DEVMAP
+#if defined(__HAVE_ARCH_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
 static int __gup_device_huge(unsigned long pfn, unsigned long addr,
 		unsigned long end, struct page **pages, int *nr)
 {
-- 
2.9.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/gup: Make __gup_device_* require THP
  2017-06-26  6:38 [PATCH] mm/gup: Make __gup_device_* require THP Oliver O'Halloran
@ 2017-07-21 23:13 ` Andrew Morton
  2017-07-22  3:49   ` Oliver
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2017-07-21 23:13 UTC (permalink / raw)
  To: Oliver O'Halloran; +Cc: linux-mm, Kirill A. Shutemov

On Mon, 26 Jun 2017 16:38:33 +1000 "Oliver O'Halloran" <oohall@gmail.com> wrote:

> These functions are the only bits of generic code that use
> {pud,pmd}_pfn() without checking for CONFIG_TRANSPARENT_HUGEPAGE.
> This works fine on x86, the only arch with devmap support, since the
> *_pfn() functions are always defined there, but this isn't true for
> every architecture.
> 
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> ---
>  mm/gup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index d9e6fddcc51f..04cf79291321 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1287,7 +1287,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
>  }
>  #endif /* __HAVE_ARCH_PTE_SPECIAL */
>  
> -#ifdef __HAVE_ARCH_PTE_DEVMAP
> +#if defined(__HAVE_ARCH_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
>  static int __gup_device_huge(unsigned long pfn, unsigned long addr,
>  		unsigned long end, struct page **pages, int *nr)
>  {

(cc Kirill)

Please provide a full description of the bug which is being fixed.  I
assume it's a build error.  What are the error messages and under what
circumstances.

Etcetera.  Enough info for me (and others) to decide which kernel
version(s) need the fix.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/gup: Make __gup_device_* require THP
  2017-07-21 23:13 ` Andrew Morton
@ 2017-07-22  3:49   ` Oliver
  2017-07-23 21:34     ` Kirill A. Shutemov
  0 siblings, 1 reply; 4+ messages in thread
From: Oliver @ 2017-07-22  3:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux MM, Kirill A. Shutemov

On Sat, Jul 22, 2017 at 9:13 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 26 Jun 2017 16:38:33 +1000 "Oliver O'Halloran" <oohall@gmail.com> wrote:
>
>> These functions are the only bits of generic code that use
>> {pud,pmd}_pfn() without checking for CONFIG_TRANSPARENT_HUGEPAGE.
>> This works fine on x86, the only arch with devmap support, since the
>> *_pfn() functions are always defined there, but this isn't true for
>> every architecture.
>>
>> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
>> ---
>>  mm/gup.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index d9e6fddcc51f..04cf79291321 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -1287,7 +1287,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
>>  }
>>  #endif /* __HAVE_ARCH_PTE_SPECIAL */
>>
>> -#ifdef __HAVE_ARCH_PTE_DEVMAP
>> +#if defined(__HAVE_ARCH_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
>>  static int __gup_device_huge(unsigned long pfn, unsigned long addr,
>>               unsigned long end, struct page **pages, int *nr)
>>  {
>
> (cc Kirill)
>
> Please provide a full description of the bug which is being fixed.  I
> assume it's a build error.  What are the error messages and under what
> circumstances.
>
> Etcetera.  Enough info for me (and others) to decide which kernel
> version(s) need the fix.

It fixes a build breakage that you will only ever see when enabling
the devmap pte bit for another architecture. Given it requires new
code to hit the bug I don't see much point in backporting it to 4.12,
but taking it as a fix for 4.13 wouldn't hurt.

The root problem is that the arch doesn't need to provide pmd_pfn()
and friends when THP is disabled. They're provided unconditionally by
x86 and ppc, but I did a cursory check and found that mips only
defines pmd_pfn() when THP is enabled so I figured this should be
fixed. Making each arch provide them unconditionally might be a better
idea, but that seemed like it'd be a lot of churn for a minor bug.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mm/gup: Make __gup_device_* require THP
  2017-07-22  3:49   ` Oliver
@ 2017-07-23 21:34     ` Kirill A. Shutemov
  0 siblings, 0 replies; 4+ messages in thread
From: Kirill A. Shutemov @ 2017-07-23 21:34 UTC (permalink / raw)
  To: Oliver; +Cc: Andrew Morton, Linux MM

On Sat, Jul 22, 2017 at 01:49:23PM +1000, Oliver wrote:
> On Sat, Jul 22, 2017 at 9:13 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Mon, 26 Jun 2017 16:38:33 +1000 "Oliver O'Halloran" <oohall@gmail.com> wrote:
> >
> >> These functions are the only bits of generic code that use
> >> {pud,pmd}_pfn() without checking for CONFIG_TRANSPARENT_HUGEPAGE.
> >> This works fine on x86, the only arch with devmap support, since the
> >> *_pfn() functions are always defined there, but this isn't true for
> >> every architecture.
> >>
> >> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> >> ---
> >>  mm/gup.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/mm/gup.c b/mm/gup.c
> >> index d9e6fddcc51f..04cf79291321 100644
> >> --- a/mm/gup.c
> >> +++ b/mm/gup.c
> >> @@ -1287,7 +1287,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
> >>  }
> >>  #endif /* __HAVE_ARCH_PTE_SPECIAL */
> >>
> >> -#ifdef __HAVE_ARCH_PTE_DEVMAP
> >> +#if defined(__HAVE_ARCH_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
> >>  static int __gup_device_huge(unsigned long pfn, unsigned long addr,
> >>               unsigned long end, struct page **pages, int *nr)
> >>  {
> >
> > (cc Kirill)
> >
> > Please provide a full description of the bug which is being fixed.  I
> > assume it's a build error.  What are the error messages and under what
> > circumstances.
> >
> > Etcetera.  Enough info for me (and others) to decide which kernel
> > version(s) need the fix.
> 
> It fixes a build breakage that you will only ever see when enabling
> the devmap pte bit for another architecture. Given it requires new
> code to hit the bug I don't see much point in backporting it to 4.12,
> but taking it as a fix for 4.13 wouldn't hurt.
> 
> The root problem is that the arch doesn't need to provide pmd_pfn()
> and friends when THP is disabled. They're provided unconditionally by
> x86 and ppc, but I did a cursory check and found that mips only
> defines pmd_pfn() when THP is enabled so I figured this should be
> fixed. Making each arch provide them unconditionally might be a better
> idea, but that seemed like it'd be a lot of churn for a minor bug.

This makes sense to me.

Assuming updated commit message,

Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-07-23 21:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-26  6:38 [PATCH] mm/gup: Make __gup_device_* require THP Oliver O'Halloran
2017-07-21 23:13 ` Andrew Morton
2017-07-22  3:49   ` Oliver
2017-07-23 21:34     ` Kirill A. Shutemov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).