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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C41BBC433F5 for ; Thu, 14 Apr 2022 20:41:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242993AbiDNUoJ (ORCPT ); Thu, 14 Apr 2022 16:44:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233181AbiDNUoI (ORCPT ); Thu, 14 Apr 2022 16:44:08 -0400 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 911E83C4AE; Thu, 14 Apr 2022 13:41:41 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id q129so6665555oif.4; Thu, 14 Apr 2022 13:41:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kQ16bevC74v8j9hP5RJfq+tF3CIcALFbt9dd1uaIG9E=; b=YXgvlrNFGYGLG+dW08HZ+Cs2iibvqp3tWcN5b5UrqhC6YCANqXNPVVtnfIbsuhryy9 HxqZ9XkM8ITFRB0DvKuYGq4yITN9Jka54M+33mqkEssU2E/w7Hew1MQhvpbuDGTWTf1V wprph6WfZkMm5MmxT3zHCjdPppr3aWKuWMbEeQ8GeQKHZZA3E5QCS8zMU1A30ImMagp1 UCZKrthXLAkly5dVR/crW6JNAQEuOR3IvV6BFjPiKsvepgbv9CS5iH22u3q3C0SbwBhn PU7hkelie7a2NkvQrxdojbhr5JGz/QrSgPKHxAsayag+BWxOpiaqExouGSWbNtA7kqEl XY5g== X-Gm-Message-State: AOAM532vIQBPoSs6L+u8tjZwW8RIyTefqMvXwI1VJKwu1yOcP21Hmt1f IwPiMD3hKaSCLgLCLTm3ng== X-Google-Smtp-Source: ABdhPJwC/Cf4MTxpznrthxydqEHpaVveVGXAK2ei0no2VM/vDG7BZn3PRSgiAWYQ1YAehWtlLvX6JQ== X-Received: by 2002:a05:6808:1a1c:b0:2fa:6c17:5c07 with SMTP id bk28-20020a0568081a1c00b002fa6c175c07mr210417oib.80.1649968900860; Thu, 14 Apr 2022 13:41:40 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id lw19-20020a0568708e1300b000e2f7602666sm1038088oab.15.2022.04.14.13.41.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 13:41:40 -0700 (PDT) Received: (nullmailer pid 2666253 invoked by uid 1000); Thu, 14 Apr 2022 20:41:38 -0000 Date: Thu, 14 Apr 2022 15:41:38 -0500 From: Rob Herring To: "Jason A. Donenfeld" Cc: "linux-kernel@vger.kernel.org" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Thomas Gleixner , Arnd Bergmann , "Theodore Ts'o" , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , Dinh Nguyen , linux-arm-kernel , linux-m68k , "open list:MIPS" , linux-riscv , sparclinux , linux-um@lists.infradead.org, X86 ML , linux-xtensa@linux-xtensa.org Subject: Re: [PATCH v4 01/11] timekeeping: add raw clock fallback for random_get_entropy() Message-ID: References: <20220413115411.21489-1-Jason@zx2c4.com> <20220413115411.21489-2-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Thu, Apr 14, 2022 at 12:38:49AM +0200, Jason A. Donenfeld wrote: > Hi Rob, > > On Wed, Apr 13, 2022 at 4:32 PM Rob Herring wrote: > > 'does not have a usable get_cycles(), ...' as clearly some arches have > > get_cycles() and yet still need a fallback. > > > > Why not handle the 'if get_cycles() returns 0 do the fallback' within > > a weak random_get_entropy() function? Then more arches don't need any > > random_get_entropy() implementation. > > No, this doesn't really work. Actually, most archs don't need a > random_get_entropy() function, because it exists in asm-generic doing > the thing we want. So that's taken care of. But weak functions as you > suggested would be quite suboptimal, because on, e.g. x86, what we > have now gets inlined into a single rdtsc instruction. Also, the > relation between get_cycles() and random_get_entropy() doesn't always > hold; some archs may not have a working get_cycles() function but do > have a path for a random_get_entropy(). Etc, etc. So I'm pretty sure > that this commit is really the most simple and optimal thing to do. I > really don't want to go the weak functions route. Is random_get_entropy() a hot path? It doesn't have to be a weak function, but look at it this way. We have the following possibilities for what random_get_entropy() does: - get_cycles() - get_cycles() but returns 0 sometimes - returns 0 - something else You're handling the 3rd case. For the 2nd case, that's riscv, arm, nios2, and x86. That's not a lot, but is 2 or 3 of the most widely used architectures. Is it really too much to ask to support the 2nd case in the generic code/header? Rob