Mailing List Archive

> int xen_irq_from_pirq(unsigned pirq)
> {
> - return pirq_to_irq[pirq];
> + int irq;
> +
> + struct irq_info *info;
> +
> + spin_lock(&irq_mapping_update_lock);
> +
> + list_for_each_entry(info, &xen_irq_list_head, list) {
> + if (info == NULL || info->type != IRQT_PIRQ)
> + continue;
> + irq = info->irq;
> + if (info->u.pirq.pirq == pirq)
> + goto out;
> + }
> + irq = -1;
> +out:
> + spin_lock(&irq_mapping_update_lock);
> +
> + return -1;

Shouldn't this be:

return irq

?

How come you are using the spin_lock here, but not
in other places when iterating over the xen_irq_list_head?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2011-03-10 at 05:33 +0000, Konrad Rzeszutek Wilk wrote:
> > int xen_irq_from_pirq(unsigned pirq)
> > {
> > - return pirq_to_irq[pirq];
> > + int irq;
> > +
> > + struct irq_info *info;
> > +
> > + spin_lock(&irq_mapping_update_lock);
> > +
> > + list_for_each_entry(info, &xen_irq_list_head, list) {
> > + if (info == NULL || info->type != IRQT_PIRQ)
> > + continue;
> > + irq = info->irq;
> > + if (info->u.pirq.pirq == pirq)
> > + goto out;
> > + }
> > + irq = -1;
> > +out:
> > + spin_lock(&irq_mapping_update_lock);
> > +
> > + return -1;
>
> Shouldn't this be:
>
> return irq

Yes. The impact of not doing so is that xen_hvm_setup_msi_irqs would
allocate a fresh PIRQ each time an MSI was reused, instead of resuing
the old one -- i.e. it's a leak. I retested PVHVM PCI hotplug with the
following patch.

> How come you are using the spin_lock here, but not
> in other places when iterating over the xen_irq_list_head?

Those other places already hold the lock in their caller (or are known
to be single threaded -- e.g. resume). Callers of xen_irq_from_pirq do
not hold the lock.

Ian.

8<------------------------

>From 9b1686b874c4893a3b014e400185940dcba43676 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 10 Mar 2011 08:54:06 +0000
Subject: [PATCH] xen: events: fix return value from xen_irq_from_pirq

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
drivers/xen/events.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 77c2b43..dc5b575 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -765,7 +765,7 @@ int xen_irq_from_pirq(unsigned pirq)
out:
spin_lock(&irq_mapping_update_lock);

- return -1;
+ return irq;
}


--
1.5.6.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

There isn't really much relationship between the two, other than
nr_irqs often being the larger of the two.

Allows us to remove a nr_irqs sized array, the only users of this
array are MSI setup and restore, neither of which are particularly
performance critical.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
drivers/xen/events.c | 59 +++++++++++++++++++++----------------------------
1 files changed, 25 insertions(+), 34 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 002283e..6782251 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -107,8 +107,6 @@ struct irq_info
#define PIRQ_NEEDS_EOI (1 << 0)
#define PIRQ_SHAREABLE (1 << 1)

-static int *pirq_to_irq;
-
static int *evtchn_to_irq;

static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
@@ -196,8 +194,6 @@ static void xen_irq_info_pirq_init(unsigned irq,
info->u.pirq.gsi = gsi;
info->u.pirq.vector = vector;
info->u.pirq.flags = flags;
-
- pirq_to_irq[pirq] = irq;
}

/*
@@ -247,16 +243,6 @@ static unsigned pirq_from_irq(unsigned irq)
return info->u.pirq.pirq;
}

-static unsigned gsi_from_irq(unsigned irq)
-{
- struct irq_info *info = info_for_irq(irq);
-
- BUG_ON(info == NULL);
- BUG_ON(info->type != IRQT_PIRQ);
-
- return info->u.pirq.gsi;
-}
-
static enum xen_irq_type type_from_irq(unsigned irq)
{
return info_for_irq(irq)->type;
@@ -653,12 +639,6 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,

spin_lock(&irq_mapping_update_lock);

- if (pirq > nr_irqs) {
- printk(KERN_WARNING "xen_map_pirq_gsi: pirq %d > nr_irqs %d!\n",
- pirq, nr_irqs);
- goto out;
- }
-
irq = find_irq_by_gsi(gsi);
if (irq != -1) {
printk(KERN_INFO "xen_map_pirq_gsi: returning irq %d for gsi %u\n",
@@ -758,7 +738,6 @@ int xen_destroy_irq(int irq)
goto out;
}
}
- pirq_to_irq[info->u.pirq.pirq] = -1;

xen_free_irq(irq);

@@ -769,7 +748,24 @@ out:

int xen_irq_from_pirq(unsigned pirq)
{
- return pirq_to_irq[pirq];
+ int irq;
+
+ struct irq_info *info;
+
+ spin_lock(&irq_mapping_update_lock);
+
+ list_for_each_entry(info, &xen_irq_list_head, list) {
+ if (info == NULL || info->type != IRQT_PIRQ)
+ continue;
+ irq = info->irq;
+ if (info->u.pirq.pirq == pirq)
+ goto out;
+ }
+ irq = -1;
+out:
+ spin_lock(&irq_mapping_update_lock);
+
+ return irq;
}

int bind_evtchn_to_irq(unsigned int evtchn)
@@ -1269,15 +1265,18 @@ static void restore_pirqs(void)
{
int pirq, rc, irq, gsi;
struct physdev_map_pirq map_irq;
+ struct irq_info *info;

- for (pirq = 0; pirq < nr_irqs; pirq++) {
- irq = pirq_to_irq[pirq];
- if (irq == -1)
+ list_for_each_entry(info, &xen_irq_list_head, list) {
+ if (info->type != IRQT_PIRQ)
continue;

+ pirq = info->u.pirq.pirq;
+ gsi = info->u.pirq.gsi;
+ irq = info->irq;
+
/* save/restore of PT devices doesn't work, so at this point the
* only devices present are GSI based emulated devices */
- gsi = gsi_from_irq(irq);
if (!gsi)
continue;

@@ -1291,7 +1290,6 @@ static void restore_pirqs(void)
printk(KERN_WARNING "xen map irq failed gsi=%d irq=%d pirq=%d rc=%d\n",
gsi, irq, pirq, rc);
xen_free_irq(irq);
- pirq_to_irq[pirq] = -1;
continue;
}

@@ -1512,13 +1510,6 @@ void __init xen_init_IRQ(void)
{
int i;

- /* We are using nr_irqs as the maximum number of pirq available but
- * that number is actually chosen by Xen and we don't know exactly
- * what it is. Be careful choosing high pirq numbers. */
- pirq_to_irq = kcalloc(nr_irqs, sizeof(*pirq_to_irq), GFP_KERNEL);
- for (i = 0; i < nr_irqs; i++)
- pirq_to_irq[i] = -1;
-
evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
GFP_KERNEL);
for (i = 0; i < NR_EVENT_CHANNELS; i++)
--
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sun, Mar 13, 2011 at 12:31:52AM +0100, joy wrote:
> Hi,
>
> I figure lockdep is going to tell you the same, but I happened to
> notice it myself:
>
> http://xenbits.xen.org/gitweb/?p=people/ianc/linux-2.6.git;a=commitdiff;h=88d0448802e4720579e28ffc7e6db8652e378274
>
> @@ -769,7 +748,24 @@ out:
>
> int xen_irq_from_pirq(unsigned pirq)
> [...]
> + spin_lock(&irq_mapping_update_lock);
> [...]
> +out:
> + spin_lock(&irq_mapping_update_lock);
>
> The latter one looks like it should be an unlock.

I just noticed that it's been pulled into
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=69c358ce377e998e3ababb494c2f8769dfb1715d
and mentioned in
http://lists.xensource.com/archives/html/xen-devel/2011-03/msg00718.html
So I'm sending it to the list (with adjusted Subject and In-Reply-To)
just in case.

--
2. That which causes joy or happiness.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, 2011-03-12 at 23:41 +0000, Josip Rodin wrote:
> On Sun, Mar 13, 2011 at 12:31:52AM +0100, joy wrote:
> > Hi,
> >
> > I figure lockdep is going to tell you the same, but I happened to
> > notice it myself:
> >
> > http://xenbits.xen.org/gitweb/?p=people/ianc/linux-2.6.git;a=commitdiff;h=88d0448802e4720579e28ffc7e6db8652e378274
> >
> > @@ -769,7 +748,24 @@ out:
> >
> > int xen_irq_from_pirq(unsigned pirq)
> > [...]
> > + spin_lock(&irq_mapping_update_lock);
> > [...]
> > +out:
> > + spin_lock(&irq_mapping_update_lock);
> >
> > The latter one looks like it should be an unlock.
>
> I just noticed that it's been pulled into
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=69c358ce377e998e3ababb494c2f8769dfb1715d
> and mentioned in
> http://lists.xensource.com/archives/html/xen-devel/2011-03/msg00718.html
> So I'm sending it to the list (with adjusted Subject and In-Reply-To)
> just in case.

Thanks. I could've sworn I fixed this up once already but I guess I
managed to not include it in the final branch somehow.

8<-------------------------------------
>From cc02eff5c1ed405153a4fe146382ee0324ab8ce1 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 14 Mar 2011 09:50:01 +0000
Subject: [PATCH] xen: events: correct locking in xen_irq_from_pirq

One of those spin_lock() calls should be an unlock...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
drivers/xen/events.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 3566c00..dc81779 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -752,7 +752,7 @@ int xen_irq_from_pirq(unsigned pirq)
}
irq = -1;
out:
- spin_lock(&irq_mapping_update_lock);
+ spin_unlock(&irq_mapping_update_lock);

return irq;
}
--
1.5.6.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel