[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1208540735.16633.102.camel@dell>
Date: Fri, 18 Apr 2008 10:45:35 -0700
From: "Michael Chan" <mchan@...adcom.com>
To: "David Miller" <davem@...emloft.net>
cc: mcarlson@...adcom.com, netdev <netdev@...r.kernel.org>,
andy@...yhouse.net, tonyb@...ernetics.com
Subject: Re: [PATCH 1/2] tg3: 5701 DMA corruption fix
On Thu, 2008-04-17 at 23:26 -0700, David Miller wrote:
> From: "Matt Carlson" <mcarlson@...adcom.com>
> Date: Wed, 16 Apr 2008 15:27:41 -0700
>
> > + while (pci_id->vendor != 0) {
> > + bridge = pci_get_device(pci_id->vendor,
> > + pci_id->device,
> > + bridge);
> > + if (!bridge) {
> > + pci_id++;
> > + continue;
> > + }
> > + if (bridge->subordinate &&
> > + (bridge->subordinate->number <=
> > + tp->pdev->bus->number) &&
> > + (bridge->subordinate->subordinate >=
> > + tp->pdev->bus->number)) {
> > + tp->tg3_flags3 |= TG3_FLG3_5701_DMA_BUG;
> > + pci_dev_put(bridge);
> > + break;
> > + }
> > + }
> > + }
>
> This code block will leak bridge device objects when the table
> comparison check fails.
Do you mean having undecremented reference count on the bridge when it
doesn't match?
I think it is ok, because when we call pci_get_device() next time, we'll
pass in the old bridge so that it can find the next one. pci_get_device
() will automatically decrement the reference count on the old bridge.
>
> Probably the best thing to do is seperate the boolean check
> from the other operations:
>
> bool match = false;
> ...
> if (bridge->subordinate &&
> (bridge->subordinate->number <=
> tp->pdev->bus->number) &&
> (bridge->subordinate->subordinate >=
> tp->pdev->bus->number))
> match = true;
>
> pci_dev_put_bridge(bridge);
>
> if (match) {
> tp->tg3_flags |= TG3_FLG3_5701_DMA_BUG;
> pci_dev_put(bridge);
> }
>
> Please fix this up, and combine the version bump into this patch.
>
> Thank you!
>
--
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
Powered by blists - more mailing lists