linux-kernel - Re: [PATCH] padata: Remove broken queue flushing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191119215345.jr7y47b37ivshwcm@gondor.apana.org.au>
Date:   Wed, 20 Nov 2019 05:53:45 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Daniel Jordan <daniel.m.jordan@...cle.com>
Cc:     Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] padata: Remove broken queue flushing

On Tue, Nov 19, 2019 at 02:24:05PM -0500, Daniel Jordan wrote:
>
> __padata_free unconditionally frees pd, so a padata job might choke on it
> later.  padata_do_parallel calls seem safe because they use RCU, but it seems
> possible that a job could call padata_do_serial after the instance is gone.

Actually __padata_free no longer frees the pd after my patch.

We should also mandate that __padata_free can only be called after
all jobs have completed.  This is already the case with pcrypt.

In fact we should discuss merging padata into pcrypt.  It's been
10 years and not a single user of padata has emerged in the kernel.

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