Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1639257
| From | Gilad Ben-Yossef <gilad@benyossef.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC 01/10] crypto: factor async completion for general use |
| Date | 2017-05-11 11:00 +0200 |
| Message-ID | <tFS6Z-47s-5@gated-at.bofh.it> (permalink) |
| References | <tE7Dc-8v0-3@gated-at.bofh.it> <tE7Dc-8v0-7@gated-at.bofh.it> <tFNqF-14Z-1@gated-at.bofh.it> <tFQRA-3na-19@gated-at.bofh.it> <tFRkC-3Q2-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, May 11, 2017 at 11:09 AM, Eric Biggers <ebiggers3@gmail.com> wrote: > On Thu, May 11, 2017 at 10:29:47AM +0300, Gilad Ben-Yossef wrote: >> > With regards to the wait being uninterruptible, I agree that this should be the >> > default behavior, because I think users waiting for specific crypto requests are >> > generally not prepared to handle the wait actually being interrupted. After >> > interruption the crypto operation will still proceed in the background, and it >> > will use buffers which the caller has in many cases already freed. However, I'd >> > suggest taking a close look at anything that was actually doing an interruptible >> > wait before, to see whether it was a bug or intentional (or "doesn't matter"). >> > >> > And yes there could always be a crypto_wait_req_interruptible() introduced if >> > some users need it. >> >> So this one was a bit of a shocker. I though the _interruptible use >> sites seemed >> wrong in the sense of being needless. However, after reading your feedback and >> reviewing the code I'm pretty sure every single one of them (including >> the one I've >> added in dm-verity-target.c this merge window) are down right dangerous and >> can cause random data corruption... so thanks for pointing this out! >> >> I though of this patch set as a "make the code pretty" for 4.13 kind >> of patch set. >> Looks like it's a bug fix now, maybe even stable material. >> >> Anyway, I'll roll a v2 and we'll see. >> > > Any that are called only by kernel threads would theoretically be safe since > kernel threads don't ordinarily receive signals. But I think that at least the > drbg and gcm waits can be reached by user threads, since they can be called via > algif_rng and algif_aead respectively. > > I recommend putting any important fixes first, so they can be backported without > depending on crypto_wait_req(). > OK, I'll send out a separate bug fix series first and rebase the crypto_wait one on top of it then. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RFC 01/10] crypto: factor async completion for general use Gilad Ben-Yossef <gilad@benyossef.com> - 2017-05-06 15:10 +0200
Re: [RFC 01/10] crypto: factor async completion for general use Eric Biggers <ebiggers3@gmail.com> - 2017-05-11 06:00 +0200
Re: [RFC 01/10] crypto: factor async completion for general use Gilad Ben-Yossef <gilad@benyossef.com> - 2017-05-11 09:40 +0200
Re: [RFC 01/10] crypto: factor async completion for general use Eric Biggers <ebiggers3@gmail.com> - 2017-05-11 10:10 +0200
Re: [RFC 01/10] crypto: factor async completion for general use Gilad Ben-Yossef <gilad@benyossef.com> - 2017-05-11 11:00 +0200
csiph-web