lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 20 Nov 2010 01:19:31 +0000
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@...rix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [PATCH] xen: use PHYSDEVOP_get_free_pirq to implement
 find_unbound_pirq

On Fri, 19 Nov 2010, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 19, 2010 at 01:58:03PM +0000, Stefano Stabellini wrote:
> > Use PHYSDEVOP_get_free_pirq to implement find_unbound_pirq
> > 
> > Use the new hypercall PHYSDEVOP_get_free_pirq to ask Xen to allocate a
> > pirq. Remove the unsupported PHYSDEVOP_get_nr_pirqs hypercall to get the
> > amount of pirq available.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@...citrix.com>
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 321a0c8..ffd286e 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -382,12 +382,17 @@ static int get_nr_hw_irqs(void)
> >  	return ret;
> >  }
> >  
> > -/* callers of this function should make sure that PHYSDEVOP_get_nr_pirqs
> > - * succeeded otherwise nr_pirqs won't hold the right value */
> > -static int find_unbound_pirq(void)
> > +static int find_unbound_pirq(int type)
> >  {
> > -	int i;
> > -	for (i = nr_pirqs-1; i >= 0; i--) {
> > +	int rc, i;
> > +	struct physdev_get_free_pirq op_get_free_pirq;
> > +	op_get_free_pirq.type = type;
> > +
> > +	rc = HYPERVISOR_physdev_op(PHYSDEVOP_get_free_pirq, &op_get_free_pirq);
> > +	if (!rc)
> > +		return op_get_free_pirq.pirq;
> > +
> > +	for (i = 16; i <= nr_pirqs-1; i++) {
> 
> 16? No no. Why not re-use the old loop, like so:
> 
>  	for (i = nr_pirqs-1; i >= 0; i--) {
> 

Because we don't know the real nr_pirqs anymore (PHYSDEVOP_get_nr_pirqs
has been removed), so it is highly possible that starting from the top
down would give us pirq numbers out of range in Xen.  Therefore we need
to start from the bottom up, and the bottom for Xen is 16.


> >  		if (pirq_to_irq[i] < 0)
> >  			return i;
> >  	}
> > @@ -669,7 +674,7 @@ void xen_allocate_pirq_msi(char *name, int *irq, int *pirq)
> >  	if (*irq == -1)
> >  		goto out;
> >  
> > -	*pirq = find_unbound_pirq();
> > +	*pirq = find_unbound_pirq(MAP_PIRQ_TYPE_MSI);
> >  	if (*pirq == -1)
> >  		goto out;
> >  
> > @@ -1504,23 +1509,12 @@ void xen_callback_vector(void) {}
> >  void __init xen_init_IRQ(void)
> >  {
> >  	int i, rc;
> > -	struct physdev_nr_pirqs op_nr_pirqs;
> >  
> >  	cpu_evtchn_mask_p = kcalloc(nr_cpu_ids, sizeof(struct cpu_evtchn_s),
> >  				    GFP_KERNEL);
> >  	irq_info = kcalloc(nr_irqs, sizeof(*irq_info), GFP_KERNEL);
> >  
> > -	rc = HYPERVISOR_physdev_op(PHYSDEVOP_get_nr_pirqs, &op_nr_pirqs);
> > -	if (rc < 0) {
> > -		nr_pirqs = nr_irqs;
> > -		if (rc != -ENOSYS)
> > -			printk(KERN_WARNING "PHYSDEVOP_get_nr_pirqs returned rc=%d\n", rc);
> > -	} else {
> > -		if (xen_pv_domain() && !xen_initial_domain())
> > -			nr_pirqs = max((int)op_nr_pirqs.nr_pirqs, nr_irqs);
> > -		else
> > -			nr_pirqs = op_nr_pirqs.nr_pirqs;
> > -	}
> > +	nr_pirqs = nr_irqs;
> 
> Why not just get rid of nr_pirgs altogether then? And use 'nr_irqs' instead?
> 

Yeah, I guess we could do that. I kept it around just to make it more
obvious that the max pirq number is different from nr_irqs and we don't
know what the exact value is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ