linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stephan Müller" <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
Date: Fri, 13 Jan 2017 11:49:05 +0100	[thread overview]
Message-ID: <1588177.ehMkkoOMrj@positron.chronox.de> (raw)
In-Reply-To: <20170113102145.GA23349@gondor.apana.org.au>

Am Freitag, 13. Januar 2017, 18:21:45 CET schrieb Herbert Xu:

Hi Herbert,

> On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote:
> > > I don't understand, what's wrong with:
> > > 
> > > sendmsg(fd, ...)
> > > aio_read(iocb1)
> > > sendmsg(fd, ...)
> > > aio_read(iocb2)
> > 
> > Sure, that works. But here you limit yourself to one IOCB per aio_read.
> > But
> > aio_read supports multiple IOCBs in one invocation. And this is the issue
> > I am considering.
> 
> Not really.  You just lay it out in the same way with lio_listio.
> That is, a write followed by read, etc.

According to the man page of lio_listio(3) the provided AIO operations are 
executed in an unspecified order. I would infer from that statement that even 
if an order of write / read / write / read is defined by the caller, this 
order may not be followed by the kernel. Thus we would need to consider the 
case that in the end, algif has to process the order of write / write / read / 
read or any other order.

Besides, the crashes I reported for the current AIO implementation in 
algif_aead and algif_skcipher are always triggered when invoking an aio_read 
with two or more IOCBs. The most important aspect I want to cover with the 
patch set is to stop crashing the kernel.

Ciao
Stephan

  reply	other threads:[~2017-01-13 10:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-25 17:13 [PATCH 0/2] crypto: AF_ALG memory management fix Stephan Müller
2016-12-25 17:15 ` [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management Stephan Müller
2017-01-12 15:51   ` Herbert Xu
2017-01-12 15:56     ` Stephan Müller
2017-01-12 16:05       ` Stephan Müller
2017-01-12 16:07         ` Herbert Xu
2017-01-12 16:10           ` Stephan Müller
2017-01-12 16:17             ` Herbert Xu
2017-01-12 16:19               ` Stephan Müller
2017-01-13 10:21                 ` Herbert Xu
2017-01-13 10:49                   ` Stephan Müller [this message]
2017-01-13 11:03                     ` Herbert Xu
2017-01-13 11:10                       ` Stephan Müller
2017-01-13 11:12                         ` Herbert Xu
2017-01-13 11:16                           ` Stephan Müller
2017-01-13 11:25                             ` Herbert Xu
2017-01-13 11:51                               ` Stephan Müller
2017-01-16 13:41                               ` Stephan Müller
2016-12-25 17:15 ` [PATCH 2/2] crypto: skcipher " Stephan Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1588177.ehMkkoOMrj@positron.chronox.de \
    --to=smueller@chronox.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).