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=-1.0 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 C6049C4CECD for ; Sun, 15 Sep 2019 08:34:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9C28121479 for ; Sun, 15 Sep 2019 08:34:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727378AbfIOIeU (ORCPT ); Sun, 15 Sep 2019 04:34:20 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:38350 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725865AbfIOIeT (ORCPT ); Sun, 15 Sep 2019 04:34:19 -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 00E66E81176; Sun, 15 Sep 2019 10:34:16 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id 90BA6160ADC; Sun, 15 Sep 2019 10:34:16 +0200 (CEST) Date: Sun, 15 Sep 2019 10:34:16 +0200 From: Lennart Poettering To: Willy Tarreau 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: <20190915083416.GA29771@gardel-login> References: <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> <20190915070722.GD20811@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190915070722.GD20811@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On So, 15.09.19 09:07, Willy Tarreau (w@1wt.eu) wrote: > > 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 ? Depends on the deps, and what options are used in /etc/crypttab. If people hard rely on swap to be enabled for boot to proceed and also use one-time passwords from /dev/urandom they better provide some form of hw rng, too. Otherwise the boot will block, yes. Basically, just add "nofail" to a line in /etc/crypttab, and the entry will be activated at boot, but we won't delay boot for it. It's going to be activated as soon as the deps are fulfilled (and thus the pool initialized), but that may well be 5h after boot, and that's totally OK as long as nothing else hard depends on it. Lennart -- Lennart Poettering, Berlin