From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian.Jackson@eu.citrix.com, jeremy@goop.org,
xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify
Date: Mon, 24 Oct 2011 16:57:08 -0400 [thread overview]
Message-ID: <20111024205708.GE2441@phenom.dumpdata.com> (raw)
In-Reply-To: <1318971851-12809-3-git-send-email-dgdegra@tycho.nsa.gov>
On Tue, Oct 18, 2011 at 05:04:11PM -0400, Daniel De Graaf wrote:
> When using the unmap notify ioctl, the event channel used for
> notification needs to be reserved to avoid it being deallocated prior to
> sending the notification.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
> drivers/xen/gntalloc.c | 14 +++++++++++++-
> drivers/xen/gntdev.c | 11 +++++++++++
> 2 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
> index f6832f4..a739fb1 100644
> --- a/drivers/xen/gntalloc.c
> +++ b/drivers/xen/gntalloc.c
> @@ -178,8 +178,10 @@ static void __del_gref(struct gntalloc_gref *gref)
> tmp[gref->notify.pgoff] = 0;
> kunmap(gref->page);
> }
> - if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
> + if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
> notify_remote_via_evtchn(gref->notify.event);
> + evtchn_put(gref->notify.event);
So.. I could have some fun by doing this in the userspace:
for (j = 0; j< 2;j++) {
for (i = 0; i < 65534; i++) {
struct ioctl_gntalloc_unmap_notify uarg = {
.index = arg.index + offsetof(struct shr_page, notifies[0]),
.action =UNMAP_NOTIFY_SEND_EVENT,
.event_channel_port = i,
};
rv = ioctl(a_fd, IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, &uarg);
}
}
And cause the event channel refcnt to be set to zero and free it. And then
causing the box to die - as the event channels for the physical IRQ might have
gotten free-ed.
Hm.. Perhaps the gntalloc and gntdev should keep track of which event channels
are OK to refcnt? Something like a whitelist? Granted at that point the refcounting
could as well be done by the API that sets up the event channels from the userspace.
So the evtchn_ioctl is pretty smart. It uses "get_port_user" to get the list
of events that belong to this user (and have been handed out). I think you
need to use that in the gntalloc to double-check that the event channel is not
one of the kernel type.
> + }
>
> gref->notify.flags = 0;
>
> @@ -396,6 +398,16 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv,
> goto unlock_out;
> }
>
> + if (op.action & UNMAP_NOTIFY_SEND_EVENT) {
> + if (evtchn_get(op.event_channel_port)) {
> + rc = -EINVAL;
> + goto unlock_out;
> + }
> + }
> +
> + if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
> + evtchn_put(gref->notify.event);
> +
> gref->notify.flags = op.action;
> gref->notify.pgoff = pgoff;
> gref->notify.event = op.event_channel_port;
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index f914b26..cfcc890 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -190,6 +190,7 @@ static void gntdev_put_map(struct grant_map *map)
>
> if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
> notify_remote_via_evtchn(map->notify.event);
> + evtchn_put(map->notify.event);
> }
>
> if (map->pages) {
> @@ -596,6 +597,16 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
> goto unlock_out;
> }
>
> + if (op.action & UNMAP_NOTIFY_SEND_EVENT) {
> + if (evtchn_get(op.event_channel_port)) {
> + rc = -EINVAL;
> + goto unlock_out;
> + }
> + }
> +
> + if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
So notify.flags has not been set yet? That looks to be done later?
Or is this in case of the user doing
uargs.action = UNMAP_NOTIFY_SEND_EVENT;
ioctl(.., IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, &uarg);
uargs.action = UNAMP_NOTIFY_CLEAR_BYTE;
ioctl(.., IOCTL_GNTALLOC_SET_UNMAP_NOTIFY, &uarg);
and we want to preserve the "old" flags before swapping over to the
new?
> + evtchn_put(map->notify.event);
> +
> map->notify.flags = op.action;
> map->notify.addr = op.index - (map->index << PAGE_SHIFT);
> map->notify.event = op.event_channel_port;
> --
> 1.7.6.4
next prev parent reply other threads:[~2011-10-24 20:57 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-16 21:14 [PATCH 0/2] Add reference counting to grant notify ioctls Daniel De Graaf
2011-09-16 21:14 ` [PATCH 1/2] xen/event: Add reference counting to event channel Daniel De Graaf
2011-09-17 4:50 ` Jeremy Fitzhardinge
2011-09-17 6:11 ` Keir Fraser
2011-09-19 15:50 ` Daniel De Graaf
2011-09-19 16:22 ` Jeremy Fitzhardinge
2011-09-19 17:53 ` Daniel De Graaf
2011-09-16 21:14 ` [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify Daniel De Graaf
2011-10-18 21:04 ` [PATCH v2 0/2] Add reference counting to grant notify ioctls Daniel De Graaf
2011-10-18 21:04 ` [PATCH 1/2] xen/event: Add reference counting to event channel Daniel De Graaf
2011-10-19 9:20 ` Ian Campbell
2011-10-24 20:22 ` Konrad Rzeszutek Wilk
2011-10-24 22:20 ` Daniel De Graaf
2011-10-25 19:05 ` Konrad Rzeszutek Wilk
2011-10-25 8:17 ` Ian Campbell
2011-10-25 19:09 ` Konrad Rzeszutek Wilk
2011-10-25 20:44 ` Ian Campbell
2011-10-18 21:04 ` [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify Daniel De Graaf
2011-10-19 9:24 ` Ian Campbell
2011-10-19 14:23 ` Daniel De Graaf
2011-10-19 14:45 ` [PATCH 2/2] xen/gnt{dev,alloc}: " Ian Campbell
2011-10-24 20:57 ` Konrad Rzeszutek Wilk [this message]
2011-10-24 22:01 ` [PATCH 2/2] xen/gnt{dev, alloc}: " Daniel De Graaf
2011-10-25 19:02 ` Konrad Rzeszutek Wilk
2011-10-25 19:41 ` Daniel De Graaf
2011-10-25 19:51 ` Konrad Rzeszutek Wilk
2011-10-25 20:27 ` Ian Campbell
2011-10-25 20:42 ` Daniel De Graaf
2011-10-25 20:50 ` Ian Campbell
2011-10-25 21:07 ` Daniel De Graaf
2011-10-26 15:47 ` [PATCH v3 0/3] Add reference counting to grant notify ioctls Daniel De Graaf
2011-10-26 15:47 ` [PATCH 1/3] xen/event: Add reference counting to event channels Daniel De Graaf
2011-10-26 16:51 ` Ian Campbell
2011-10-26 16:57 ` Ian Campbell
2011-10-26 17:28 ` Daniel De Graaf
2011-10-27 9:03 ` Ian Campbell
2011-10-26 18:42 ` [PATCH 1/3 v3.2] " Daniel De Graaf
2011-10-26 15:47 ` [PATCH 2/3] xen/gntalloc: Change gref_lock to a mutex Daniel De Graaf
2011-10-26 15:47 ` [PATCH 3/3] xen/gnt{dev, alloc}: reserve event channels for notify Daniel De Graaf
2011-10-27 21:58 ` [PATCH v4 0/3] Add reference counting to grant notify ioctls Daniel De Graaf
2011-10-27 21:58 ` [PATCH 1/3] xen/event: Add reference counting to event channels Daniel De Graaf
2011-10-27 21:58 ` [PATCH 2/3] xen/gntalloc: Change gref_lock to a mutex Daniel De Graaf
2011-10-27 21:58 ` [PATCH 3/3] xen/gnt{dev, alloc}: reserve event channels for notify Daniel De Graaf
2011-11-11 20:33 ` [PATCH v4 0/3] Add reference counting to grant notify ioctls Konrad Rzeszutek Wilk
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=20111024205708.GE2441@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=jeremy@goop.org \
--cc=keir@xen.org \
--cc=xen-devel@lists.xensource.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.