Date:   Fri, 10 Mar 2023 12:21:34 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= <toke@redhat.com>
Cc:     Horia =?utf-8?Q?Geant=C4=83?= <horia.geanta@nxp.com>,
        Pankaj Gupta <pankaj.gupta@nxp.com>,
        Gaurav Jain <gaurav.jain@nxp.com>,
        Mathew McBride <matt@traverse.com.au>,
        linux-crypto@vger.kernel.org
Subject: Re: Hitting BUG_ON in crypto_unregister_alg() on reboot with
 caamalg_qi2 driver
Message-ID: <ZAqwTqw3lR+dnImO@gondor.apana.org.au>
References: <87r0tyq8ph.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87r0tyq8ph.fsf@toke.dk>
Precedence: bulk

On Thu, Mar 09, 2023 at 03:51:22PM +0100, Toke H?iland-J?rgensen wrote:
> Hi folks
> 
> I'm hitting what appears to be a deliberate BUG_ON() in
> crypto_unregister_alg() when rebooting my traverse ten64 device on a
> 6.2.2 kernel (using the Arch linux-aarch64 build, which is basically an
> upstream kernel).
> 
> Any idea what might be causing this? It does not appear on an older
> (5.17, which is the newest kernel that works reliably, for unrelated
> reasons).

On the face of it this looks like a generic issue with drivers
and the Crypto API.  Historically crypto modules weren't meant
to be removed/unregistered until the last user has freed the tfm.

Obviously with drivers that start unregistering the algorithms when
the hardware goes away this paradigm breaks.  What should happen is
that the driver continues to hold onto the crypto algorithm registration
even when the hardware has gone away.

Some work has to be done in the driver to actually make this safe
(all the drivers I've looked at are broken in this way).

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt