linux-kernel - [tip:WIP.x86/alternatives 7/9] arch/x86/kernel/alternative.c:896:42: sparse: Using plain integer as NULL pointer

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Sat, 20 Apr 2019 16:08:04 +0800
From:   kbuild test robot <lkp@...el.com>
To:     Daniel Bristot de Oliveira <bristot@...hat.com>
Cc:     kbuild-all@...org, linux-kernel@...r.kernel.org,
        tipbuild@...or.com, Ingo Molnar <mingo@...nel.org>
Subject: [tip:WIP.x86/alternatives 7/9] arch/x86/kernel/alternative.c:896:42:
 sparse: Using plain integer as NULL pointer

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/alternatives
head:   1f30946b1a01baf22df6faf74c0a1e602bb6cac7
commit: 76ec759ad71c1fa0c4b327367e82b2650109a22f [7/9] x86/alternative: Batch of patch operations
reproduce:
        # apt-get install sparse
        git checkout 76ec759ad71c1fa0c4b327367e82b2650109a22f
        make ARCH=x86_64 allmodconfig
        make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@...el.com>



sparse warnings: (new ones prefixed by >>)

>> arch/x86/kernel/alternative.c:896:42: sparse: Using plain integer as NULL pointer

vim +896 arch/x86/kernel/alternative.c

   836	
   837	/**
   838	 * text_poke_bp() -- update instructions on live kernel on SMP
   839	 * @addr:	address to patch
   840	 * @opcode:	opcode of new instruction
   841	 * @len:	length to copy
   842	 * @handler:	address to jump to when the temporary breakpoint is hit
   843	 *
   844	 * Modify multi-byte instruction by using int3 breakpoint on SMP.
   845	 * We completely avoid stop_machine() here, and achieve the
   846	 * synchronization using int3 breakpoint.
   847	 *
   848	 * The way it is done:
   849	 *	- add a int3 trap to the address that will be patched
   850	 *	- sync cores
   851	 *	- update all but the first byte of the patched range
   852	 *	- sync cores
   853	 *	- replace the first byte (int3) by the first byte of
   854	 *	  replacing opcode
   855	 *	- sync cores
   856	 */
   857	void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
   858	{
   859		unsigned char int3 = 0xcc;
   860	
   861		lockdep_assert_held(&text_mutex);
   862	
   863		bp_int3_handler = handler;
   864		bp_int3_addr = (u8 *)addr + sizeof(int3);
   865	
   866		bp_patching_in_progress = true;
   867		/*
   868		 * Corresponding read barrier in int3 notifier for making sure the
   869		 * in_progress and handler are correctly ordered wrt. patching.
   870		 */
   871		smp_wmb();
   872	
   873		text_poke_bp_set_handler(addr, handler, int3);
   874	
   875		on_each_cpu(do_sync_core, NULL, 1);
   876	
   877		if (len - sizeof(int3) > 0) {
   878			patch_all_but_first_byte(addr, opcode, len, int3);
   879			/*
   880			 * According to Intel, this core syncing is very likely
   881			 * not necessary and we'd be safe even without it. But
   882			 * better safe than sorry (plus there's not only Intel).
   883			 */
   884			on_each_cpu(do_sync_core, NULL, 1);
   885		}
   886	
   887		patch_first_byte(addr, opcode, int3);
   888	
   889		on_each_cpu(do_sync_core, NULL, 1);
   890		/*
   891		 * sync_core() implies an smp_mb() and orders this store against
   892		 * the writing of the new instruction.
   893		 */
   894		bp_patching_in_progress = false;
   895	
 > 896		bp_int3_handler = bp_int3_addr = 0;
   897		return addr;
   898	}
   899	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation