From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 for-4.6 3/3] tools/libxl: Only continue stream operations if the stream is still in progress
Date: Tue, 28 Jul 2015 16:21:14 +0100 [thread overview]
Message-ID: <55B79DEA.2040801@citrix.com> (raw)
In-Reply-To: <21943.39885.704950.477219@mariner.uk.xensource.com>
On 28/07/15 16:12, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v2 for-4.6 3/3] tools/libxl: Only continue stream operations if the stream is still in progress"):
>> Imagine a scenario whereby some error has occured and
>> check_all_finished() has _abort()'ed the tasks, but the save helper was
>> already on the way out, signalling success.
> ...
>> It is only save to stream_continue() if the stream is currently in use,
>> which is not a guaranteed situation in this function even if rc is 0.
erm s/save/safe/
> Hrm. Yes.
>
> What do you think about putting the inuse check in stream_continue ?
That would work on the stream_read side but not the stream_write side,
but is not really correct IMO.
The _inuse() check is needed because the save helper callback is not
sure whether the stream is in use or not. This is a property of the
save helper callback, rather than the stream.
Pushing the _inuse() check into the next layer would function, but it
adds extra _inuse() checks to other codepaths which should be fatal if
they failed in other contexts.
Would resubmitting with extra comments explaining this suffice?
~Andrew
next prev parent reply other threads:[~2015-07-28 15:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 16:47 [PATCH v2 for-4.6 0/3] Fixes to stream v2 task joining logic Andrew Cooper
2015-07-27 16:47 ` [PATCH v2 for-4.6 1/3] tools/libxl: Do not set stream->rc in stream_complete() Andrew Cooper
2015-07-28 10:26 ` Ian Jackson
2015-07-27 16:47 ` [PATCH v2 for-4.6 2/3] tools/libxl: Do not fire the stream callback multiple times Andrew Cooper
2015-07-28 10:27 ` Ian Jackson
2015-07-27 16:47 ` [PATCH v2 for-4.6 3/3] tools/libxl: Only continue stream operations if the stream is still in progress Andrew Cooper
2015-07-28 13:41 ` Ian Jackson
2015-07-28 13:56 ` Andrew Cooper
2015-07-28 15:12 ` Ian Jackson
2015-07-28 15:21 ` Andrew Cooper [this message]
2015-07-28 15:59 ` Ian Jackson
2015-07-28 16:52 ` Andrew Cooper
2015-07-28 17:07 ` Ian Jackson
2015-07-29 14:17 ` Ian Campbell
2015-07-29 14:18 ` Ian Campbell
2015-07-28 13:27 ` [PATCH v2 for-4.6 0/3] Fixes to stream v2 task joining logic Ian Campbell
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=55B79DEA.2040801@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.