Re: [PATCH v5 05/12] x86/mm: add INVLPGB support code

Re: [PATCH v5 05/12] x86/mm: add INVLPGB support code

[kernel test robot]

Hi Rik,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/x86/mm]
[also build test ERROR on tip/master linus/master tip/x86/core v6.13-rc7]
[cannot apply to tip/auto-latest next-20250116]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Rik-van-Riel/x86-mm-make-MMU_GATHER_RCU_TABLE_FREE-unconditional/20250116-103657
base:   tip/x86/mm
patch link:    https://lore.kernel.org/r/20250116023127.1531583-6-riel%40surriel.com
patch subject: [PATCH v5 05/12] x86/mm: add INVLPGB support code
config: i386-buildonly-randconfig-001-20250117 (https://download.01.org/0day-ci/archive/20250117/202501171121.nQcwVI41-lkp@intel.com/config)
compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250117/202501171121.nQcwVI41-lkp@intel.com/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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501171121.nQcwVI41-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/x86/kernel/asm-offsets.c:14:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:17:
   In file included from include/linux/fs.h:33:
   In file included from include/linux/percpu-rwsem.h:7:
   In file included from include/linux/rcuwait.h:6:
   In file included from include/linux/sched/signal.h:9:
   In file included from include/linux/sched/task.h:13:
   In file included from include/linux/uaccess.h:12:
   In file included from arch/x86/include/asm/uaccess.h:17:
   In file included from arch/x86/include/asm/tlbflush.h:13:
>> arch/x86/include/asm/invlpgb.h:26:49: error: invalid input size for constraint 'a'
      26 |         asm volatile(".byte 0x0f, 0x01, 0xfe" : : "a" (rax), "c" (ecx), "d" (edx));
         |                                                        ^
   In file included from arch/x86/kernel/asm-offsets.c:14:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:21:
   In file included from include/linux/mm.h:2223:
   include/linux/vmstat.h:518:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
     518 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
         |                               ~~~~~~~~~~~ ^ ~~~
   1 warning and 1 error generated.
   make[3]: *** [scripts/Makefile.build:102: arch/x86/kernel/asm-offsets.s] Error 1 shuffle=3995685176
   make[3]: Target 'prepare' not remade because of errors.
   make[2]: *** [Makefile:1263: prepare0] Error 2 shuffle=3995685176
   make[2]: Target 'prepare' not remade because of errors.
   make[1]: *** [Makefile:251: __sub-make] Error 2 shuffle=3995685176
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:251: __sub-make] Error 2 shuffle=3995685176
   make: Target 'prepare' not remade because of errors.


vim +/a +26 arch/x86/include/asm/invlpgb.h

     7	
     8	/*
     9	 * INVLPGB does broadcast TLB invalidation across all the CPUs in the system.
    10	 *
    11	 * The INVLPGB instruction is weakly ordered, and a batch of invalidations can
    12	 * be done in a parallel fashion.
    13	 *
    14	 * TLBSYNC is used to ensure that pending INVLPGB invalidations initiated from
    15	 * this CPU have completed.
    16	 */
    17	static inline void __invlpgb(unsigned long asid, unsigned long pcid,
    18				     unsigned long addr, u16 extra_count,
    19				     bool pmd_stride, unsigned long flags)
    20	{
    21		u32 edx = (pcid << 16) | asid;
    22		u32 ecx = (pmd_stride << 31) | extra_count;
    23		u64 rax = addr | flags;
    24	
    25		/* INVLPGB; supported in binutils >= 2.36. */
  > 26		asm volatile(".byte 0x0f, 0x01, 0xfe" : : "a" (rax), "c" (ecx), "d" (edx));
    27	}
    28	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v5 05/12] x86/mm: add INVLPGB support code

[Rik van Riel]

On Fri, 2025-01-17 at 11:37 +0800, kernel test robot wrote:
> 
> compiler: clang version 19.1.3
> (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b25
> 4b6afab99)
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20250117/202501171121.nQcwVI
> 41-lkp@intel.com/reproduce)
> 

> > > arch/x86/include/asm/invlpgb.h:26:49: error: invalid input size
> > > for constraint 'a'
>       26 |         asm volatile(".byte 0x0f, 0x01, 0xfe" : : "a"
> (rax), "c" (ecx), "d" (edx));
>          |                                                        ^
> 

What do I do about this?

It didn't used to complain when we had a named
assembler operator there:

    asm volatile("invlpgb" : : "a" (rax), "c" (ecx), "d" (edx));

However, now that we're using .byte for compatibility
with older binutils, things break with newer llvm?

-- 
All Rights Reversed.

Re: [PATCH v5 05/12] x86/mm: add INVLPGB support code

[Rik van Riel]

On Fri, 2025-01-17 at 09:20 -0500, Rik van Riel wrote:
> On Fri, 2025-01-17 at 11:37 +0800, kernel test robot wrote:
> > 
> > compiler: clang version 19.1.3
> > (
> > https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b25
> > 4b6afab99)
> > reproduce (this is a W=1 build):
> > (
> > https://download.01.org/0day-ci/archive/20250117/202501171121.nQcwVI
> > 41-lkp@intel.com/reproduce)
> > 
> 
> > > > arch/x86/include/asm/invlpgb.h:26:49: error: invalid input size
> > > > for constraint 'a'
> >       26 |         asm volatile(".byte 0x0f, 0x01, 0xfe" : : "a"
> > (rax), "c" (ecx), "d" (edx));
> >          |                                                        ^
> > 
> 
> What do I do about this?

Ohhh, never mind.

The failing build is a 32 bit build!

I just need to use unsigned long instead of u64 in the
next version.

-- 
All Rights Reversed.