From: Eric Farman <farman@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
Farhan Ali <alifm@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org,
qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 1/6] vfio-ccw: make it safe to access channel programs
Date: Mon, 4 Feb 2019 14:25:34 -0500 [thread overview]
Message-ID: <9b35717e-8994-cde9-2afe-243ab80c371a@linux.ibm.com> (raw)
In-Reply-To: <20190130132212.7376-2-cohuck@redhat.com>
On 01/30/2019 08:22 AM, Cornelia Huck wrote:
> When we get a solicited interrupt, the start function may have
> been cleared by a csch, but we still have a channel program
> structure allocated. Make it safe to call the cp accessors in
> any case, so we can call them unconditionally.
>
> While at it, also make sure that functions called from other parts
> of the code return gracefully if the channel program structure
> has not been initialized (even though that is a bug in the caller).
>
> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> ---
> drivers/s390/cio/vfio_ccw_cp.c | 20 +++++++++++++++++++-
> drivers/s390/cio/vfio_ccw_cp.h | 2 ++
> drivers/s390/cio/vfio_ccw_fsm.c | 5 +++++
> 3 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> index ba08fe137c2e..0bc0c38edda7 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -335,6 +335,7 @@ static void cp_unpin_free(struct channel_program *cp)
> struct ccwchain *chain, *temp;
> int i;
>
> + cp->initialized = false;
> list_for_each_entry_safe(chain, temp, &cp->ccwchain_list, next) {
> for (i = 0; i < chain->ch_len; i++) {
> pfn_array_table_unpin_free(chain->ch_pat + i,
> @@ -701,6 +702,8 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)
> */
> cp->orb.cmd.c64 = 1;
>
> + cp->initialized = true;
> +
Not seen in this hunk, but we call ccwchain_loop_tic() just prior to
this point. If that returns non-zero, we call cp_unpin_free()[1] (and
set initailized to false), and then fall through to here. So this is
going to set initialized to true, even though we're taking an error
path. :-(
[1] Wait, why is it calling cp_unpin_free()? Oh, I had proposed
squashing cp_free() and cp_unpin_free() back in November[2], got an r-b
from Pierre but haven't gotten back to tidy up the series for a v2.
Okay, I'll try to do that again soon. :-)
[2] https://patchwork.kernel.org/patch/10675261/
> return ret;
> }
>
> @@ -715,7 +718,8 @@ int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)
> */
> void cp_free(struct channel_program *cp)
> {
> - cp_unpin_free(cp);
> + if (cp->initialized)
> + cp_unpin_free(cp);
> }
>
> /**
> @@ -760,6 +764,10 @@ int cp_prefetch(struct channel_program *cp)
> struct ccwchain *chain;
> int len, idx, ret;
>
> + /* this is an error in the caller */
> + if (!cp || !cp->initialized)
> + return -EINVAL;
> +
> list_for_each_entry(chain, &cp->ccwchain_list, next) {
> len = chain->ch_len;
> for (idx = 0; idx < len; idx++) {
> @@ -795,6 +803,10 @@ union orb *cp_get_orb(struct channel_program *cp, u32 intparm, u8 lpm)
> struct ccwchain *chain;
> struct ccw1 *cpa;
>
> + /* this is an error in the caller */
> + if (!cp || !cp->initialized)
> + return NULL;
> +
> orb = &cp->orb;
>
> orb->cmd.intparm = intparm;
> @@ -831,6 +843,9 @@ void cp_update_scsw(struct channel_program *cp, union scsw *scsw)
> u32 cpa = scsw->cmd.cpa;
> u32 ccw_head, ccw_tail;
>
> + if (!cp->initialized)
> + return;
> +
> /*
> * LATER:
> * For now, only update the cmd.cpa part. We may need to deal with
> @@ -869,6 +884,9 @@ bool cp_iova_pinned(struct channel_program *cp, u64 iova)
> struct ccwchain *chain;
> int i;
>
> + if (!cp->initialized)
So, two of the checks added above look for a nonzero cp pointer prior to
checking initialized, while two don't. I guess cp can't be NULL, since
it's embedded in the private struct directly and that's only free'd when
we do vfio_ccw_sch_remove() ... But I guess some consistency in how we
look would be nice.
> + return false;
> +
> list_for_each_entry(chain, &cp->ccwchain_list, next) {
> for (i = 0; i < chain->ch_len; i++)
> if (pfn_array_table_iova_pinned(chain->ch_pat + i,
> diff --git a/drivers/s390/cio/vfio_ccw_cp.h b/drivers/s390/cio/vfio_ccw_cp.h
> index a4b74fb1aa57..3c20cd208da5 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.h
> +++ b/drivers/s390/cio/vfio_ccw_cp.h
> @@ -21,6 +21,7 @@
> * @ccwchain_list: list head of ccwchains
> * @orb: orb for the currently processed ssch request
> * @mdev: the mediated device to perform page pinning/unpinning
> + * @initialized: whether this instance is actually initialized
> *
> * @ccwchain_list is the head of a ccwchain list, that contents the
> * translated result of the guest channel program that pointed out by
> @@ -30,6 +31,7 @@ struct channel_program {
> struct list_head ccwchain_list;
> union orb orb;
> struct device *mdev;
> + bool initialized;
> };
>
> extern int cp_init(struct channel_program *cp, struct device *mdev,
> diff --git a/drivers/s390/cio/vfio_ccw_fsm.c b/drivers/s390/cio/vfio_ccw_fsm.c
> index cab17865aafe..e7c9877c9f1e 100644
> --- a/drivers/s390/cio/vfio_ccw_fsm.c
> +++ b/drivers/s390/cio/vfio_ccw_fsm.c
> @@ -31,6 +31,10 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
> private->state = VFIO_CCW_STATE_BUSY;
>
> orb = cp_get_orb(&private->cp, (u32)(addr_t)sch, sch->lpm);
> + if (!orb) {
> + ret = -EIO;
> + goto out;
> + }
>
> /* Issue "Start Subchannel" */
> ccode = ssch(sch->schid, orb);
> @@ -64,6 +68,7 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
> default:
> ret = ccode;
> }
> +out:
> spin_unlock_irqrestore(sch->lock, flags);
> return ret;
> }
>
next prev parent reply other threads:[~2019-02-04 19:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 13:22 [Qemu-devel] [PATCH v3 0/6] vfio-ccw: support hsch/csch (kernel part) Cornelia Huck
2019-01-30 13:22 ` [Qemu-devel] [PATCH v3 1/6] vfio-ccw: make it safe to access channel programs Cornelia Huck
2019-01-30 18:51 ` Halil Pasic
2019-01-31 11:52 ` Cornelia Huck
2019-01-31 12:34 ` Halil Pasic
2019-02-04 15:31 ` Cornelia Huck
2019-02-05 11:52 ` Halil Pasic
2019-02-05 12:35 ` Cornelia Huck
2019-02-05 14:48 ` Eric Farman
2019-02-05 15:14 ` Farhan Ali
2019-02-05 16:13 ` Cornelia Huck
2019-02-04 19:25 ` Eric Farman [this message]
2019-02-05 12:03 ` Cornelia Huck
2019-02-05 14:41 ` Eric Farman
2019-02-05 16:29 ` Cornelia Huck
2019-01-30 13:22 ` [Qemu-devel] [PATCH v3 2/6] vfio-ccw: rework ssch state handling Cornelia Huck
2019-02-04 21:29 ` Eric Farman
2019-02-05 12:10 ` Cornelia Huck
2019-02-05 14:31 ` Eric Farman
2019-02-05 16:32 ` Cornelia Huck
2019-01-30 13:22 ` [Qemu-devel] [PATCH v3 3/6] vfio-ccw: protect the I/O region Cornelia Huck
2019-02-08 21:26 ` Eric Farman
2019-02-11 15:57 ` Cornelia Huck
2019-01-30 13:22 ` [Qemu-devel] [PATCH v3 4/6] vfio-ccw: add capabilities chain Cornelia Huck
2019-02-15 15:46 ` Eric Farman
2019-02-19 11:06 ` Cornelia Huck
2019-01-30 13:22 ` [Qemu-devel] [PATCH v3 5/6] s390/cio: export hsch to modules Cornelia Huck
2019-01-30 13:22 ` [Qemu-devel] [PATCH v3 6/6] vfio-ccw: add handling for async channel instructions Cornelia Huck
2019-01-30 17:00 ` Halil Pasic
2019-01-30 17:09 ` Halil Pasic
2019-01-31 11:53 ` Cornelia Huck
2019-02-06 14:00 ` [Qemu-devel] [PATCH v3 0/6] vfio-ccw: support hsch/csch (kernel part) Cornelia Huck
2019-02-08 21:19 ` Eric Farman
2019-02-11 16:13 ` Cornelia Huck
2019-02-11 17:37 ` Eric Farman
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=9b35717e-8994-cde9-2afe-243ab80c371a@linux.ibm.com \
--to=farman@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=cohuck@redhat.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).