From: Cornelia Huck <cohuck@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
linux-s390@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] virtio: hint if callbacks surprisingly might sleep
Date: Wed, 13 Feb 2019 14:44:14 +0100 [thread overview]
Message-ID: <20190213144414.6543cd22.cohuck@redhat.com> (raw)
In-Reply-To: <20190131102713-mutt-send-email-mst@kernel.org>
On Thu, 31 Jan 2019 10:27:53 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Jan 31, 2019 at 01:53:14PM +0100, Cornelia Huck wrote:
> > A virtio transport is free to implement some of the callbacks in
> > virtio_config_ops in a matter that they cannot be called from
> > atomic context (e.g. virtio-ccw, which maps a lot of the callbacks
> > to channel I/O, which is an inherently asynchronous mechanism).
> > This can be very surprising for developers using the much more
> > common virtio-pci transport, just to find out that things break
> > when used on s390.
> >
> > The documentation for virtio_config_ops now contains a comment
> > explaining this, but it makes sense to add a might_sleep() annotation
> > to various wrapper functions in the virtio core to avoid surprises
> > later.
> >
> > Note that annotations are NOT added to two classes of calls:
> > - direct calls from device drivers (all current callers should be
> > fine, however)
> > - calls which clearly won't be made from atomic context (such as
> > those ultimately coming in via the driver core)
> >
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>
>
> Makes sense to me. I don't think we should push our luck in
> this release though, better defer until the merge window.
Friendly ping, as we're quite close to the release of 5.0 now.
next prev parent reply other threads:[~2019-02-13 13:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 12:53 [PATCH RFC] virtio: hint if callbacks surprisingly might sleep Cornelia Huck
2019-01-31 15:27 ` Michael S. Tsirkin
2019-01-31 15:41 ` Cornelia Huck
2019-01-31 15:41 ` Cornelia Huck
2019-02-13 13:44 ` Cornelia Huck [this message]
2019-02-13 15:04 ` Michael S. Tsirkin
2019-02-13 15:04 ` Michael S. Tsirkin
2019-02-13 13:44 ` Cornelia Huck
2019-01-31 15:27 ` Michael S. Tsirkin
-- strict thread matches above, loose matches on Subject: below --
2019-01-31 12:53 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=20190213144414.6543cd22.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=virtualization@lists.linux-foundation.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.