Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp1310987ybc; Sat, 16 Nov 2019 20:11:18 -0800 (PST) X-Google-Smtp-Source: APXvYqw/KN1SKrfGJRu+mKaI+v+JZ70c9LZMi8Xs6eTavhTzmVZsmyeiJMudJ4A9PrYEQSONum8E X-Received: by 2002:a17:906:2518:: with SMTP id i24mr15247402ejb.4.1573963877917; Sat, 16 Nov 2019 20:11:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573963877; cv=none; d=google.com; s=arc-20160816; b=0XaX7So3TvuYNCBpo69ucwxZtJF4Fo6uM0s5JcJxIPoaeArBr0tKzE5bBOK1H65WQ8 IMuRnswsy8sp40wxHgl9wWyAd27JGrIfsYiJB/BeAFqaIbhq5kK8WOBwMm7r2tIpVNP4 gNhBgtzks8hiXGCXDF8zHUjBYDUrMUMM5xfvQcEL+kyNwEtbSLfZyXkc759ZH+Urfofa Je34/7Zn6eyD4HtEb9v6Pq8ONCTgwrvWLO9twHhv+08gubgbUghhiiX+Z7/FSy5sW06U 1msGSNBCgC395pTj0PvET3kO0q9omjKWg5kzUDbmbgDPc5xX3ik2n3u45166vNN3qfmV JP+w== 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=HNbWZlENvwDZoLvaEGsn6QweZkfCM/OR7HpiKY16zfI=; b=wBgZ+BduBmQN6hgSTbWXc7BMYtNa4DU8ENTIIWZDUNMlV+LyMAvfwXaEmLo3YLrGR2 UQD9s6LthT0T5BfWXXhaG41WrmTwUBbyAdbRraG7d1l/mg/ytZnNSJ4Ss8tLM6OhXwdy AiTj5WF6VNL11D3zLzzWIEoK1XqV6StYy4NOXgTXeojSfZypBuB/3RTweANIMlk4J3kT 12sRaQ+Ht8kp/Gyq0aTq3SQMwh8WCvRJIIFf7ncGR8BLWWkQolnkhN7C939gIl0xXdhY GsF5WlX8c91T0CijL4Sx0U13fCTpYaYeNZXZWLj01xl6olcKV/JyY6Zo7PdKMLrM4elb KX8A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-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 o3si8815907eje.263.2019.11.16.20.10.25; Sat, 16 Nov 2019 20:11:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-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-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725901AbfKQEKV (ORCPT + 99 others); Sat, 16 Nov 2019 23:10:21 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:49711 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725839AbfKQEKU (ORCPT ); Sat, 16 Nov 2019 23:10:20 -0500 Received: from callcc.thunk.org (pool-72-93-95-157.bstnma.fios.verizon.net [72.93.95.157]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAH49jHK017868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Nov 2019 23:09:47 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 7153F4202FD; Sat, 16 Nov 2019 23:09:45 -0500 (EST) Date: Sat, 16 Nov 2019 23:09:45 -0500 From: "Theodore Y. Ts'o" To: Herbert Xu Cc: "Maciej S. Szmigiero" , Stephen Boyd , Arnd Bergmann , Greg Kroah-Hartman , Sebastian Andrzej Siewior , Keerthy , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] random: Don't freeze in add_hwgenerator_randomness() if stopping kthread Message-ID: <20191117040945.GB31360@mit.edu> References: <20191110135543.3476097-1-mail@maciej.szmigiero.name> <5dcee409.1c69fb81.f5027.48ad@mx.google.com> <415922ac-3c87-081c-6fdf-73fc97d0f397@maciej.szmigiero.name> <20191117005641.qgremf2lrj46qy4p@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191117005641.qgremf2lrj46qy4p@gondor.apana.org.au> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Sun, Nov 17, 2019 at 08:56:41AM +0800, Herbert Xu wrote: > On Sun, Nov 17, 2019 at 12:01:20AM +0100, Maciej S. Szmigiero wrote: > > > > If a reader (user space) task is frozen then it is no longer waiting > > on this waitqueue - at least if I understand correctly how the freezer > > works for user space tasks, that is by interrupting waits via a fake > > signal. > > At this point I'm just going to revert the whole thing and we can > sort it out in the next development cycle. Thanks, I hadn't planned on taking any /dev/random changes this cycle because it had gotten too late and the ext4 tree had gotten unusually busy. - Ted