From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 20 Feb 2020 16:55:15 -0000 Received: from mga12.intel.com ([192.55.52.136]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j4p6Y-0003M2-83 for speck@linutronix.de; Thu, 20 Feb 2020 17:55:14 +0100 Date: Thu, 20 Feb 2020 08:55:11 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH 0/2] more sampling fun 0 Message-ID: <20200220165511.GH160988@tassilo.jf.intel.com> References: <20200220081420.GA3328448@kroah.com> <20200220145510.GE160988@tassilo.jf.intel.com> <20200220150549.GA3437955@kroah.com> MIME-Version: 1.0 In-Reply-To: <20200220150549.GA3437955@kroah.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, Feb 20, 2020 at 04:05:49PM +0100, speck for Greg KH wrote: > On Thu, Feb 20, 2020 at 06:55:10AM -0800, speck for Andi Kleen wrote: > > > Then we need to stop using RDRAND internally for our "give me a random > > > number api" which has spread to more and more parts of the kernel. > > > > Only if that API is called frequently enough. AFAIK it is not. > > It's called by all sorts of places in the kernel today. > > > Normally it's used for rare rekeying of hash tables etc., which > > doesn't happen very often. > > "normally" :) I looked through the users. The ones that weren't clearly slow path were SCTP connection setup, exec, and some strange abuse in bcache that should probably be fixed anyways. I suppose maybe for exec, but still not sure it's worth it. But the exec use is for seeding user space RNG, so that's the one that might actually be worth it. -Andi