All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Cc: Dong Jia Shi <bjsdjshi@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfio-ccw: process ssch with interrupts disabled
Date: Mon, 16 Apr 2018 11:35:57 +0200	[thread overview]
Message-ID: <20180416113557.25d4fbbb.cohuck@redhat.com> (raw)
In-Reply-To: <20180416021312.GO12194@bjsdjshi@linux.vnet.ibm.com>

On Mon, 16 Apr 2018 10:13:12 +0800
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:

> * Cornelia Huck <cohuck@redhat.com> [2018-04-13 16:05:09 +0200]:
> 
> > When we call ssch, an interrupt might already be pending once we
> > return from the START SUBCHANNEL instruction. Therefore we need to
> > make sure interrupts are disabled until after we're done with our
> > processing.  
> Sounds right.
> 
> > 
> > Note that the subchannel lock is the same as the ccwdevice lock that
> > is mentioned in the documentation for ccw_device_start() and friends.  
> I think this is helpful hint for me to understand the correct way of
> using sch->lock in our context, but not sure if the word "same" brings
> confusion to the others. There are many difference between them,
> considering the fact that sch->lock exists in the CSS driver for a long
> time already, and it is not external interface like ccw_dev->lock, and
> its usage is different with ccw_dev->lock in the existing code.
> It's because vfio-ccw are offering interface to the external world based
> directly on the css driver level, it makes the purpose of protecting
> what should be protected with it becomes the same.
> 
> Not a problem for me, but better with a better rewording?

Huh, my intention was to clarify things, not to make them more
confusing :)

The documentation for ccw_device_start() and friends seems to be the
only place where we explicitly state locking requirements, so that's
where I came from. Maybe simply reword the first paragraph to mention
the lock?

"When we call ssch, an interrupt might already be pending once we
return from the START SUBCHANNEL instruction. Therefore we need to make
sure interrupts are disabled while holding the subchannel lock until
after we're done with our processing."

Or maybe things are already clear enough from the code?
> 
> > 
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> > ---
> >  drivers/s390/cio/vfio_ccw_fsm.c | 19 ++++++++++++-------
> >  1 file changed, 12 insertions(+), 7 deletions(-)

> LGTM:
> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.ibm.com>
> 

Thanks!

  parent reply	other threads:[~2018-04-16  9:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 14:05 [PATCH] vfio-ccw: process ssch with interrupts disabled Cornelia Huck
     [not found] ` <20180416021312.GO12194@bjsdjshi@linux.vnet.ibm.com>
2018-04-16  9:35   ` Cornelia Huck [this message]
     [not found] ` <20180418082931.GO5428@bjsdjshi@linux.vnet.ibm.com>
2018-04-19  9:16   ` Cornelia Huck
2018-04-19 12:01 ` Halil Pasic
2018-04-19 14:14 ` Pierre Morel
2018-04-19 15:22   ` 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=20180416113557.25d4fbbb.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=bjsdjshi@linux.ibm.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.ibm.com \
    /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.