From: "Horia Geantă" <horia.geanta@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
"Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: Stephen Boyd <swboyd@chromium.org>, Theodore Ts'o <tytso@mit.edu>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Keerthy <j-keerthy@ti.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] random: Don't freeze in add_hwgenerator_randomness() if stopping kthread
Date: Wed, 2 Dec 2020 16:28:07 +0200 [thread overview]
Message-ID: <2f581f84-378f-05cf-1902-f0494aafe706@nxp.com> (raw)
In-Reply-To: <20191117005641.qgremf2lrj46qy4p@gondor.apana.org.au>
On 11/17/2019 2:57 AM, 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.
>
Working at adding power management support for caam crypto driver,
I've stumbled upon the issue of caam rng suspending while hwrng kthread
is still active.
For now I've fixed the issue by unregistering / re-registering caam rng
from hwrng at device suspend / resume time.
OTOH I see a few commits:
03a3bb7ae631 ("hwrng: core - Freeze khwrng thread during suspend")
ff296293b353 ("random: Support freezable kthreads in add_hwgenerator_randomness()")
59b569480dc8 ("random: Use wait_event_freezable() in add_hwgenerator_randomness()")
however they were reverted a bit later in commit
08e97aec700a ("Revert "hwrng: core - Freeze khwrng thread during suspend"")
I wasn't able to find a follow-up on this topic.
Could you advise on what's the proper thing to do going forward?
Thanks,
Horia
next prev parent reply other threads:[~2020-12-02 14:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-10 13:55 [PATCH] random: Don't freeze in add_hwgenerator_randomness() if stopping kthread Maciej S. Szmigiero
2019-11-15 6:08 ` Herbert Xu
[not found] ` <5dcee409.1c69fb81.f5027.48ad@mx.google.com>
2019-11-16 23:01 ` Maciej S. Szmigiero
2019-11-17 0:56 ` Herbert Xu
2019-11-17 4:09 ` Theodore Y. Ts'o
2020-12-02 14:28 ` Horia Geantă [this message]
2020-12-03 0:29 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2f581f84-378f-05cf-1902-f0494aafe706@nxp.com \
--to=horia.geanta@nxp.com \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=j-keerthy@ti.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=swboyd@chromium.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).