linux-kernel - Re: [PATCH] aio: Add command to wait completion of all requests

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] [day] [month] [year] [list]

Message-ID: <20170614144757.GC7230@kvack.org>
Date:   Wed, 14 Jun 2017 10:47:57 -0400
From:   Benjamin LaHaise <bcrl@...ck.org>
To:     Kirill Tkhai <ktkhai@...tuozzo.com>
Cc:     avagin@...nvz.org, linux-kernel@...r.kernel.org,
        viro@...iv.linux.org.uk, gorcunov@...nvz.org,
        akpm@...ux-foundation.org, xemul@...tuozzo.com
Subject: Re: [PATCH] aio: Add command to wait completion of all requests

On Wed, Jun 14, 2017 at 12:11:38PM +0300, Kirill Tkhai wrote:
> On 14.06.2017 02:26, Benjamin LaHaise wrote:
...
> > Nope.  An aio may not complete in a timely fashion, in which case your
> > wait for all aios to complete will simply wait forever.  I take it this is
> > not the desired behaviour of checkpointing.
> 
> But read_events() does it. What the difference between them?

read_events() does not wait for all aios to complete.  The model here is
event driving programming: the program waits for an event, wakes up, does
some work, goes back to sleep until another event comes in.  Some of the
aios in flight won't complete for significant amounts of time, but that
doesn't matter since those which do complete will be processed and cause
state machines to make progress.

> >> Could you please describe how will cancelling aio requests will help to wait
> >> till their completion? Is there is guarantee, they will be easily queued back?
> >> I suppose, no, because there are may be a memory limit or some low level
> >> drivers limitations, dependent on internal conditions.
> > 
> > This is the problem you're facing.  Quiescing aios is complicated!
> 
> It's too generic words and they may refer to anything. And it's a problem,
> which is not connected with small aio engine, because it's impossible to guarantee
> availability of kernel resources from there. Imagine, parallel task eats memory
> of your just cancelled request: then you just can't queue request back.
> 
> This argument makes your suggestion not rock-stable suitable for all cases:
> it will break user applications in such situations.

Again, you're failing to understand what the programming model is for aio.

> >> Also, it's not seems good to overload aio with the functionality of obtaining
> >> closed file descriptors of submitted requests.
> >>
> >> Do you mean this way, or I misunderstood you? Could you please to concretize your
> >> idea?
> > 
> > Yes, this is what I'm talking about.
> > 
> >> In my vision cancelling requests does not allow to implement the need I described.
> >> If we can't queue request back, it breaks snapshotting and user application in
> >> general.
> > 
> > This is what you have to figure out.  This is why your patch is incomplete
> > and cannot be accepted.  You can't punt the complexity your feature
> > requires onto other maintainers -- your implementation has to be reasonably
> > complete at time of patch inclusion.  Can you see now why your patch can't
> > be included as-is?  The assumption you made that aios complete in a timely
> > fashion is incorrect.  Everything else stems from that.
> 
> I just can't see why read_events() just waits for requests completion not paying
> attention of the all above you said. Could you please clarify the difference
> between two these situations?

Read my above comments about event driven programming.  Waiting for all
aios to complete is very different from waiting for a non-specific
completion event to come along.

		-ben
-- 
"Thought is the essence of where you are now."