Re: [PATCH] drivers/char/random.c: Clean up style issues

[kernel test robot <lkp@intel.com>]

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@intel.com/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@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202508251623.uUGghjhZ-lkp@intel.com/

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