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.8 required=3.0 tests=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 8E200C4CECD for ; Tue, 17 Sep 2019 17:30:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 73E212171F for ; Tue, 17 Sep 2019 17:30:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731076AbfIQRai (ORCPT ); Tue, 17 Sep 2019 13:30:38 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:40780 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728433AbfIQRai (ORCPT ); Tue, 17 Sep 2019 13:30:38 -0400 Received: from gardel-login.0pointer.net (gardel.0pointer.net [IPv6:2a01:238:43ed:c300:10c3:bcf3:3266:da74]) by gardel.0pointer.net (Postfix) with ESMTP id E36ACE80FFC; Tue, 17 Sep 2019 19:30:36 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id A1B96160ADC; Tue, 17 Sep 2019 19:30:36 +0200 (CEST) Date: Tue, 17 Sep 2019 19:30:36 +0200 From: Lennart Poettering To: "Alexander E. Patrakov" Cc: Linus Torvalds , Willy Tarreau , Matthew Garrett , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190917173036.GC31798@gardel-login> References: <20190917052438.GA26923@1wt.eu> <2508489.jOnZlRuxVn@merkaba> <6ae36cda-5045-6873-9727-1d36bf45b84e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ae36cda-5045-6873-9727-1d36bf45b84e@gmail.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Di, 17.09.19 21:58, Alexander E. Patrakov (patrakov@gmail.com) wrote: > I am worried that the getrandom delays will be serialized, because processes > sometimes run one after another. If there are enough chained/dependent > processes that ask for randomness before it is ready, the end result is > still a too-big delay, essentially a failed boot. > > In other words: your approach of adding delays only makes sense for heavily > parallelized boot, which may not be the case, especially for embedded > systems that don't like systemd. As mentioned elsewhere: once the pool is initialized it's initialized. This means any pending getrandom() on the whole system will unblock at the same time, and from the on all getrandom()s will be non-blocking. systemd-random-seed.service is nowadays a synchronization point for exactly the moment where the pool is considered full. Lennart -- Lennart Poettering, Berlin