On Fri, Jun 05, 2020 at 04:59:18PM +1000, Herbert Xu wrote:
> The crypto notify call occurs with a read mutex held so you must
> not do any substantial work directly. In particular, you cannot
> call crypto_alloc_* as they may trigger further notifications
> which may dead-lock in the presence of
Herbert,
> The crypto notify call occurs with a read mutex held so you must not
> do any substantial work directly. In particular, you cannot call
> crypto_alloc_* as they may trigger further notifications which may
> dead-lock in the presence of another writer.
>
> This patch fixes this by pos
On Fri, Jun 05, 2020 at 11:45:27AM -0700, Eric Biggers wrote:
> How about the following:
>
> (It includes some other cleanups too, like switching to the static_branch API,
> since the static_key one is deprecated and confusing. I can split it into
> separate patches...)
I don't have objections
On Fri, Jun 05, 2020 at 11:48:46AM -0700, Eric Biggers wrote:
>
> That's only guaranteed to be true if the code is built is a loadable module.
> If
> it's built-in to the kernel, it could be called earlier, by a previous
> initcall.
That would just be a bug. The same thing can happen with any
On Sat, Jun 06, 2020 at 04:25:22AM +1000, Herbert Xu wrote:
> > That would make the checks for a NULL tfm in crc_t10dif_transform_show() and
> > crc_t10dif_notify() unnecessary. Also, it would make it so that
> > crc_t10dif_update() no longer crashes if called before module_init().
>
> crc_t10dif
On Fri, Jun 05, 2020 at 11:22:37AM -0700, Eric Biggers wrote:
>
> Wouldn't it be better to have crct10dif_fallback enabled by default, and then
> disable it once the tfm is allocated?
>
> That would make the checks for a NULL tfm in crc_t10dif_transform_show() and
> crc_t10dif_notify() unnecessar
On Fri, Jun 05, 2020 at 11:22:37AM -0700, Eric Biggers wrote:
>
> Wouldn't it be better to have crct10dif_fallback enabled by default, and then
> disable it once the tfm is allocated?
That's a semantic change. As it is if the first allocation fails
then we never try again. You can do this in a d
On Fri, Jun 05, 2020 at 04:59:18PM +1000, Herbert Xu wrote:
> The crypto notify call occurs with a read mutex held so you must
> not do any substantial work directly. In particular, you cannot
> call crypto_alloc_* as they may trigger further notifications
> which may dead-lock in the presence of
The crypto notify call occurs with a read mutex held so you must
not do any substantial work directly. In particular, you cannot
call crypto_alloc_* as they may trigger further notifications
which may dead-lock in the presence of another writer.
This patch fixes this by postponing the work into a
On Thu, Jun 04, 2020 at 10:40:49PM -0700, Eric Biggers wrote:
> On Thu, Jun 04, 2020 at 04:33:24PM +1000, Herbert Xu wrote:
> > +static void crc_t10dif_rehash(struct work_struct *work)
> > +{
> > + struct crypto_shash *new, *old;
> > +
> > mutex_lock(&crc_t10dif_mutex);
> > old = rcu_dere
On Thu, Jun 04, 2020 at 04:33:24PM +1000, Herbert Xu wrote:
> +static void crc_t10dif_rehash(struct work_struct *work)
> +{
> + struct crypto_shash *new, *old;
> +
> mutex_lock(&crc_t10dif_mutex);
> old = rcu_dereference_protected(crct10dif_tfm,
>
The crypto notify call occurs with a read mutex held so you must
not do any substantial work directly. In particular, you cannot
call crypto_alloc_* as they may trigger further notifications
which may dead-lock in the presence of another writer.
This patch fixes this by postponing the work into a
12 matches
Mail list logo
