arch/s390/kvm/gaccess.c:321:2: error: expected identifier

Quoted 1 line

Quoted 1 line

arch/s390/kvm/gaccess.c:344:8: error: duplicate case value: '0' and 'PROT_TYPE_LA' both equal '0'

Hi,

Due to the line:

include/linux/huge_mm.h:509 '#include <uapi/asm/mman.h>'

there is a name collision in arch/s390/kvm/gaccess.c, where 'PROT_NONE' is also defined as value for 'enum prot_type'.

A possible fix for this would be to rename PROT_NONE in the enum to PROT_TYPE_NONE.

The patch causing this problem was created by me based on a suggestion in the review process of another patch that I submitted first:

https://lore.kernel.org/linux-mm/[email protected]/

In case '#include <uapi/asm/mman.h>' causes unexpected trouble, we can also take the patch back... What do you think?

Thanks and regards
Ignacio

Quoted 1 line · kernel test robot

Quoted 1 line

Quoted 1 line

arch/s390/kvm/gaccess.c:344:8: error: duplicate case value: '0' and 'PROT_TYPE_LA' both equal '0'

Quoted 1 line

arch/s390/kvm/gaccess.c:321:2: error: expected identifier

Quoted 1 line

arch/s390/kvm/gaccess.c:344:8: error: duplicate case value: '0' and 'PROT_TYPE_LA' both equal '0'

+cc s390 people, kvm s390 people + lists. sorry for noise but get_maintainers.pl says there's a lot of you :)

Quoted 5 lines · Ignacio Moreno Gonzalez

Hi,

Due to the line:

include/linux/huge_mm.h:509 '#include <uapi/asm/mman.h>'

BTW, I didn't notice at the time, but shouldn't this be linux/mman.h? You shouldn't be importing this header this way generally (only other users are arch code).

But at any rate, you will ultimately import the PROT_NONE declaration.

Quoted 2 lines

there is a name collision in arch/s390/kvm/gaccess.c, where 'PROT_NONE' is also defined as value for 'enum prot_type'.

That is crazy. Been there since 2022 also...!

Quoted 2 lines

A possible fix for this would be to rename PROT_NONE in the enum to PROT_TYPE_NONE.

Yeah this is the correct fix, IMO, but you will need to get that sorted with the arch maintainers.

I think this suggests we should back out this change for now and try again next cycle given we haven't much time left.

Have cc'd s390/kvm for s390 maintainers for their input however!

Quoted 6 lines

The patch causing this problem was created by me based on a suggestion in the review process of another patch that I submitted first:

https://lore.kernel.org/linux-mm/[email protected]/

In case '#include <uapi/asm/mman.h>' causes unexpected trouble, we can also take the patch back... What do you think?

I guess we need to back this out for the time being, since we're so near the end of the cycle.

Quoted 8 lines

Thanks and regards
Ignacio

Quoted 1 line · kernel test robot

Quoted 1 line

Quoted 1 line

arch/s390/kvm/gaccess.c:344:8: error: duplicate case value: '0' and 'PROT_TYPE_LA' both equal '0'

For convenience, let me include the top of the original report. The full thing is at https://lore.kernel.org/all/[email protected]/

The original patch for this is at
https://lore.kernel.org/all/20250508-madvise-nohugepage-noop-without-thp-v1-1-e7ceffb197f3@kuka.com/

Original report:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
head:   24e96425873f27730d30dcfc639a3995e312e6f2
commit: cd07d277e6acce78e103478ea19a452bcf31013e [320/331] mm: madvise: make MADV_NOHUGEPAGE a no-op if !THP
config: s390-randconfig-r062-20250514

+(https://download.01.org/0day-ci/archive/20250514/[email protected]/config)
compiler: clang version 21.0.0git (https://github.com/llvm/llvm-project f819f46284f2a79790038e1f6649172789734ae8) reproduce (this is a W=1 build):
+(https://download.01.org/0day-ci/archive/20250514/[email protected]/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

Quoted 1 line

Quoted 1 line

arch/s390/kvm/gaccess.c:321:2: error: expected identifier

     321 |         PROT_NONE,
         |         ^
   include/uapi/asm-generic/mman-common.h:16:19: note: expanded from macro 'PROT_NONE'
      16 | #define PROT_NONE       0x0             /* page can not be accessed */
         |                         ^

Quoted 1 line

Quoted 1 line

arch/s390/kvm/gaccess.c:344:8: error: duplicate case value: '0' and 'PROT_TYPE_LA' both equal '0'

344 | case PROT_TYPE_LA:
| ^
arch/s390/kvm/gaccess.c:337:8: note: previous case defined here
337 | case PROT_NONE:
| ^
include/uapi/asm-generic/mman-common.h:16:19: note: expanded from macro 'PROT_NONE'

      16 | #define PROT_NONE       0x0             /* page can not be accessed */
         |                         ^

Quoted 22 lines · On Wed, 14 May 2025 14:48:44 +0100 Lorenzo Stoakes…

+cc s390 people, kvm s390 people + lists. sorry for noise but get_maintainers.pl says there's a lot of you :)

Quoted 5 lines · Ignacio Moreno Gonzalez

Hi,

Due to the line:

include/linux/huge_mm.h:509 '#include <uapi/asm/mman.h>'

BTW, I didn't notice at the time, but shouldn't this be linux/mman.h? You shouldn't be importing this header this way generally (only other users are arch code).

But at any rate, you will ultimately import the PROT_NONE declaration.

Quoted 2 lines

there is a name collision in arch/s390/kvm/gaccess.c, where 'PROT_NONE' is also defined as value for 'enum prot_type'.

That is crazy. Been there since 2022 also...!

Quoted 1 line

Quoted 1 line

Quoted 1 line

A possible fix for this would be to rename PROT_NONE in the enum to PROT_TYPE_NONE.

please write a patch to rename PROT_NONE in our enum to PROT_TYPE_DUMMY, I can review it quickly.

if Paolo has no objections, I'm fine with having the patch go through the mm tree

Am 14.05.25 um 16:27 schrieb Claudio Imbrenda:

Quoted 30 lines

Quoted 14 lines · On Wed, 14 May 2025 14:48:44 +0100 Lorenzo Stoakes…

+cc s390 people, kvm s390 people + lists. sorry for noise but get_maintainers.pl says there's a lot of you :)

Quoted 5 lines · Ignacio Moreno Gonzalez

Hi,

Due to the line:

include/linux/huge_mm.h:509 '#include <uapi/asm/mman.h>'

BTW, I didn't notice at the time, but shouldn't this be linux/mman.h? You shouldn't be importing this header this way generally (only other users are arch code).

Quoted 9 lines

But at any rate, you will ultimately import the PROT_NONE declaration.

Quoted 2 lines

there is a name collision in arch/s390/kvm/gaccess.c, where 'PROT_NONE' is also defined as value for 'enum prot_type'.

That is crazy. Been there since 2022 also...!

Quoted 2 lines

A possible fix for this would be to rename PROT_NONE in the enum to PROT_TYPE_NONE.

please write a patch to rename PROT_NONE in our enum to PROT_TYPE_DUMMY, I can review it quickly.

Quoted 2 lines

if Paolo has no objections, I'm fine with having the patch go through the mm tree

Yes, lets do a quick fix and I can also do

Acked-by Christian Borntraeger <[email protected]>

for a s/PROT_NONE/PROT_TYPE_NONE/g
patch.

Quoted 8 lines

Quoted 7 lines

Quoted 1 line

Quoted 1 line

A possible fix for this would be to rename PROT_NONE in the enum to PROT_TYPE_NONE.

please write a patch to rename PROT_NONE in our enum to PROT_TYPE_DUMMY, I can review it quickly.

if Paolo has no objections, I'm fine with having the patch go through the mm tree

Quoted 5 lines

Yes, lets do a quick fix and I can also do

Acked-by Christian Borntraeger <[email protected]>

for a s/PROT_NONE/PROT_TYPE_NONE/g
patch.

I'd rather have PROT_TYPE_DUMMY, since it's a dummy value and not something that indicates "no protection"

Am 14.05.25 um 16:48 schrieb Claudio Imbrenda:

Quoted 11 lines

Quoted 11 lines

Quoted 7 lines

Quoted 1 line

Quoted 1 line

A possible fix for this would be to rename PROT_NONE in the enum to PROT_TYPE_NONE.

please write a patch to rename PROT_NONE in our enum to PROT_TYPE_DUMMY, I can review it quickly.

if Paolo has no objections, I'm fine with having the patch go through the mm tree

Yes, lets do a quick fix and I can also do

Acked-by Christian Borntraeger <[email protected]>

Quoted 5 lines

Quoted 2 lines

for a s/PROT_NONE/PROT_TYPE_NONE/g
patch.

I'd rather have PROT_TYPE_DUMMY, since it's a dummy value and not something that indicates "no protection"

makes sense.

Quoted 18 lines · Christian Borntraeger

Am 14.05.25 um 16:48 schrieb Claudio Imbrenda:

Quoted 14 lines

Quoted 13 lines

Quoted 7 lines

Quoted 1 line

Quoted 1 line

A possible fix for this would be to rename PROT_NONE in the enum to PROT_TYPE_NONE.

please write a patch to rename PROT_NONE in our enum to PROT_TYPE_DUMMY, I can review it quickly.

if Paolo has no objections, I'm fine with having the patch go through the mm tree

Yes, lets do a quick fix and I can also do

Acked-by Christian Borntraeger <[email protected]>

for a s/PROT_NONE/PROT_TYPE_NONE/g
patch.

Quoted 4 lines

Quoted 2 lines

I'd rather have PROT_TYPE_DUMMY, since it's a dummy value and not something that indicates "no protection"

makes sense.

Thanks for the quick response guys, did you want us to write the patch?

We can put something together quickly if so and cc you on it.

Ack on the comment above, of course!

Cheers, Lorenzo