netdev - Re: b44: regression in 2.6.22 (resend)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 May 2007 14:05:41 -0700
From:	"Gary Zambrano" <zambrano@...adcom.com>
To:	"Michael Buesch" <mb@...sch.de>
cc:	"Maximilian Engelhardt" <maxi@...monizer.de>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"linux-wireless" <linux-wireless@...r.kernel.org>,
	"Stephen Hemminger" <shemminger@...ux-foundation.org>,
	"Arnaldo Carvalho de Melo" <acme@...stprotocols.net>,
	"Jeff Garzik" <jgarzik@...ox.com>, netdev@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: b44: regression in 2.6.22 (resend)

On Tue, 2007-05-29 at 22:45 +0200, Michael Buesch wrote:
> On Tuesday 29 May 2007 16:14:35 Gary Zambrano wrote:
> > On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
> > > On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
> > > > On Monday 28 May 2007, Michael Buesch wrote:
> > > > > Can you also test the following patch?
> > > > > I think there's a bug in b44 that is doesn't properly discard
> > > > > shared IRQs, so it might possibly generate a NAPI storm, dunno.
> > > > > Worth a try.
> > > > >
> > > > > Index: linux-2.6.22-rc3/drivers/net/b44.c
> > > > > ===================================================================
> > > > > --- linux-2.6.22-rc3.orig/drivers/net/b44.c	2007-05-27 23:01:44.000000000
> > > > > +0200 +++ linux-2.6.22-rc3/drivers/net/b44.c	2007-05-28 12:48:27.000000000
> > > > > +0200 @@ -911,6 +911,8 @@ static irqreturn_t b44_interrupt(int irq
> > > > >  	spin_lock(&bp->lock);
> > > > >
> > > > >  	istat = br32(bp, B44_ISTAT);
> > > > > +	if (istat == 0xFFFFFFFF)
> > > > > +		goto out; /* Shared IRQ not for us */
> > > > >  	imask = br32(bp, B44_IMASK);
> > > > >
> > > > >  	/* The interrupt mask register controls which interrupt bits
> > > > > @@ -942,6 +944,7 @@ irq_ack:
> > > > >  		bw32(bp, B44_ISTAT, istat);
> > > > >  		br32(bp, B44_ISTAT);
> > > > >  	}
> > > > > +out:
> > > > >  	spin_unlock(&bp->lock);
> > > > >  	return IRQ_RETVAL(handled);
> > > > >  }
> > > > 
> > > > I did try this patch on a affected kernel, but I didn't notice any big 
> > > > difference. Perhaps the kernel is a bit less slow during the test, but It's 
> > > > hard to tell.
> > > 
> > > Ok, but anyway. I think this is a bug and needs to be fixed this way. Gary?
> > > 
> > 
> > Thanks Michael.
> > No, I don't think this is a bug and it does not need to be fixed.
> 
> Are you sure? I'm not so sure, because
> 1) On bcm43xx the reverse engineers told us that the card
>    returns 0xFFFFFFFF for no-irq-pending. Since b44 and bcm43xx
>    are very similiar in IRQ and DMA I just thought it would
>    be the case there, too. Just guessing.
The b44 interrupt status reg returns a value of 0 if no interrupts are
pending. The b44 uses a mask to determine which bits (events) can
generate device interrupts on the system. If the masked interrupt status
register bits are not asserted, then the b44 will return to the system
with handled = 0. 
So, I think the way the b44 interrupt code is written should be ok and
not a bug. 


> 2) PCMCIA cards usually return all-ones if you try to read a
>    register of a card that's been removed. So it's good
>    practice to check for this and bail out early in the IRQ
>    path. Do PCMCIA cards (PC-card, not neccessarily a real
>    16bit PCMCIA card) for b44 exist?

I do not know of any pccard application of the b44. As far as I know
b44s live on motherboards and in the wireless soc.

Thanks,
Gary

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html