Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5713094ybe; Tue, 17 Sep 2019 12:14:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqzCeh7kq6xkZShOn2BsRMPIIO3iNBGk9GBivRuc03YtRpVPe3mogWWt5iELgFhF+5fCg5OK X-Received: by 2002:a17:906:a40b:: with SMTP id l11mr6257840ejz.307.1568747671930; Tue, 17 Sep 2019 12:14:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568747671; cv=none; d=google.com; s=arc-20160816; b=0ollin26H/awqoHO//kb0nS0dCoIgiHFe2PavX17oX1Tc317Uw/Y1Kp7uWI0aADJ65 pgOUGElIX3uLJeVvag9Xzf8MtFMdqUElH+1eGTLRubZ2+dclgMaCB9eG7uIxgKX5kZeY FwQSdbwEDyio0RUsPjDihCVQyCpTBx/2f4ew88bcM9R66Ov5IchE8++ERwNAJkRS0wdz bfUxMzzlfsPs2pHXRkzcz8oGyInOIl9ias0cy2fSXxR0Z70jlS+Odei7Xzhyr2ua05Nc MogdbU0Uu5WPtRPmnk+d6h10/SLEk/j3cZI8UI1Ts4nK71U3mEPFZMHuv4Zp+wCEQ3G/ bn5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=al0G1p3/reYJcMGOIo9yCubr6jTf8dNgEzIxHvVhI8U=; b=yu+E8RYhbYIPnaH0Lf3U2gSKzfYxx+sJJtILXE8cL/lZqD37fey3Na7Yeu+8TuqDo2 OaBZnQGyMsyA78OfFLPFS9+nCUBNXKPGcIZTqJGViMSmqbTaGOgcAcQJJ3QyBkphGOpX YLxuzxtcSmJ4PVZe5oGo1G54LqenLw5g/oeyodew9N/bkxwNmeTSfuDFoO/QW+OJAVGH lkGIqVqSDaUAwa/Xu8TNb/g35z+vBGrpIiu6PtA6UUwV01Y7fq7n5OeRTUyqZkEVWLLn w64MFrgVj9M3BxBXJAuVF/Rw5Agb3BMjprMr4/f1JAZawQTiSrmG2a9uJQ6exr0/fsEu bNDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y10si1633004eje.50.2019.09.17.12.14.07; Tue, 17 Sep 2019 12:14:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731050AbfIQRai (ORCPT + 99 others); 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