All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH] random: do not take pool spinlock at boot
Date: Sat, 12 Feb 2022 13:35:00 +0800	[thread overview]
Message-ID: <202202121318.QSBkUcwP-lkp@intel.com> (raw)
In-Reply-To: <20220212002859.622233-1-Jason@zx2c4.com>

[-- Attachment #1: Type: text/plain, Size: 4290 bytes --]

Hi "Jason,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20220211]
[cannot apply to char-misc/char-misc-testing linux/master linus/master v5.17-rc3 v5.17-rc2 v5.17-rc1 v5.17-rc3]
[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/Jason-A-Donenfeld/random-do-not-take-pool-spinlock-at-boot/20220212-083131
base:    6d9bd4ad4ca08b1114e814c2c42383b8b13be631
config: um-x86_64_defconfig (https://download.01.org/0day-ci/archive/20220212/202202121318.QSBkUcwP-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/cac377f6ab22a8bfe966643ebe19812e8187de3b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Jason-A-Donenfeld/random-do-not-take-pool-spinlock-at-boot/20220212-083131
        git checkout cac377f6ab22a8bfe966643ebe19812e8187de3b
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 O=build_dir ARCH=um SUBARCH=x86_64 SHELL=/bin/bash

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

All errors (new ones prefixed by >>):

   drivers/char/random.c: In function 'rand_initialize':
>> drivers/char/random.c:162:3: error: implicit declaration of function '_mix_pool_bytes'; did you mean 'mix_pool_bytes'? [-Werror=implicit-function-declaration]
     162 |   _mix_pool_bytes(&rv, sizeof(rv));
         |   ^~~~~~~~~~~~~~~
         |   mix_pool_bytes
   drivers/char/random.c: At top level:
   drivers/char/random.c:822:13: warning: conflicting types for '_mix_pool_bytes'
     822 | static void _mix_pool_bytes(const void *in, size_t nbytes)
         |             ^~~~~~~~~~~~~~~
>> drivers/char/random.c:822:13: error: static declaration of '_mix_pool_bytes' follows non-static declaration
   drivers/char/random.c:162:3: note: previous implicit declaration of '_mix_pool_bytes' was here
     162 |   _mix_pool_bytes(&rv, sizeof(rv));
         |   ^~~~~~~~~~~~~~~
   drivers/char/random.c:1109:6: warning: no previous prototype for 'add_hwgenerator_randomness' [-Wmissing-prototypes]
    1109 | void add_hwgenerator_randomness(const void *buffer, size_t count,
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +162 drivers/char/random.c

   138	
   139	/*
   140	 * Note that setup_arch() may call add_device_randomness()
   141	 * long before we get here. This allows seeding of the pools
   142	 * with some platform dependent data very early in the boot
   143	 * process. But it limits our options here. We must use
   144	 * statically allocated structures that already have all
   145	 * initializations complete at compile time. We should also
   146	 * take care not to overwrite the precious per platform data
   147	 * we were given.
   148	 */
   149	int __init rand_initialize(void)
   150	{
   151		size_t i;
   152		ktime_t now = ktime_get_real();
   153		bool arch_init = true;
   154		unsigned long rv;
   155	
   156		for (i = BLAKE2S_BLOCK_SIZE; i > 0; i -= sizeof(rv)) {
   157			if (!arch_get_random_seed_long_early(&rv) &&
   158			    !arch_get_random_long_early(&rv)) {
   159				rv = random_get_entropy();
   160				arch_init = false;
   161			}
 > 162			_mix_pool_bytes(&rv, sizeof(rv));
   163		}
   164		_mix_pool_bytes(&now, sizeof(now));
   165		_mix_pool_bytes(utsname(), sizeof(*(utsname())));
   166	
   167		extract_entropy(base_crng.key, sizeof(base_crng.key));
   168		++base_crng.generation;
   169	
   170		if (arch_init && trust_cpu && crng_init < 2) {
   171			crng_init = 2;
   172			pr_notice("crng init done (trusting CPU's manufacturer)\n");
   173		}
   174	
   175		if (ratelimit_disable) {
   176			urandom_warning.interval = 0;
   177			unseeded_warning.interval = 0;
   178		}
   179		return 0;
   180	}
   181	

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

  parent reply	other threads:[~2022-02-12  5:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-12  0:28 [PATCH] random: do not take pool spinlock at boot Jason A. Donenfeld
2022-02-12  5:04 ` kernel test robot
2022-02-12  5:35 ` kernel test robot [this message]
2022-02-12 10:01   ` Jason A. Donenfeld
2022-02-14  6:40     ` Chen, Rong A
2022-02-13  6:55 ` Dominik Brodowski
2022-02-21  5:34 ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202202121318.QSBkUcwP-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=kbuild-all@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.