[PATCH 6/7] powerpc/64s/radix: serialize_against_pte_lookup IPIs trim mm_cpumask

kernel test robot lkp at intel.com
Fri Dec 18 05:23:39 AEDT 2020


Hi Nicholas,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.10 next-20201217]
[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]

url:    https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-TLB-flushing-improvements/20201217-220230
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-m031-20201217 (attached as .config)
compiler: powerpc64le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/5bd02bea3da4e21fa00729e7687fc93a5c653e2b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Nicholas-Piggin/powerpc-64s-TLB-flushing-improvements/20201217-220230
        git checkout 5bd02bea3da4e21fa00729e7687fc93a5c653e2b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> arch/powerpc/mm/book3s64/radix_tlb.c:646:6: error: no previous prototype for 'exit_lazy_flush_tlb' [-Werror=missing-prototypes]
     646 | void exit_lazy_flush_tlb(struct mm_struct *mm, bool always_flush)
         |      ^~~~~~~~~~~~~~~~~~~
   cc1: all warnings being treated as errors


vim +/exit_lazy_flush_tlb +646 arch/powerpc/mm/book3s64/radix_tlb.c

   641	
   642	/*
   643	 * If always_flush is true, then flush even if this CPU can't be removed
   644	 * from mm_cpumask.
   645	 */
 > 646	void exit_lazy_flush_tlb(struct mm_struct *mm, bool always_flush)
   647	{
   648		unsigned long pid = mm->context.id;
   649		int cpu = smp_processor_id();
   650	
   651		/*
   652		 * A kthread could have done a mmget_not_zero() after the flushing CPU
   653		 * checked mm_cpumask, and be in the process of kthread_use_mm when
   654		 * interrupted here. In that case, current->mm will be set to mm,
   655		 * because kthread_use_mm() setting ->mm and switching to the mm is
   656		 * done with interrupts off.
   657		 */
   658		if (current->mm == mm)
   659			goto out;
   660	
   661		if (current->active_mm == mm) {
   662			WARN_ON_ONCE(current->mm != NULL);
   663			/* Is a kernel thread and is using mm as the lazy tlb */
   664			mmgrab(&init_mm);
   665			current->active_mm = &init_mm;
   666			switch_mm_irqs_off(mm, &init_mm, current);
   667			mmdrop(mm);
   668		}
   669	
   670		/*
   671		 * This IPI may be initiated from any source including those not
   672		 * running the mm, so there may be a racing IPI that comes after
   673		 * this one which finds the cpumask already clear. Check and avoid
   674		 * underflowing the active_cpus count in that case. The race should
   675		 * not otherwise be a problem, but the TLB must be flushed because
   676		 * that's what the caller expects.
   677		 */
   678		if (cpumask_test_cpu(cpu, mm_cpumask(mm))) {
   679			atomic_dec(&mm->context.active_cpus);
   680			cpumask_clear_cpu(cpu, mm_cpumask(mm));
   681			always_flush = true;
   682		}
   683	
   684	out:
   685		if (always_flush)
   686			_tlbiel_pid(pid, RIC_FLUSH_ALL);
   687	}
   688	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 40559 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20201218/d87f383d/attachment-0001.gz>


More information about the Linuxppc-dev mailing list