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 1/2] xen/event: Add reference counting to event channel
Date: Mon, 24 Oct 2011 16:22:42 -0400 [thread overview]
Message-ID: <20111024202242.GD2441@phenom.dumpdata.com> (raw)
In-Reply-To: <1318971851-12809-2-git-send-email-dgdegra@tycho.nsa.gov>
On Tue, Oct 18, 2011 at 05:04:10PM -0400, Daniel De Graaf wrote:
> Event channels exposed to userspace by the evtchn module may be used by
> other modules in an asynchronous manner, which requires that reference
> counting be used to prevent the event channel from being closed before
> the signals are delivered.
You should probably also remove the comment in "xen_bind_pirq_gsi_to_irq"
which talks about refcount (as the comment would now apply to this code and
might confuse people reading the code).
There are two scenarios I am concerned about:
1). Xen pciback allocates/setups an physical IRQ on behalf of a guest. Lets
concentrate on MSI as that is more interesting. The PV guests sends
XEN_PCI_OP_enable_msi, dom0 calls pci_enable_msi(), MSI libs end up calling
xen_initdom_setup_msi_irqs, which calls xen_bind_pirq_msi_to_irq and
irq->refcnt==2.
Guest dies without calling XEN_PCI_OP_disable_msi, so we end up in
xen_pcibk_reset_device which calls pci_disable_msi().. which calls xen_free_irq().
And all of that sets refcnt==1.. OK, and if we do call xen_pcibk_reset_device()
again it is smart enough _not_ to call pci_disable_msi() twice.
So I guess that case is actually OK, but if there was a driver that decided to
call pci_disable_msi (or pci_disable_irq) we could hit the BUG_ON(). Perhaps
that should be altered to WARN_ON.
2). Grantdev holding the refcnt forever. That is probably the easiest as it would
be a bug in the code.
Hmm, I think I've talked myself out of actually finding any cases where this would
be problematic from a design perspective. The only issue I can see is exposing bugs
in the users of event channel API - which there might be. So definitly needs some
heavy duty testing.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
> drivers/xen/events.c | 34 ++++++++++++++++++++++++++++++++++
> include/xen/events.h | 6 ++++++
> 2 files changed, 40 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7523719..36d3390 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -88,6 +88,7 @@ enum xen_irq_type {
> struct irq_info
> {
> struct list_head list;
> + atomic_t refcount;
refcnt
> enum xen_irq_type type; /* type */
> unsigned irq;
> unsigned short evtchn; /* event channel */
> @@ -407,6 +408,7 @@ static void xen_irq_init(unsigned irq)
> panic("Unable to allocate metadata for IRQ%d\n", irq);
>
> info->type = IRQT_UNBOUND;
> + atomic_set(&info->refcount, 1);
>
> irq_set_handler_data(irq, info);
>
> @@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq)
>
> irq_set_handler_data(irq, NULL);
>
> + BUG_ON(atomic_read(&info->refcount) > 1);
> +
> kfree(info);
>
> /* Legacy IRQ descriptors are managed by the arch. */
> @@ -912,6 +916,10 @@ static void unbind_from_irq(unsigned int irq)
> {
> struct evtchn_close close;
> int evtchn = evtchn_from_irq(irq);
> + struct irq_info *info = irq_get_handler_data(irq);
> +
> + if (!atomic_dec_and_test(&info->refcount))
> + return;
>
> mutex_lock(&irq_mapping_update_lock);
>
> @@ -1038,6 +1046,32 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id)
> }
> EXPORT_SYMBOL_GPL(unbind_from_irqhandler);
>
> +int evtchn_get(unsigned int evtchn)
> +{
> + int irq = evtchn_to_irq[evtchn];
> + struct irq_info *info;
> +
> + if (irq == -1)
> + return -ENOENT;
> +
> + info = irq_get_handler_data(irq);
> +
> + if (!info)
> + return -ENOENT;
> +
> + atomic_inc(&info->refcount);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(evtchn_get);
> +
> +void evtchn_put(unsigned int evtchn)
The decleration for 'evtchn' is 'unsigned short' so that can be
used instead of 'unsigned int'.
> +{
> + int irq = evtchn_to_irq[evtchn];
Not checking if the irq is valid? Or if the evtchn is valid?
> + unbind_from_irq(irq);
> +}
> +EXPORT_SYMBOL_GPL(evtchn_put);
> +
> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
> {
> int irq = per_cpu(ipi_to_irq, cpu)[vector];
> diff --git a/include/xen/events.h b/include/xen/events.h
> index d287997..a459cca 100644
> --- a/include/xen/events.h
> +++ b/include/xen/events.h
> @@ -37,6 +37,12 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
> */
> void unbind_from_irqhandler(unsigned int irq, void *dev_id);
>
> +/*
> + * Allow extra references to event channels exposed to userspace by evtchn
> + */
> +int evtchn_get(unsigned int evtchn);
> +void evtchn_put(unsigned int evtchn);
> +
> void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector);
> int resend_irq_on_evtchn(unsigned int irq);
> void rebind_evtchn_irq(int evtchn, int irq);
> --
> 1.7.6.4
next prev parent reply other threads:[~2011-10-24 20:22 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 [this message]
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 ` [PATCH 2/2] xen/gnt{dev, alloc}: " Konrad Rzeszutek Wilk
2011-10-24 22:01 ` 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=20111024202242.GD2441@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.