* linux-next: build failure on powerpc 8xx with 16k pages
@ 2020-06-04 10:48 Christophe Leroy
2020-06-04 11:17 ` Will Deacon
0 siblings, 1 reply; 11+ messages in thread
From: Christophe Leroy @ 2020-06-04 10:48 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC, Will Deacon,
Thomas Gleixner, Stephen Rothwell
Cc: Linux Next Mailing List, Linux Kernel Mailing List
Hi all,
Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of
CONFIG_PPC_4K_PAGES, getting the following build failure:
CC mm/gup.o
In file included from ./include/linux/kernel.h:11:0,
from mm/gup.c:2:
In function 'gup_hugepte.constprop',
inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8:
./include/linux/compiler.h:392:38: error: call to
'__compiletime_assert_257' declared with attribute error: Unsupported
access size for {READ,WRITE}_ONCE().
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:373:4: note: in definition of macro
'__compiletime_assert'
prefix ## suffix(); \
^
./include/linux/compiler.h:392:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:405:2: note: in expansion of macro
'compiletime_assert'
compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
^
./include/linux/compiler.h:291:2: note: in expansion of macro
'compiletime_assert_rwonce_type'
compiletime_assert_rwonce_type(x); \
^
mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE'
pte = READ_ONCE(*ptep);
^
In function 'gup_get_pte',
inlined from 'gup_pte_range' at mm/gup.c:2228:9,
inlined from 'gup_pmd_range' at mm/gup.c:2613:15,
inlined from 'gup_pud_range' at mm/gup.c:2641:15,
inlined from 'gup_p4d_range' at mm/gup.c:2666:15,
inlined from 'gup_pgd_range' at mm/gup.c:2694:15,
inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3:
./include/linux/compiler.h:392:38: error: call to
'__compiletime_assert_254' declared with attribute error: Unsupported
access size for {READ,WRITE}_ONCE().
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:373:4: note: in definition of macro
'__compiletime_assert'
prefix ## suffix(); \
^
./include/linux/compiler.h:392:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:405:2: note: in expansion of macro
'compiletime_assert'
compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
^
./include/linux/compiler.h:291:2: note: in expansion of macro
'compiletime_assert_rwonce_type'
compiletime_assert_rwonce_type(x); \
^
mm/gup.c:2199:9: note: in expansion of macro 'READ_ONCE'
return READ_ONCE(*ptep);
^
make[2]: *** [mm/gup.o] Error 1
Bisected to:
2ab3a0a02905 (HEAD, refs/bisect/bad) READ_ONCE: Enforce atomicity for
{READ,WRITE}_ONCE() memory accesses
Christophe
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: linux-next: build failure on powerpc 8xx with 16k pages 2020-06-04 10:48 linux-next: build failure on powerpc 8xx with 16k pages Christophe Leroy @ 2020-06-04 11:17 ` Will Deacon 0 siblings, 0 replies; 11+ messages in thread From: Will Deacon @ 2020-06-04 11:17 UTC (permalink / raw) To: Christophe Leroy Cc: Andrew Morton, Michael Ellerman, PowerPC, Thomas Gleixner, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, peterz Hi, [+Peter] On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: > Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of > CONFIG_PPC_4K_PAGES, getting the following build failure: > > CC mm/gup.o > In file included from ./include/linux/kernel.h:11:0, > from mm/gup.c:2: > In function 'gup_hugepte.constprop', > inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: > ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' > declared with attribute error: Unsupported access size for > {READ,WRITE}_ONCE(). > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:373:4: note: in definition of macro > '__compiletime_assert' > prefix ## suffix(); \ > ^ > ./include/linux/compiler.h:392:2: note: in expansion of macro > '_compiletime_assert' > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:405:2: note: in expansion of macro > 'compiletime_assert' > compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ > ^ > ./include/linux/compiler.h:291:2: note: in expansion of macro > 'compiletime_assert_rwonce_type' > compiletime_assert_rwonce_type(x); \ > ^ > mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' > pte = READ_ONCE(*ptep); > ^ > In function 'gup_get_pte', > inlined from 'gup_pte_range' at mm/gup.c:2228:9, > inlined from 'gup_pmd_range' at mm/gup.c:2613:15, > inlined from 'gup_pud_range' at mm/gup.c:2641:15, > inlined from 'gup_p4d_range' at mm/gup.c:2666:15, > inlined from 'gup_pgd_range' at mm/gup.c:2694:15, > inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: At first glance, this looks like a real bug in the 16k page code -- you're loading the pte non-atomically on the fast GUP path and so you're prone to tearing, which probably isn't what you want. For a short-term hack, I'd suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if you want to support this them you'll need to rework your pte_t so that it can be loaded atomically. Will ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages @ 2020-06-04 11:17 ` Will Deacon 0 siblings, 0 replies; 11+ messages in thread From: Will Deacon @ 2020-06-04 11:17 UTC (permalink / raw) To: Christophe Leroy Cc: Stephen Rothwell, peterz, Linux Kernel Mailing List, Linux Next Mailing List, Andrew Morton, PowerPC, Thomas Gleixner Hi, [+Peter] On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: > Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of > CONFIG_PPC_4K_PAGES, getting the following build failure: > > CC mm/gup.o > In file included from ./include/linux/kernel.h:11:0, > from mm/gup.c:2: > In function 'gup_hugepte.constprop', > inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: > ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' > declared with attribute error: Unsupported access size for > {READ,WRITE}_ONCE(). > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:373:4: note: in definition of macro > '__compiletime_assert' > prefix ## suffix(); \ > ^ > ./include/linux/compiler.h:392:2: note: in expansion of macro > '_compiletime_assert' > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:405:2: note: in expansion of macro > 'compiletime_assert' > compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ > ^ > ./include/linux/compiler.h:291:2: note: in expansion of macro > 'compiletime_assert_rwonce_type' > compiletime_assert_rwonce_type(x); \ > ^ > mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' > pte = READ_ONCE(*ptep); > ^ > In function 'gup_get_pte', > inlined from 'gup_pte_range' at mm/gup.c:2228:9, > inlined from 'gup_pmd_range' at mm/gup.c:2613:15, > inlined from 'gup_pud_range' at mm/gup.c:2641:15, > inlined from 'gup_p4d_range' at mm/gup.c:2666:15, > inlined from 'gup_pgd_range' at mm/gup.c:2694:15, > inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: At first glance, this looks like a real bug in the 16k page code -- you're loading the pte non-atomically on the fast GUP path and so you're prone to tearing, which probably isn't what you want. For a short-term hack, I'd suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if you want to support this them you'll need to rework your pte_t so that it can be loaded atomically. Will ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages 2020-06-04 11:17 ` Will Deacon @ 2020-06-04 12:00 ` Peter Zijlstra -1 siblings, 0 replies; 11+ messages in thread From: Peter Zijlstra @ 2020-06-04 12:00 UTC (permalink / raw) To: Will Deacon Cc: Christophe Leroy, Andrew Morton, Michael Ellerman, PowerPC, Thomas Gleixner, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List On Thu, Jun 04, 2020 at 12:17:23PM +0100, Will Deacon wrote: > Hi, [+Peter] > > On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: > > Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of > > CONFIG_PPC_4K_PAGES, getting the following build failure: > > > > CC mm/gup.o > > In file included from ./include/linux/kernel.h:11:0, > > from mm/gup.c:2: > > In function 'gup_hugepte.constprop', > > inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: > > ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' > > declared with attribute error: Unsupported access size for > > {READ,WRITE}_ONCE(). > > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > ^ > > ./include/linux/compiler.h:373:4: note: in definition of macro > > '__compiletime_assert' > > prefix ## suffix(); \ > > ^ > > ./include/linux/compiler.h:392:2: note: in expansion of macro > > '_compiletime_assert' > > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > ^ > > ./include/linux/compiler.h:405:2: note: in expansion of macro > > 'compiletime_assert' > > compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ > > ^ > > ./include/linux/compiler.h:291:2: note: in expansion of macro > > 'compiletime_assert_rwonce_type' > > compiletime_assert_rwonce_type(x); \ > > ^ > > mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' > > pte = READ_ONCE(*ptep); > > ^ > > In function 'gup_get_pte', > > inlined from 'gup_pte_range' at mm/gup.c:2228:9, > > inlined from 'gup_pmd_range' at mm/gup.c:2613:15, > > inlined from 'gup_pud_range' at mm/gup.c:2641:15, > > inlined from 'gup_p4d_range' at mm/gup.c:2666:15, > > inlined from 'gup_pgd_range' at mm/gup.c:2694:15, > > inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: > > At first glance, this looks like a real bug in the 16k page code -- you're > loading the pte non-atomically on the fast GUP path and so you're prone to > tearing, which probably isn't what you want. For a short-term hack, I'd > suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if > you want to support this them you'll need to rework your pte_t so that it > can be loaded atomically. Looking at commit 55c8fc3f49302, they're all the exact same value, so what they could do is grow another special gup_get_pte() variant that just loads the first value. Also, per that very same commit, there's a distinct lack of WRITE_ONCE() in the pte_update() / __set_pte_at() paths for much of Power. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages @ 2020-06-04 12:00 ` Peter Zijlstra 0 siblings, 0 replies; 11+ messages in thread From: Peter Zijlstra @ 2020-06-04 12:00 UTC (permalink / raw) To: Will Deacon Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List, Andrew Morton, PowerPC, Thomas Gleixner On Thu, Jun 04, 2020 at 12:17:23PM +0100, Will Deacon wrote: > Hi, [+Peter] > > On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: > > Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of > > CONFIG_PPC_4K_PAGES, getting the following build failure: > > > > CC mm/gup.o > > In file included from ./include/linux/kernel.h:11:0, > > from mm/gup.c:2: > > In function 'gup_hugepte.constprop', > > inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: > > ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' > > declared with attribute error: Unsupported access size for > > {READ,WRITE}_ONCE(). > > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > ^ > > ./include/linux/compiler.h:373:4: note: in definition of macro > > '__compiletime_assert' > > prefix ## suffix(); \ > > ^ > > ./include/linux/compiler.h:392:2: note: in expansion of macro > > '_compiletime_assert' > > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > ^ > > ./include/linux/compiler.h:405:2: note: in expansion of macro > > 'compiletime_assert' > > compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ > > ^ > > ./include/linux/compiler.h:291:2: note: in expansion of macro > > 'compiletime_assert_rwonce_type' > > compiletime_assert_rwonce_type(x); \ > > ^ > > mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' > > pte = READ_ONCE(*ptep); > > ^ > > In function 'gup_get_pte', > > inlined from 'gup_pte_range' at mm/gup.c:2228:9, > > inlined from 'gup_pmd_range' at mm/gup.c:2613:15, > > inlined from 'gup_pud_range' at mm/gup.c:2641:15, > > inlined from 'gup_p4d_range' at mm/gup.c:2666:15, > > inlined from 'gup_pgd_range' at mm/gup.c:2694:15, > > inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: > > At first glance, this looks like a real bug in the 16k page code -- you're > loading the pte non-atomically on the fast GUP path and so you're prone to > tearing, which probably isn't what you want. For a short-term hack, I'd > suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if > you want to support this them you'll need to rework your pte_t so that it > can be loaded atomically. Looking at commit 55c8fc3f49302, they're all the exact same value, so what they could do is grow another special gup_get_pte() variant that just loads the first value. Also, per that very same commit, there's a distinct lack of WRITE_ONCE() in the pte_update() / __set_pte_at() paths for much of Power. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages 2020-06-04 12:00 ` Peter Zijlstra @ 2020-06-04 14:35 ` Christophe Leroy -1 siblings, 0 replies; 11+ messages in thread From: Christophe Leroy @ 2020-06-04 14:35 UTC (permalink / raw) To: Peter Zijlstra, Will Deacon Cc: Andrew Morton, Michael Ellerman, PowerPC, Thomas Gleixner, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List On 06/04/2020 12:00 PM, Peter Zijlstra wrote: > On Thu, Jun 04, 2020 at 12:17:23PM +0100, Will Deacon wrote: >> Hi, [+Peter] >> >> On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: >>> Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of >>> CONFIG_PPC_4K_PAGES, getting the following build failure: >>> >>> CC mm/gup.o >>> In file included from ./include/linux/kernel.h:11:0, >>> from mm/gup.c:2: >>> In function 'gup_hugepte.constprop', >>> inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: >>> ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' >>> declared with attribute error: Unsupported access size for >>> {READ,WRITE}_ONCE(). >>> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >>> ^ >>> ./include/linux/compiler.h:373:4: note: in definition of macro >>> '__compiletime_assert' >>> prefix ## suffix(); \ >>> ^ >>> ./include/linux/compiler.h:392:2: note: in expansion of macro >>> '_compiletime_assert' >>> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >>> ^ >>> ./include/linux/compiler.h:405:2: note: in expansion of macro >>> 'compiletime_assert' >>> compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ >>> ^ >>> ./include/linux/compiler.h:291:2: note: in expansion of macro >>> 'compiletime_assert_rwonce_type' >>> compiletime_assert_rwonce_type(x); \ >>> ^ >>> mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' >>> pte = READ_ONCE(*ptep); >>> ^ >>> In function 'gup_get_pte', >>> inlined from 'gup_pte_range' at mm/gup.c:2228:9, >>> inlined from 'gup_pmd_range' at mm/gup.c:2613:15, >>> inlined from 'gup_pud_range' at mm/gup.c:2641:15, >>> inlined from 'gup_p4d_range' at mm/gup.c:2666:15, >>> inlined from 'gup_pgd_range' at mm/gup.c:2694:15, >>> inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: >> >> At first glance, this looks like a real bug in the 16k page code -- you're >> loading the pte non-atomically on the fast GUP path and so you're prone to >> tearing, which probably isn't what you want. For a short-term hack, I'd >> suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if >> you want to support this them you'll need to rework your pte_t so that it >> can be loaded atomically. > > Looking at commit 55c8fc3f49302, they're all the exact same value, so > what they could do is grow another special gup_get_pte() variant that > just loads the first value. > > Also, per that very same commit, there's a distinct lack of WRITE_ONCE() > in the pte_update() / __set_pte_at() paths for much of Power. > Thanks for the idea. Now I get the same issue at CC mm/mincore.o In file included from ./include/asm-generic/bug.h:5:0, from ./arch/powerpc/include/asm/bug.h:109, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:9, from ./include/linux/pagemap.h:8, from mm/mincore.c:11: In function 'huge_ptep_get', inlined from 'mincore_hugetlb' at mm/mincore.c:35:20: ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_218' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE(). _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert' prefix ## suffix(); \ ^ ./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ./include/linux/compiler.h:405:2: note: in expansion of macro 'compiletime_assert' compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ ^ ./include/linux/compiler.h:291:2: note: in expansion of macro 'compiletime_assert_rwonce_type' compiletime_assert_rwonce_type(x); \ ^ ./include/asm-generic/hugetlb.h:125:9: note: in expansion of macro 'READ_ONCE' return READ_ONCE(*ptep); ^ make[2]: *** [mm/mincore.o] Error 1 I guess for this one I have to implement platform specific huge_ptep_get() Christophe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages @ 2020-06-04 14:35 ` Christophe Leroy 0 siblings, 0 replies; 11+ messages in thread From: Christophe Leroy @ 2020-06-04 14:35 UTC (permalink / raw) To: Peter Zijlstra, Will Deacon Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List, Andrew Morton, PowerPC, Thomas Gleixner On 06/04/2020 12:00 PM, Peter Zijlstra wrote: > On Thu, Jun 04, 2020 at 12:17:23PM +0100, Will Deacon wrote: >> Hi, [+Peter] >> >> On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: >>> Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of >>> CONFIG_PPC_4K_PAGES, getting the following build failure: >>> >>> CC mm/gup.o >>> In file included from ./include/linux/kernel.h:11:0, >>> from mm/gup.c:2: >>> In function 'gup_hugepte.constprop', >>> inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: >>> ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' >>> declared with attribute error: Unsupported access size for >>> {READ,WRITE}_ONCE(). >>> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >>> ^ >>> ./include/linux/compiler.h:373:4: note: in definition of macro >>> '__compiletime_assert' >>> prefix ## suffix(); \ >>> ^ >>> ./include/linux/compiler.h:392:2: note: in expansion of macro >>> '_compiletime_assert' >>> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >>> ^ >>> ./include/linux/compiler.h:405:2: note: in expansion of macro >>> 'compiletime_assert' >>> compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ >>> ^ >>> ./include/linux/compiler.h:291:2: note: in expansion of macro >>> 'compiletime_assert_rwonce_type' >>> compiletime_assert_rwonce_type(x); \ >>> ^ >>> mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' >>> pte = READ_ONCE(*ptep); >>> ^ >>> In function 'gup_get_pte', >>> inlined from 'gup_pte_range' at mm/gup.c:2228:9, >>> inlined from 'gup_pmd_range' at mm/gup.c:2613:15, >>> inlined from 'gup_pud_range' at mm/gup.c:2641:15, >>> inlined from 'gup_p4d_range' at mm/gup.c:2666:15, >>> inlined from 'gup_pgd_range' at mm/gup.c:2694:15, >>> inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: >> >> At first glance, this looks like a real bug in the 16k page code -- you're >> loading the pte non-atomically on the fast GUP path and so you're prone to >> tearing, which probably isn't what you want. For a short-term hack, I'd >> suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if >> you want to support this them you'll need to rework your pte_t so that it >> can be loaded atomically. > > Looking at commit 55c8fc3f49302, they're all the exact same value, so > what they could do is grow another special gup_get_pte() variant that > just loads the first value. > > Also, per that very same commit, there's a distinct lack of WRITE_ONCE() > in the pte_update() / __set_pte_at() paths for much of Power. > Thanks for the idea. Now I get the same issue at CC mm/mincore.o In file included from ./include/asm-generic/bug.h:5:0, from ./arch/powerpc/include/asm/bug.h:109, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:9, from ./include/linux/pagemap.h:8, from mm/mincore.c:11: In function 'huge_ptep_get', inlined from 'mincore_hugetlb' at mm/mincore.c:35:20: ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_218' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE(). _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert' prefix ## suffix(); \ ^ ./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ./include/linux/compiler.h:405:2: note: in expansion of macro 'compiletime_assert' compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ ^ ./include/linux/compiler.h:291:2: note: in expansion of macro 'compiletime_assert_rwonce_type' compiletime_assert_rwonce_type(x); \ ^ ./include/asm-generic/hugetlb.h:125:9: note: in expansion of macro 'READ_ONCE' return READ_ONCE(*ptep); ^ make[2]: *** [mm/mincore.o] Error 1 I guess for this one I have to implement platform specific huge_ptep_get() Christophe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages 2020-06-04 14:35 ` Christophe Leroy @ 2020-06-04 16:10 ` Will Deacon -1 siblings, 0 replies; 11+ messages in thread From: Will Deacon @ 2020-06-04 16:10 UTC (permalink / raw) To: Christophe Leroy Cc: Peter Zijlstra, Andrew Morton, Michael Ellerman, PowerPC, Thomas Gleixner, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, arnd [+Arnd since I think we spoke about this on IRC once] On Thu, Jun 04, 2020 at 02:35:14PM +0000, Christophe Leroy wrote: > Now I get the same issue at > > CC mm/mincore.o > In file included from ./include/asm-generic/bug.h:5:0, > from ./arch/powerpc/include/asm/bug.h:109, > from ./include/linux/bug.h:5, > from ./include/linux/mmdebug.h:5, > from ./include/linux/mm.h:9, > from ./include/linux/pagemap.h:8, > from mm/mincore.c:11: > In function 'huge_ptep_get', > inlined from 'mincore_hugetlb' at mm/mincore.c:35:20: > ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_218' > declared with attribute error: Unsupported access size for > {READ,WRITE}_ONCE(). > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:373:4: note: in definition of macro > '__compiletime_assert' > prefix ## suffix(); \ > ^ > ./include/linux/compiler.h:392:2: note: in expansion of macro > '_compiletime_assert' > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:405:2: note: in expansion of macro > 'compiletime_assert' > compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ > ^ > ./include/linux/compiler.h:291:2: note: in expansion of macro > 'compiletime_assert_rwonce_type' > compiletime_assert_rwonce_type(x); \ > ^ > ./include/asm-generic/hugetlb.h:125:9: note: in expansion of macro > 'READ_ONCE' > return READ_ONCE(*ptep); > ^ > make[2]: *** [mm/mincore.o] Error 1 > > I guess for this one I have to implement platform specific huge_ptep_get() Yeah, or bite the bullet and introduce proper accessors for all these things: pte_read() pmd_read() pud_read() etc with the default implementation pointing at READ_ONCE(), but allowing an architecture override. It's a big job because mm/ would need repainting, but it would have the benefit of being able to remove aggregate types from READ_ONCE() entirely and using a special accessor just for the page-table types. That might also mean that we could have asm-generic versions of things like ptep_get_and_clear() that work for architectures with hardware update and need atomic rmw. But I'm getting ahead of myself. Will ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages @ 2020-06-04 16:10 ` Will Deacon 0 siblings, 0 replies; 11+ messages in thread From: Will Deacon @ 2020-06-04 16:10 UTC (permalink / raw) To: Christophe Leroy Cc: Stephen Rothwell, arnd, Peter Zijlstra, Linux Kernel Mailing List, Linux Next Mailing List, Andrew Morton, PowerPC, Thomas Gleixner [+Arnd since I think we spoke about this on IRC once] On Thu, Jun 04, 2020 at 02:35:14PM +0000, Christophe Leroy wrote: > Now I get the same issue at > > CC mm/mincore.o > In file included from ./include/asm-generic/bug.h:5:0, > from ./arch/powerpc/include/asm/bug.h:109, > from ./include/linux/bug.h:5, > from ./include/linux/mmdebug.h:5, > from ./include/linux/mm.h:9, > from ./include/linux/pagemap.h:8, > from mm/mincore.c:11: > In function 'huge_ptep_get', > inlined from 'mincore_hugetlb' at mm/mincore.c:35:20: > ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_218' > declared with attribute error: Unsupported access size for > {READ,WRITE}_ONCE(). > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:373:4: note: in definition of macro > '__compiletime_assert' > prefix ## suffix(); \ > ^ > ./include/linux/compiler.h:392:2: note: in expansion of macro > '_compiletime_assert' > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ./include/linux/compiler.h:405:2: note: in expansion of macro > 'compiletime_assert' > compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ > ^ > ./include/linux/compiler.h:291:2: note: in expansion of macro > 'compiletime_assert_rwonce_type' > compiletime_assert_rwonce_type(x); \ > ^ > ./include/asm-generic/hugetlb.h:125:9: note: in expansion of macro > 'READ_ONCE' > return READ_ONCE(*ptep); > ^ > make[2]: *** [mm/mincore.o] Error 1 > > I guess for this one I have to implement platform specific huge_ptep_get() Yeah, or bite the bullet and introduce proper accessors for all these things: pte_read() pmd_read() pud_read() etc with the default implementation pointing at READ_ONCE(), but allowing an architecture override. It's a big job because mm/ would need repainting, but it would have the benefit of being able to remove aggregate types from READ_ONCE() entirely and using a special accessor just for the page-table types. That might also mean that we could have asm-generic versions of things like ptep_get_and_clear() that work for architectures with hardware update and need atomic rmw. But I'm getting ahead of myself. Will ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages 2020-06-04 11:17 ` Will Deacon @ 2020-06-04 13:55 ` Christophe Leroy -1 siblings, 0 replies; 11+ messages in thread From: Christophe Leroy @ 2020-06-04 13:55 UTC (permalink / raw) To: Will Deacon Cc: Andrew Morton, Michael Ellerman, PowerPC, Thomas Gleixner, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, peterz On 06/04/2020 11:17 AM, Will Deacon wrote: > Hi, [+Peter] > > On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: >> Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of >> CONFIG_PPC_4K_PAGES, getting the following build failure: >> >> CC mm/gup.o >> In file included from ./include/linux/kernel.h:11:0, >> from mm/gup.c:2: >> In function 'gup_hugepte.constprop', >> inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: >> ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' >> declared with attribute error: Unsupported access size for >> {READ,WRITE}_ONCE(). >> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >> ^ >> ./include/linux/compiler.h:373:4: note: in definition of macro >> '__compiletime_assert' >> prefix ## suffix(); \ >> ^ >> ./include/linux/compiler.h:392:2: note: in expansion of macro >> '_compiletime_assert' >> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >> ^ >> ./include/linux/compiler.h:405:2: note: in expansion of macro >> 'compiletime_assert' >> compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ >> ^ >> ./include/linux/compiler.h:291:2: note: in expansion of macro >> 'compiletime_assert_rwonce_type' >> compiletime_assert_rwonce_type(x); \ >> ^ >> mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' >> pte = READ_ONCE(*ptep); >> ^ >> In function 'gup_get_pte', >> inlined from 'gup_pte_range' at mm/gup.c:2228:9, >> inlined from 'gup_pmd_range' at mm/gup.c:2613:15, >> inlined from 'gup_pud_range' at mm/gup.c:2641:15, >> inlined from 'gup_p4d_range' at mm/gup.c:2666:15, >> inlined from 'gup_pgd_range' at mm/gup.c:2694:15, >> inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: > > At first glance, this looks like a real bug in the 16k page code -- you're > loading the pte non-atomically on the fast GUP path and so you're prone to > tearing, which probably isn't what you want. For a short-term hack, I'd > suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if > you want to support this them you'll need to rework your pte_t so that it > can be loaded atomically. What do you mean by *rework* pte_t ? pte are 32 bits words in size and are spread every 4 words in memory. Therefore pte_t has to be 128 bits because unlike huge_pte handling which always use huge_pte_offset() in loops, many many places in the kernel do pte++, so we need the pte type to be the size of the interval from one pte to the next one. Christophe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: linux-next: build failure on powerpc 8xx with 16k pages @ 2020-06-04 13:55 ` Christophe Leroy 0 siblings, 0 replies; 11+ messages in thread From: Christophe Leroy @ 2020-06-04 13:55 UTC (permalink / raw) To: Will Deacon Cc: Stephen Rothwell, peterz, Linux Kernel Mailing List, Linux Next Mailing List, Andrew Morton, PowerPC, Thomas Gleixner On 06/04/2020 11:17 AM, Will Deacon wrote: > Hi, [+Peter] > > On Thu, Jun 04, 2020 at 10:48:03AM +0000, Christophe Leroy wrote: >> Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of >> CONFIG_PPC_4K_PAGES, getting the following build failure: >> >> CC mm/gup.o >> In file included from ./include/linux/kernel.h:11:0, >> from mm/gup.c:2: >> In function 'gup_hugepte.constprop', >> inlined from 'gup_huge_pd.isra.78' at mm/gup.c:2465:8: >> ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_257' >> declared with attribute error: Unsupported access size for >> {READ,WRITE}_ONCE(). >> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >> ^ >> ./include/linux/compiler.h:373:4: note: in definition of macro >> '__compiletime_assert' >> prefix ## suffix(); \ >> ^ >> ./include/linux/compiler.h:392:2: note: in expansion of macro >> '_compiletime_assert' >> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) >> ^ >> ./include/linux/compiler.h:405:2: note: in expansion of macro >> 'compiletime_assert' >> compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \ >> ^ >> ./include/linux/compiler.h:291:2: note: in expansion of macro >> 'compiletime_assert_rwonce_type' >> compiletime_assert_rwonce_type(x); \ >> ^ >> mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE' >> pte = READ_ONCE(*ptep); >> ^ >> In function 'gup_get_pte', >> inlined from 'gup_pte_range' at mm/gup.c:2228:9, >> inlined from 'gup_pmd_range' at mm/gup.c:2613:15, >> inlined from 'gup_pud_range' at mm/gup.c:2641:15, >> inlined from 'gup_p4d_range' at mm/gup.c:2666:15, >> inlined from 'gup_pgd_range' at mm/gup.c:2694:15, >> inlined from 'internal_get_user_pages_fast' at mm/gup.c:2785:3: > > At first glance, this looks like a real bug in the 16k page code -- you're > loading the pte non-atomically on the fast GUP path and so you're prone to > tearing, which probably isn't what you want. For a short-term hack, I'd > suggest having CONFIG_HAVE_FAST_GUP depend on !CONFIG_PPC_16K_PAGES, but if > you want to support this them you'll need to rework your pte_t so that it > can be loaded atomically. What do you mean by *rework* pte_t ? pte are 32 bits words in size and are spread every 4 words in memory. Therefore pte_t has to be 128 bits because unlike huge_pte handling which always use huge_pte_offset() in loops, many many places in the kernel do pte++, so we need the pte type to be the size of the interval from one pte to the next one. Christophe ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-06-04 16:12 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-04 10:48 linux-next: build failure on powerpc 8xx with 16k pages Christophe Leroy 2020-06-04 11:17 ` Will Deacon 2020-06-04 11:17 ` Will Deacon 2020-06-04 12:00 ` Peter Zijlstra 2020-06-04 12:00 ` Peter Zijlstra 2020-06-04 14:35 ` Christophe Leroy 2020-06-04 14:35 ` Christophe Leroy 2020-06-04 16:10 ` Will Deacon 2020-06-04 16:10 ` Will Deacon 2020-06-04 13:55 ` Christophe Leroy 2020-06-04 13:55 ` Christophe Leroy
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.