Hi Osama, kernel test robot noticed the following build warnings: [auto build test WARNING on v6.17-rc2] [also build test WARNING on linus/master] [cannot apply to crng-random/master next-20250822] [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/Osama-Abdelkader/drivers-char-random-c-Clean-up-style-issues/20250821-010651 base: v6.17-rc2 patch link: https://lore.kernel.org/r/20250820170359.78811-1-osama.abdelkader%40gmail.com patch subject: [PATCH] drivers/char/random.c: Clean up style issues config: sparc-randconfig-r071-20250825 (https://download.01.org/0day-ci/archive/20250825/202508251623.uUGghjhZ-lkp@xxxxxxxxx/config) compiler: sparc-linux-gcc (GCC) 8.5.0 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@xxxxxxxxx> | Closes: https://lore.kernel.org/oe-kbuild-all/202508251623.uUGghjhZ-lkp@xxxxxxxxx/ smatch warnings: drivers/char/random.c:325 crng_fast_key_erasure() warn: inconsistent indenting drivers/char/random.c:349 crng_make_state() warn: inconsistent indenting vim +325 drivers/char/random.c 304 305 /* 306 * This generates a ChaCha block using the provided key, and then 307 * immediately overwrites that key with half the block. It returns 308 * the resultant ChaCha state to the user, along with the second 309 * half of the block containing 32 bytes of random data that may 310 * be used; random_data_len may not be greater than 32. 311 * 312 * The returned ChaCha state contains within it a copy of the old 313 * key value, at index 4, so the state should always be zeroed out 314 * immediately after using in order to maintain forward secrecy. 315 * If the state cannot be erased in a timely manner, then it is 316 * safer to set the random_data parameter to &chacha_state->x[4] 317 * so that this function overwrites it before returning. 318 */ 319 static void crng_fast_key_erasure(u8 key[CHACHA_KEY_SIZE], 320 struct chacha_state *chacha_state, 321 u8 *random_data, size_t random_data_len) 322 { 323 u8 first_block[CHACHA_BLOCK_SIZE]; 324 > 325 WARN_ON_ONCE(random_data_len > 32); 326 if (random_data_len > 32) 327 return; 328 chacha_init_consts(chacha_state); 329 memcpy(&chacha_state->x[4], key, CHACHA_KEY_SIZE); 330 memset(&chacha_state->x[12], 0, sizeof(u32) * 4); 331 chacha20_block(chacha_state, first_block); 332 333 memcpy(key, first_block, CHACHA_KEY_SIZE); 334 memcpy(random_data, first_block + CHACHA_KEY_SIZE, random_data_len); 335 memzero_explicit(first_block, sizeof(first_block)); 336 } 337 338 /* 339 * This function returns a ChaCha state that you may use for generating 340 * random data. It also returns up to 32 bytes on its own of random data 341 * that may be used; random_data_len may not be greater than 32. 342 */ 343 static void crng_make_state(struct chacha_state *chacha_state, 344 u8 *random_data, size_t random_data_len) 345 { 346 unsigned long flags; 347 struct crng *crng; 348 > 349 WARN_ON_ONCE(random_data_len > 32); 350 if (random_data_len > 32) 351 return; 352 /* 353 * For the fast path, we check whether we're ready, unlocked first, and 354 * then re-check once locked later. In the case where we're really not 355 * ready, we do fast key erasure with the base_crng directly, extracting 356 * when crng_init is CRNG_EMPTY. 357 */ 358 if (!crng_ready()) { 359 bool ready; 360 361 spin_lock_irqsave(&base_crng.lock, flags); 362 ready = crng_ready(); 363 if (!ready) { 364 if (crng_init == CRNG_EMPTY) 365 extract_entropy(base_crng.key, sizeof(base_crng.key)); 366 crng_fast_key_erasure(base_crng.key, chacha_state, 367 random_data, random_data_len); 368 } 369 spin_unlock_irqrestore(&base_crng.lock, flags); 370 if (!ready) 371 return; 372 } 373 374 local_lock_irqsave(&crngs.lock, flags); 375 crng = raw_cpu_ptr(&crngs); 376 377 /* 378 * If our per-cpu crng is older than the base_crng, then it means 379 * somebody reseeded the base_crng. In that case, we do fast key 380 * erasure on the base_crng, and use its output as the new key 381 * for our per-cpu crng. This brings us up to date with base_crng. 382 */ 383 if (unlikely(crng->generation != READ_ONCE(base_crng.generation))) { 384 spin_lock(&base_crng.lock); 385 crng_fast_key_erasure(base_crng.key, chacha_state, 386 crng->key, sizeof(crng->key)); 387 crng->generation = base_crng.generation; 388 spin_unlock(&base_crng.lock); 389 } 390 391 /* 392 * Finally, when we've made it this far, our per-cpu crng has an up 393 * to date key, and we can do fast key erasure with it to produce 394 * some random data and a ChaCha state for the caller. All other 395 * branches of this function are "unlikely", so most of the time we 396 * should wind up here immediately. 397 */ 398 crng_fast_key_erasure(crng->key, chacha_state, random_data, random_data_len); 399 local_unlock_irqrestore(&crngs.lock, flags); 400 } 401 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
