Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220915002235.v2.1.I7c0a79e9b3c52584f5b637fde5f1d6f807605806@changeid>
 <CAHmME9rhunb05DEnc=UfGr8k9_LBi1NW2Hi0OsRbGwcCN2NzjQ@mail.gmail.com> <CAM7w-FXHWzcN1Y7pwb6+1KA6A2oZRrfpOJdWFVWjRvjbp+DEOg@mail.gmail.com>
In-Reply-To: <CAM7w-FXHWzcN1Y7pwb6+1KA6A2oZRrfpOJdWFVWjRvjbp+DEOg@mail.gmail.com>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Mon, 19 Sep 2022 17:05:41 +0200
Message-ID: <CAHmME9qmiNcs6iye=Yjnpfx7vy6QMd8t8nuVOg7omOhOdkN-Hw@mail.gmail.com>
Subject: Re: [PATCH v2 1/2] random: move add_hwgenerator_randomness()'s wait
 outside function
To:     Sven van Ashbrook <svenva@chromium.org>
Cc:     Dominik Brodowski <linux@dominikbrodowski.net>,
        Peter Huewe <peterhuewe@gmx.de>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Olivia Mackall <olivia@selenic.com>,
        Alex Levin <levinale@google.com>,
        Andrey Pronin <apronin@google.com>,
        Stephen Boyd <swboyd@google.com>,
        Rajat Jain <rajatja@google.com>,
        Eric Biggers <ebiggers@google.com>,
        Petr Mladek <pmladek@suse.com>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        "Theodore Ts'o" <tytso@mit.edu>, linux-crypto@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Sep 19, 2022 at 5:03 PM Sven van Ashbrook <svenva@chromium.org> wrote:
>
> On Fri, Sep 16, 2022 at 10:51 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > The other thing that occurred to me when reading this patch in context
> > of the other one is that this sleep you're removing here is not the
> > only sleep in the call chain. Each hwrng driver can also sleep, and
> > many do, sometimes for a long time, blocking until there's data
> > available, which might happen after minutes in some cases. So maybe
> > that's something to think about in context of this patchset -- that
> > just moving this to a delayed worker might not actually fix the issue
> > you're having with sleeps.
> >
>
> This is an excellent point. A look at tpm2_calc_ordinal_duration()
> reveals that tpm_transmit() may block for 300s at a time. So when
> we are using a WQ_FREEZABLE delayed_work, the PM may have to wait
> for up to 300s when draining the wq on suspend. That will introduce
> a lot of breakage in suspend/resume.
>
> Dominik: in light of this, please proceed with your patch, without
> rebasing it onto mine.
>
> + tpm maintainers Peter Huewe and Jarkko Sakkinen, a quick recap of
> the problem:
>
> - on ChromeOS we are seeing intermittent suspend/resume errors+warnings
>   related to activity of the core's hwrng_fillfn. this kthread keeps
>   runningduring suspend/resume. if this happens to kick off an bus (i2c)
>   transaction while the bus driver is in suspend, this triggers
>   a "Transfer while suspended" warning from the i2c core, followed by
>   an error return:
>
> i2c_designware i2c_designware.1: Transfer while suspended
> tpm tpm0: i2c transfer failed (attempt 1/3): -108
> [ snip 10s of transfer failed attempts]
>
> - in 2019, Stephen Boyd made an attempt at fixing this by making the
>   hwrng_fillfn kthread freezable. But a freezable thread requires
>   different API calls for scheduling, waiting, and timeout. This
>   generated regressions, so the solution had to be reverted.
>
> https://patchwork.kernel.org/project/linux-crypto/patch/20190805233241.220521-1-swboyd@chromium.org/
>
> - the current patch attempts to halt hwrng_fillfn during suspend by
>   converting it to a self-rearming delayed_work. The PM drains all
>   work before going into suspend. But, the potential minute-long
>   blocking delays in tpm make this solution infeasible.
>
> Peter and Jarkko, can you think of a possible way forward to eliminate
> the warnings+errors?
>
> -Sven


By the way, there was a recent ath9k patch that kind of went to a
similar tune. The solution was to make ath9k's hwrng driver sleep
using a hwrng-specific sleep function that allowed the core framework
to cancel that sleep. Maybe that's a potential solution here, or
something similar to it. Might be worth taking a look at that patch. I
think it's in one of Herbert's trees.

Jason