lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 12 Jun 2020 13:12:29 +0800
From:   kernel test robot <lkp@...el.com>
To:     Sourabh Jain <sourabhjain@...ux.ibm.com>, mpe@...erman.id.au
Cc:     kbuild-all@...ts.01.org, mahesh@...ux.vnet.ibm.com,
        linux-kernel@...r.kernel.org, hbathini@...ux.ibm.com,
        linuxppc-dev@...abs.org
Subject: Re: [PATCH v4] powerpc/fadump: fix race between pstore write and
 fadump crash trigger

Hi Sourabh,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on linus/master linux/master v5.7 next-20200611]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Sourabh-Jain/powerpc-fadump-fix-race-between-pstore-write-and-fadump-crash-trigger/20200605-033545
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r002-20200612 (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
        # 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@...el.com>

All errors (new ones prefixed by >>, old ones prefixed by <<):

arch/powerpc/kernel/fadump.c: In function 'crash_fadump':
>> arch/powerpc/kernel/fadump.c:700:15: error: 'cpus_in_crash' undeclared (first use in this function)
700 |   atomic_inc(&cpus_in_crash);
|               ^~~~~~~~~~~~~
arch/powerpc/kernel/fadump.c:700:15: note: each undeclared identifier is reported only once for each function it appears in
arch/powerpc/kernel/fadump.c: In function 'fadump_update_elfcore_header':
arch/powerpc/kernel/fadump.c:755:17: warning: variable 'elf' set but not used [-Wunused-but-set-variable]
755 |  struct elfhdr *elf;
|                 ^~~
arch/powerpc/kernel/fadump.c: At top level:
arch/powerpc/kernel/fadump.c:1706:22: warning: no previous prototype for 'arch_reserved_kernel_pages' [-Wmissing-prototypes]
1706 | unsigned long __init arch_reserved_kernel_pages(void)
|                      ^~~~~~~~~~~~~~~~~~~~~~~~~~

vim +/cpus_in_crash +700 arch/powerpc/kernel/fadump.c

   678	
   679	void crash_fadump(struct pt_regs *regs, const char *str)
   680	{
   681		unsigned int msecs;
   682		struct fadump_crash_info_header *fdh = NULL;
   683		int old_cpu, this_cpu;
   684		unsigned int ncpus = num_online_cpus() - 1; /* Do not include first CPU */
   685	
   686		if (!should_fadump_crash())
   687			return;
   688	
   689		/*
   690		 * old_cpu == -1 means this is the first CPU which has come here,
   691		 * go ahead and trigger fadump.
   692		 *
   693		 * old_cpu != -1 means some other CPU has already on it's way
   694		 * to trigger fadump, just keep looping here.
   695		 */
   696		this_cpu = smp_processor_id();
   697		old_cpu = cmpxchg(&crashing_cpu, -1, this_cpu);
   698	
   699		if (old_cpu != -1) {
 > 700			atomic_inc(&cpus_in_crash);
   701	
   702			/*
   703			 * We can't loop here indefinitely. Wait as long as fadump
   704			 * is in force. If we race with fadump un-registration this
   705			 * loop will break and then we go down to normal panic path
   706			 * and reboot. If fadump is in force the first crashing
   707			 * cpu will definitely trigger fadump.
   708			 */
   709			while (fw_dump.dump_registered)
   710				cpu_relax();
   711			return;
   712		}
   713	
   714		fdh = __va(fw_dump.fadumphdr_addr);
   715		fdh->crashing_cpu = crashing_cpu;
   716		crash_save_vmcoreinfo();
   717	
   718		if (regs)
   719			fdh->regs = *regs;
   720		else
   721			ppc_save_regs(&fdh->regs);
   722	
   723		fdh->online_mask = *cpu_online_mask;
   724	
   725		/*
   726		 * If we came in via system reset, wait a while for the secondary
   727		 * CPUs to enter.
   728		 */
   729		if (TRAP(&(fdh->regs)) == 0x100) {
   730			msecs = CRASH_TIMEOUT;
   731			while ((atomic_read(&cpus_in_crash) < ncpus) && (--msecs > 0))
   732				mdelay(1);
   733		}
   734	
   735		fw_dump.ops->fadump_trigger(fdh, str);
   736	}
   737	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

Download attachment ".config.gz" of type "application/gzip" (29766 bytes)

Powered by blists - more mailing lists