Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2774182ybe; Sun, 15 Sep 2019 00:08:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqxTGQyhklcs/tmL3/Du0BYV9i6ez3zXrS37meSVsSYwNZcOoat9F0VMxvUBAo1TZgaSwZ0S X-Received: by 2002:aa7:db05:: with SMTP id t5mr56612925eds.242.1568531290626; Sun, 15 Sep 2019 00:08:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568531290; cv=none; d=google.com; s=arc-20160816; b=hUAqALIk7qwKNH16x6T2Me1FUnvkD8lJbL7TGTinPeAq5DQoo2fBs4HoilYUTisI5p dGnf8SLT+w3J8RWTMFSbZjLpVtTvtkycHSmZKoop1RXz1jKZTvULQ3/Y7XbwobltoyYV Vd5RCwD5a8wIewteFl8wM08j96Xi/68Je9wVOkv7cbeZFiAqFtrekdrvfyTqE1HZVScm Wdt7T6ra/XK5qaI5n6X0/tNhO8hkSr979D0K1RcJ+MLVgjMjbYm43sCFn5dur0gSnYyk 2TPULoGBoRYUJGx8QVUu6P+8SK0m833FABEOZSBnzVV2kJO0yriSpHuyBZlNgpjL5voX /q5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=d2E4Ldg8bgWFdQgYr0a+DziAxdLHEEVv48xF+8GZZLs=; b=cml1c4EA0PowaNBft44MhHwe8iTUeNg2UalDgfYrKSuWhsumISqIb7nHtr1dy0wIif yRXnUWBnAsujf5QeHVXNHcnwyeEBQ6otHnbhNKYHTB7t27nyy0UOan3KnVrqod1wlimA D5PMppivxyBcc0J1kQ//rGjbKqAjvEhHk6IhGcsdGV3VJ5jBv1kSZ5SG2Fq7FfuAXuGb wMsbTaAj58vI4ZmMCVsOBlrZNrHM6TcyNqLfKMwyOxLofV/fg2thAvBvF2IZVKernN9U SUS9kcwyLBA0mQDrlKBxVN5j9P07iOfxwrKd3TJymBwaQPRNDc1Q+HZm7ub8+BgQgdDX GvDA== 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 q26si16595207ejx.34.2019.09.15.00.07.46; Sun, 15 Sep 2019 00:08:10 -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 S1725835AbfIOHHn (ORCPT + 99 others); Sun, 15 Sep 2019 03:07:43 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:45095 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725497AbfIOHHn (ORCPT ); Sun, 15 Sep 2019 03:07:43 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8F77MEU021637; Sun, 15 Sep 2019 09:07:22 +0200 Date: Sun, 15 Sep 2019 09:07:22 +0200 From: Willy Tarreau To: Lennart Poettering Cc: Linus Torvalds , "Alexander E. Patrakov" , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190915070722.GD20811@1wt.eu> References: <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> <214fed0e-6659-def9-b5f8-a9d7a8cb72af@gmail.com> <20190915065655.GB29681@gardel-login> <20190915070103.GC20811@1wt.eu> <20190915070541.GC29681@gardel-login> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190915070541.GC29681@gardel-login> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sun, Sep 15, 2019 at 09:05:41AM +0200, Lennart Poettering wrote: > On So, 15.09.19 09:01, Willy Tarreau (w@1wt.eu) wrote: > > > On Sun, Sep 15, 2019 at 08:56:55AM +0200, Lennart Poettering wrote: > > > There's benefit in being able to wait until the pool is initialized > > > before we update the random seed stored on disk with a new one, > > > > And what exactly makes you think that waiting with arms crossed not > > doing anything else has any chance to make the situation change if > > you already had no such entropy available when reaching that first > > call, especially during early boot ? > > That code can finish 5h after boot, it's entirely fine with this > specific usecase. > > Again: we don't delay "the boot" for this. We just delay "writing a > new seed to disk" for this. And if that is 5h later, then that's > totally fine, because in the meantime it's just one bg process more that > hangs around waiting to do what it needs to do. Didn't you say it could also happen when using encrypted swap ? If so I suspect this could happen very early during boot, before any services may be started ? Willy