From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: linux-s390@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>,
Pierre Morel <pmorel@linux.ibm.com>,
kvm@vger.kernel.org, Farhan Ali <alifm@linux.ibm.com>,
qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
qemu-s390x@nongnu.org
Subject: Re: [PATCH v2 2/5] vfio-ccw: concurrent I/O handling
Date: Mon, 28 Jan 2019 18:31:24 +0100 [thread overview]
Message-ID: <20190128183124.3d73ac6e.cohuck@redhat.com> (raw)
In-Reply-To: <d1f84cbc-2caf-1bd8-8607-79d5a3f9eb6d@linux.ibm.com>
On Fri, 25 Jan 2019 15:22:56 -0500
Eric Farman <farman@linux.ibm.com> wrote:
> If we come into mdev_write with state=BUSY and we get the lock,
> copy_from_user, and do our jump table we go to fsm_io_busy to set
> ret_code and return -EAGAIN. Why then don't we set the jump table for
> state=NOT_OPER||STANDBY to do something that will return -EACCES instead
> of how we currently do a direct return of -EACCES before all the
> lock/copy stuff (and the jump table that would take us to fsm_io_error
> and an error message before returning -EIO)?
If you phrase it like that, I'm wondering why we're not already doing
it that way :) We just need to make sure to revert to the previous
state on error instead of IDLE.
next prev parent reply other threads:[~2019-01-28 17:31 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 11:03 [PATCH v2 0/5] vfio-ccw: support hsch/csch (kernel part) Cornelia Huck
2019-01-21 11:03 ` [PATCH v2 1/5] vfio-ccw: make it safe to access channel programs Cornelia Huck
2019-01-22 14:56 ` Halil Pasic
2019-01-22 15:19 ` Cornelia Huck
2019-01-21 11:03 ` [PATCH v2 2/5] vfio-ccw: concurrent I/O handling Cornelia Huck
2019-01-21 20:20 ` Halil Pasic
2019-01-22 10:29 ` Cornelia Huck
2019-01-22 11:17 ` Halil Pasic
2019-01-22 11:53 ` Cornelia Huck
2019-01-22 12:46 ` Halil Pasic
2019-01-22 17:26 ` Cornelia Huck
2019-01-22 19:03 ` Halil Pasic
2019-01-23 10:34 ` Cornelia Huck
2019-01-23 13:06 ` Halil Pasic
2019-01-23 13:34 ` Cornelia Huck
2019-01-24 19:16 ` Eric Farman
2019-01-25 10:13 ` Cornelia Huck
2019-01-22 18:33 ` Halil Pasic
2019-01-23 10:21 ` Cornelia Huck
2019-01-23 13:30 ` Halil Pasic
2019-01-24 10:05 ` Cornelia Huck
2019-01-24 10:08 ` Pierre Morel
2019-01-24 10:19 ` Cornelia Huck
2019-01-24 11:18 ` Pierre Morel
2019-01-24 11:45 ` Halil Pasic
2019-01-24 19:14 ` Eric Farman
2019-01-25 2:25 ` Eric Farman
2019-01-25 2:37 ` Eric Farman
2019-01-25 10:24 ` Cornelia Huck
2019-01-25 12:58 ` Cornelia Huck
2019-01-25 14:01 ` Halil Pasic
2019-01-25 14:21 ` Cornelia Huck
2019-01-25 16:04 ` Halil Pasic
2019-01-28 17:13 ` Cornelia Huck
2019-01-28 19:30 ` Halil Pasic
2019-01-29 9:58 ` Cornelia Huck
2019-01-29 19:39 ` Halil Pasic
2019-01-30 13:29 ` Cornelia Huck
2019-01-30 14:32 ` Farhan Ali
2019-01-28 17:09 ` Cornelia Huck
2019-01-28 19:15 ` Halil Pasic
2019-01-28 21:48 ` Eric Farman
2019-01-29 10:20 ` Cornelia Huck
2019-01-29 14:14 ` Eric Farman
2019-01-29 18:53 ` Cornelia Huck
2019-01-29 10:10 ` Cornelia Huck
2019-01-25 15:57 ` Eric Farman
2019-01-28 17:24 ` Cornelia Huck
2019-01-28 21:50 ` Eric Farman
2019-01-25 20:22 ` Eric Farman
2019-01-28 17:31 ` Cornelia Huck [this message]
2019-01-25 13:09 ` Halil Pasic
2019-01-25 12:58 ` Halil Pasic
2019-01-25 20:21 ` Eric Farman
2019-01-21 11:03 ` [PATCH v2 3/5] vfio-ccw: add capabilities chain Cornelia Huck
2019-01-23 15:57 ` [qemu-s390x] " Halil Pasic
2019-01-25 16:19 ` Eric Farman
2019-01-25 21:00 ` Eric Farman
2019-01-28 17:34 ` Cornelia Huck
2019-01-21 11:03 ` [PATCH v2 4/5] s390/cio: export hsch to modules Cornelia Huck
2019-01-22 15:21 ` [qemu-s390x] " Halil Pasic
2019-01-21 11:03 ` [PATCH v2 5/5] vfio-ccw: add handling for async channel instructions Cornelia Huck
2019-01-23 15:51 ` Halil Pasic
2019-01-24 10:06 ` Cornelia Huck
2019-01-24 10:37 ` Halil Pasic
2019-01-25 21:00 ` Eric Farman
2019-01-28 17:40 ` Cornelia Huck
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=20190128183124.3d73ac6e.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=farman@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.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).