From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8436C43215 for ; Sun, 17 Nov 2019 10:31:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7DFFF20730 for ; Sun, 17 Nov 2019 10:31:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=chronox.de header.i=@chronox.de header.b="ceYz9e/7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726116AbfKQKbw (ORCPT ); Sun, 17 Nov 2019 05:31:52 -0500 Received: from mo4-p02-ob.smtp.rzone.de ([81.169.146.169]:18213 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbfKQKbw (ORCPT ); Sun, 17 Nov 2019 05:31:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1573986707; s=strato-dkim-0002; d=chronox.de; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=YIRBWy6xFDF2aafrRHV3OAx+nt5eArNLC9lAVDkTFxs=; b=ceYz9e/7xtXSGt91JOiWo+Mop5dwRZrXuyaaVtv1ERe5cIjwgYHlgcBYIcBAEmqEW/ xsaHo05WgsPqQLxepXw4UrUSynr5HU8378XQ/OYUQb215U+70gMhShbzdNFu4YvbDVIq Ye0mACPoFPeDHC2q/ZG90VyyLTAY1loJiBC+IoJAsasCDZ6QxbU4Xx2/2xrz58+tEw8G ebKeM/vJzNx4y3ruaBvsL4CCYLKcbhPpaRCND5+kgZmZh/7WnUmXhLjfyZUlWlh+0m6j CZoi1fk+1vAHtLN9Usw9YyhNmh0MLGuR8x9hXGECE0nQqvpWQuqdk6qD80bwhpX4PxhG NxRQ== X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzHHXDbIvSfb0y2" X-RZG-CLASS-ID: mo00 Received: from positron.chronox.de by smtp.strato.de (RZmta 44.29.0 DYNA|AUTH) with ESMTPSA id N09a57vAHAUEVPH (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 17 Nov 2019 11:30:14 +0100 (CET) From: Stephan =?ISO-8859-1?Q?M=FCller?= To: Thomas Gleixner Cc: Arnd Bergmann , Greg Kroah-Hartman , linux-crypto@vger.kernel.org, LKML , linux-api@vger.kernel.org, "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Willy Tarreau , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Nicolai Stange , "Peter, Matthias" , Marcelo Henrique Cerri , Roman Drahtmueller , Neil Horman Subject: Re: [PATCH v25 01/12] Linux Random Number Generator Date: Sun, 17 Nov 2019 11:30:13 +0100 Message-ID: <9486573.CV9Qe9s7RZ@positron.chronox.de> In-Reply-To: References: <6157374.ptSnyUpaCn@positron.chronox.de> <2645285.kI0haNqfm4@positron.chronox.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Samstag, 16. November 2019, 12:25:21 CET schrieb Thomas Gleixner: Hi Thomas, > On Sat, 16 Nov 2019, Stephan M=FCller wrote: > > +/** > > + * Hot code path - Callback for interrupt handler > > + */ > > +void add_interrupt_randomness(int irq, int irq_flags) > > +{ > > + lrng_time_process(); > > + > > + if (!lrng_pool_highres_timer()) { > > + struct pt_regs *regs =3D get_irq_regs(); > > + static atomic_t reg_idx =3D ATOMIC_INIT(0); > > + u64 ip; > > + > > + lrng_pool_lfsr_u32(jiffies); > > + lrng_pool_lfsr_u32(irq); > > + lrng_pool_lfsr_u32(irq_flags); > > + > > + if (regs) { > > + u32 *ptr =3D (u32 *)regs; > > + int reg_ptr =3D atomic_add_return_relaxed(1, ®_idx); > > + size_t n =3D (sizeof(struct pt_regs) / sizeof(u32)); > > + > > + ip =3D instruction_pointer(regs); > > + lrng_pool_lfsr_u32(*(ptr + (reg_ptr % n))); > > + } else > > + ip =3D _RET_IP_; > > + > > + lrng_pool_lfsr_u32(ip >> 32); > > + lrng_pool_lfsr_u32(ip); > > + } >=20 > Is there a way to avoid all that processing right in the interrupt hot > path and just store the raw data for later processing? The main code path is lrng_time_process(). This code is streamlined as you= =20 already suggested: it is very lightweight to the interrupt handler. Compare= d=20 to the existing /dev/random implementation it is about 50% faster. When measuring the lrng_time_process, it takes on one particular test syste= m=20 on average about 65 cycles where on that very same system the=20 add_interrupt_randomness code path from the existing /dev/random takes on=20 average about 97 cycles. The additional code you see in the add_interrupt_randomness is only execute= d=20 if lrng_pool_highres_timer is not set. This is not set if the LRNG does not= =20 find a high-resolution time stamp, i.e. random_get_entropy() returns 0. As = on=20 most architectures this is now set, this code path is not executed. This additional code path serves as an emergency code to collect some data= =20 that smells random and having entropy but not having really much. It may be a bit more stremlined but since it is hardly used, I left it as i= t=20 is so far. Do you see the need to streamline it more at this time? Thanks a lot. Ciao Stephan