Hi Andrew,
After merging the akpm tree, today's linux-next build (sparc defconfig)
failed like this:
In file included from mm/vmscan.c:55:0:
include/linux/swapops.h: In function 'swp_entry_to_pmd':
include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
return __pmd(0);
^
include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected
Caused by commit
9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
It looks like sparc 32 bit has no __pmd() ...
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
Hi all,
On Tue, 1 Aug 2017 16:39:04 +1000 Stephen Rothwell <[email protected]> wrote:
>
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> failed like this:
>
> In file included from mm/vmscan.c:55:0:
> include/linux/swapops.h: In function 'swp_entry_to_pmd':
> include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
> return __pmd(0);
> ^
> include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected
>
> Caused by commit
>
> 9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
>
> It looks like sparc 32 bit has no __pmd() ...
>
> I have reverted that commit for today.
OK, that is a pain as it causes many build warnings some of which are
treated as errors :-( (see e.g.
http://kisskb.ellerman.id.au/kisskb/buildresult/13112192/). So maybe
we need to fix sthe sparc32 build instead? Are there any other
architectures/platforms that do not define __pmd() ?
--
Cheers,
Stephen Rothwell
Hi Stephen,
The warning after removing __pmd() is caused by a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
so (pmd_t) {0} causes warning in some GCC versions.
__pmd() is defined in alpha, arm, arm64, frv, ia64, m32r, m68k, microblaze, mips, parisc,
powerpc, s390, sh, sparc, tile, um, x86, and asm-generic, according to
http://elixir.free-electrons.com/linux/latest/ident/__pmd
I am not sure about whether arc, blackfin, c6x, cris, h8300, hexagon, metag, mn10300, nios2, score,
xtensa use __pmd() in asm-generic or not.
I am looking for other workarounds for this warning now.
—
Best Regards,
Yan Zi
On 1 Aug 2017, at 6:50, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 1 Aug 2017 16:39:04 +1000 Stephen Rothwell <[email protected]> wrote:
>>
>> After merging the akpm tree, today's linux-next build (sparc defconfig)
>> failed like this:
>>
>> In file included from mm/vmscan.c:55:0:
>> include/linux/swapops.h: In function 'swp_entry_to_pmd':
>> include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
>> return __pmd(0);
>> ^
>> include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected
>>
>> Caused by commit
>>
>> 9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
>>
>> It looks like sparc 32 bit has no __pmd() ...
>>
>> I have reverted that commit for today.
>
> OK, that is a pain as it causes many build warnings some of which are
> treated as errors :-( (see e.g.
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkisskb.ellerman.id.au%2Fkisskb%2Fbuildresult%2F13112192%2F&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7Cbf7a7ad57ad04505172f08d4d8cb31c5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636371814609835949&sdata=diTid245prNY3Jy1pPEaL5q8dSBifFVzliKRq54fXhk%3D&reserved=0). So maybe
> we need to fix sthe sparc32 build instead? Are there any other
> architectures/platforms that do not define __pmd() ?
>
> --
> Cheers,
> Stephen Rothwell
Hi Stephen,
I found two possible fixes.
1. This uses C++ zero initializer, GCC is OK with it.
I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
--- a/include/linux/swapops.h~a
+++ a/include/linux/swapops.h
@@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
{
- return (pmd_t){ 0 };
+ return (pmd_t){};
}
static inline int is_pmd_migration_entry(pmd_t pmd)
2. This is ugly but working.
It works with GCC 4.9.3 and GCC 6.4.0.
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -219,7 +219,10 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
{
- return (pmd_t){ 0 };
+ pmd_t e;
+ memset(&e, 0, sizeof(pmd_t));
+ return e;
}
static inline int is_pmd_migration_entry(pmd_t pmd)
—
Best Regards,
Yan Zi
On 1 Aug 2017, at 7:30, Zi Yan wrote:
> Hi Stephen,
>
> The warning after removing __pmd() is caused by a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
> so (pmd_t) {0} causes warning in some GCC versions.
>
> __pmd() is defined in alpha, arm, arm64, frv, ia64, m32r, m68k, microblaze, mips, parisc,
> powerpc, s390, sh, sparc, tile, um, x86, and asm-generic, according to
> http://elixir.free-electrons.com/linux/latest/ident/__pmd
>
> I am not sure about whether arc, blackfin, c6x, cris, h8300, hexagon, metag, mn10300, nios2, score,
> xtensa use __pmd() in asm-generic or not.
>
> I am looking for other workarounds for this warning now.
>
>
> —
> Best Regards,
> Yan Zi
>
> On 1 Aug 2017, at 6:50, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> On Tue, 1 Aug 2017 16:39:04 +1000 Stephen Rothwell <[email protected]> wrote:
>>>
>>> After merging the akpm tree, today's linux-next build (sparc defconfig)
>>> failed like this:
>>>
>>> In file included from mm/vmscan.c:55:0:
>>> include/linux/swapops.h: In function 'swp_entry_to_pmd':
>>> include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
>>> return __pmd(0);
>>> ^
>>> include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected
>>>
>>> Caused by commit
>>>
>>> 9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
>>>
>>> It looks like sparc 32 bit has no __pmd() ...
>>>
>>> I have reverted that commit for today.
>>
>> OK, that is a pain as it causes many build warnings some of which are
>> treated as errors :-( (see e.g.
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkisskb.ellerman.id.au%2Fkisskb%2Fbuildresult%2F13112192%2F&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7Cbf7a7ad57ad04505172f08d4d8cb31c5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636371814609835949&sdata=diTid245prNY3Jy1pPEaL5q8dSBifFVzliKRq54fXhk%3D&reserved=0). So maybe
>> we need to fix sthe sparc32 build instead? Are there any other
>> architectures/platforms that do not define __pmd() ?
>>
>> --
>> Cheers,
>> Stephen Rothwell
Hi Zi,
On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <[email protected]> wrote:
>
> I found two possible fixes.
>
> 1. This uses C++ zero initializer, GCC is OK with it.
> I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
>
> --- a/include/linux/swapops.h~a
> +++ a/include/linux/swapops.h
> @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
>
> static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> {
> - return (pmd_t){ 0 };
> + return (pmd_t){};
> }
I have done that for today ... please decide which is best (or find
something better - maybe every platform really needs to have a __pmd()
definition) and submit a real fix patch to Andrew.
--
Cheers,
Stephen Rothwell
Hi all,
On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <[email protected]> wrote:
>
> On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <[email protected]> wrote:
> >
> > I found two possible fixes.
> >
> > 1. This uses C++ zero initializer, GCC is OK with it.
> > I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> >
> > --- a/include/linux/swapops.h~a
> > +++ a/include/linux/swapops.h
> > @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
> >
> > static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> > {
> > - return (pmd_t){ 0 };
> > + return (pmd_t){};
> > }
>
> I have done that for today ... please decide which is best (or find
> something better - maybe every platform really needs to have a __pmd()
> definition) and submit a real fix patch to Andrew.
OK, that failed for my compiler (gcc 5.2.0) like this:
In file included from mm/vmscan.c:55:0:
include/linux/swapops.h: In function 'swp_entry_to_pmd':
include/linux/swapops.h:226:16: error: empty scalar initializer
return (pmd_t){};
^
include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')
So I used the other idea (on top of Andrew's current tree):
From: Stephen Rothwell <[email protected]>
Date: Wed, 2 Aug 2017 15:55:02 +1000
Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
Signed-off-by: Stephen Rothwell <[email protected]>
---
include/linux/swapops.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 45b092aa6419..61cffa148a79 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
{
- return __pmd(0);
+ pmd_t e;
+ memset(&e, 0, sizeof(pmd_t));
+ return e;
}
static inline int is_pmd_migration_entry(pmd_t pmd)
--
2.13.2
--
Cheers,
Stephen Rothwell
Hi all,
On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell <[email protected]> wrote:
>
> On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <[email protected]> wrote:
> >
> > On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <[email protected]> wrote:
> > >
> > > I found two possible fixes.
> > >
> > > 1. This uses C++ zero initializer, GCC is OK with it.
> > > I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> > >
> > > --- a/include/linux/swapops.h~a
> > > +++ a/include/linux/swapops.h
> > > @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
> > >
> > > static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> > > {
> > > - return (pmd_t){ 0 };
> > > + return (pmd_t){};
> > > }
> >
> > I have done that for today ... please decide which is best (or find
> > something better - maybe every platform really needs to have a __pmd()
> > definition) and submit a real fix patch to Andrew.
>
> OK, that failed for my compiler (gcc 5.2.0) like this:
>
> In file included from mm/vmscan.c:55:0:
> include/linux/swapops.h: In function 'swp_entry_to_pmd':
> include/linux/swapops.h:226:16: error: empty scalar initializer
> return (pmd_t){};
> ^
> include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')
This has reappeared today :-( (for the arm multi_v7_defconfig build at
least)
> So I used the other idea (on top of Andrew's current tree):
The fix patch now looks like this:
From: Stephen Rothwell <[email protected]>
Date: Wed, 2 Aug 2017 15:55:02 +1000
Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
Signed-off-by: Stephen Rothwell <[email protected]>
---
include/linux/swapops.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 45b092aa6419..61cffa148a79 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
{
- return (pmd_t){};
+ pmd_t e;
+ memset(&e, 0, sizeof(pmd_t));
+ return e;
}
static inline int is_pmd_migration_entry(pmd_t pmd)
--
Cheers,
Stephen Rothwell
On Thu, 7 Sep 2017 15:23:55 +1000 Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell <[email protected]> wrote:
> >
> > On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <[email protected]> wrote:
> > >
> > > On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <[email protected]> wrote:
> > > >
> > > > I found two possible fixes.
> > > >
> > > > 1. This uses C++ zero initializer, GCC is OK with it.
> > > > I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> > > >
> > > > --- a/include/linux/swapops.h~a
> > > > +++ a/include/linux/swapops.h
> > > > @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
> > > >
> > > > static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> > > > {
> > > > - return (pmd_t){ 0 };
> > > > + return (pmd_t){};
> > > > }
> > >
> > > I have done that for today ... please decide which is best (or find
> > > something better - maybe every platform really needs to have a __pmd()
> > > definition) and submit a real fix patch to Andrew.
> >
> > OK, that failed for my compiler (gcc 5.2.0) like this:
> >
> > In file included from mm/vmscan.c:55:0:
> > include/linux/swapops.h: In function 'swp_entry_to_pmd':
> > include/linux/swapops.h:226:16: error: empty scalar initializer
> > return (pmd_t){};
> > ^
> > include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')
>
> This has reappeared today :-( (for the arm multi_v7_defconfig build at
> least)
>
> > So I used the other idea (on top of Andrew's current tree):
>
> The fix patch now looks like this:
>
> From: Stephen Rothwell <[email protected]>
> Date: Wed, 2 Aug 2017 15:55:02 +1000
> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
>
> Signed-off-by: Stephen Rothwell <[email protected]>
> ---
> include/linux/swapops.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index 45b092aa6419..61cffa148a79 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>
> static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> {
> - return (pmd_t){};
> + pmd_t e;
> + memset(&e, 0, sizeof(pmd_t));
> + return e;
> }
err, yeah. I didn't want to add that one :(
At the very least we should add a good comment explaining why we had to
resort to this.
On 7 Sep 2017, at 3:46, Andrew Morton wrote:
> On Thu, 7 Sep 2017 15:23:55 +1000 Stephen Rothwell <[email protected]> wrote:
>
>> Hi all,
>>
>> On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell <[email protected]> wrote:
>>>
>>> On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <[email protected]> wrote:
>>>>
>>>> On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <[email protected]> wrote:
>>>>>
>>>>> I found two possible fixes.
>>>>>
>>>>> 1. This uses C++ zero initializer, GCC is OK with it.
>>>>> I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
>>>>>
>>>>> --- a/include/linux/swapops.h~a
>>>>> +++ a/include/linux/swapops.h
>>>>> @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
>>>>>
>>>>> static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>>>>> {
>>>>> - return (pmd_t){ 0 };
>>>>> + return (pmd_t){};
>>>>> }
>>>>
>>>> I have done that for today ... please decide which is best (or find
>>>> something better - maybe every platform really needs to have a __pmd()
>>>> definition) and submit a real fix patch to Andrew.
>>>
>>> OK, that failed for my compiler (gcc 5.2.0) like this:
>>>
>>> In file included from mm/vmscan.c:55:0:
>>> include/linux/swapops.h: In function 'swp_entry_to_pmd':
>>> include/linux/swapops.h:226:16: error: empty scalar initializer
>>> return (pmd_t){};
>>> ^
>>> include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')
>>
>> This has reappeared today :-( (for the arm multi_v7_defconfig build at
>> least)
>>
>>> So I used the other idea (on top of Andrew's current tree):
>>
>> The fix patch now looks like this:
>>
>> From: Stephen Rothwell <[email protected]>
>> Date: Wed, 2 Aug 2017 15:55:02 +1000
>> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
>>
>> Signed-off-by: Stephen Rothwell <[email protected]>
>> ---
>> include/linux/swapops.h | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
>> index 45b092aa6419..61cffa148a79 100644
>> --- a/include/linux/swapops.h
>> +++ b/include/linux/swapops.h
>> @@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>>
>> static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>> {
>> - return (pmd_t){};
>> + pmd_t e;
>> + memset(&e, 0, sizeof(pmd_t));
>> + return e;
>> }
>
> err, yeah. I didn't want to add that one :(
>
> At the very least we should add a good comment explaining why we had to
> resort to this.
Hi Andrew,
I think __pmd(0) can be used now. I fixed __pmd() in sparc32 at commit
9157259d16a8ee8116a98d32f29b797689327e8d, which is in 4.13 now.
I should have told you this earlier, sorry about that.
Just wonder if any other reason prevents us using __pmd().
Thanks.
—
Best Regards,
Yan Zi
Hi all,
On Thu, 07 Sep 2017 06:59:09 -0400 "Zi Yan" <[email protected]> wrote:
>
> I think __pmd(0) can be used now. I fixed __pmd() in sparc32 at commit
> 9157259d16a8ee8116a98d32f29b797689327e8d, which is in 4.13 now.
> I should have told you this earlier, sorry about that.
>
> Just wonder if any other reason prevents us using __pmd().
OK, so today I have applied this instead (which is the same as dropping
mm-thp-enable-thp-migration-in-generic-path-fix-fix-fix):
From: Stephen Rothwell <[email protected]>
Date: Fri, 8 Sep 2017 12:40:39 +1000
Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
Signed-off-by: Stephen Rothwell <[email protected]>
---
include/linux/swapops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index b88441d284e2..291c4b534658 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -291,7 +291,7 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
{
- return (pmd_t){};
+ return __pmd(0);
}
static inline int is_pmd_migration_entry(pmd_t pmd)
--
2.13.2
--
Cheers,
Stephen Rothwell
Hi all,
On Fri, 8 Sep 2017 12:49:59 +1000 Stephen Rothwell <[email protected]> wrote:
>
> OK, so today I have applied this instead (which is the same as dropping
> mm-thp-enable-thp-migration-in-generic-path-fix-fix-fix):
>
> From: Stephen Rothwell <[email protected]>
> Date: Fri, 8 Sep 2017 12:40:39 +1000
> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
>
> Signed-off-by: Stephen Rothwell <[email protected]>
> ---
> include/linux/swapops.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index b88441d284e2..291c4b534658 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -291,7 +291,7 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>
> static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> {
> - return (pmd_t){};
> + return __pmd(0);
> }
>
> static inline int is_pmd_migration_entry(pmd_t pmd)
That survived my "during the day" builds (including sparc32). Some one
should just check the overnight build results:
http://kisskb.ellerman.id.au/linux-next
--
Cheers,
Stephen Rothwell
I checked. __pmd() works.
BTW, my sparc32 fix was added in linux-next on August 11th
and __pmd() is there, too. This means __pmd() + my fix has survived
for almost a month in linux-next. It should be good.
--
Best Regards
Yan Zi
On 7 Sep 2017, at 23:43, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 8 Sep 2017 12:49:59 +1000 Stephen Rothwell <[email protected]> wrote:
>>
>> OK, so today I have applied this instead (which is the same as dropping
>> mm-thp-enable-thp-migration-in-generic-path-fix-fix-fix):
>>
>> From: Stephen Rothwell <[email protected]>
>> Date: Fri, 8 Sep 2017 12:40:39 +1000
>> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
>>
>> Signed-off-by: Stephen Rothwell <[email protected]>
>> ---
>> include/linux/swapops.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
>> index b88441d284e2..291c4b534658 100644
>> --- a/include/linux/swapops.h
>> +++ b/include/linux/swapops.h
>> @@ -291,7 +291,7 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>>
>> static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>> {
>> - return (pmd_t){};
>> + return __pmd(0);
>> }
>>
>> static inline int is_pmd_migration_entry(pmd_t pmd)
>
> That survived my "during the day" builds (including sparc32). Some one
> should just check the overnight build results:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkisskb.ellerman.id.au%2Flinux-next&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7C2fd0d9ae031f4c49a49208d4f66bcc34%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636404390233531971&sdata=%2F2RdKh9%2Fl5P8F1sIticPEnTLJaWyt0xR%2BV6YXFBhsRs%3D&reserved=0
> --
> Cheers,
> Stephen Rothwell