[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4E8590CD0200007800058ABA@nat28.tlf.novell.com>
Date: Fri, 30 Sep 2011 08:50:05 +0100
From: "Jan Beulich" <JBeulich@...e.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
<linux-kernel@...r.kernel.org>
Cc: "Dan Carpenter" <error27@...il.com>,
<xen-devel@...ts.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/9] xen/pciback: Check if the device
is found instead of blindly assuming so.
>>> On 29.09.11 at 21:52, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> Just in case it is not found, don't try to dereference it.
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> ---
> drivers/xen/xen-pciback/pci_stub.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index d985b65..55086e9 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -222,6 +222,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
> }
>
> spin_unlock_irqrestore(&pcistub_devices_lock, flags);
> + if (!found_psdev)
> + return;
If this happens, it's a bug (backend controller found the device, but
the generic backend code didn't), so I would say minimally a WARN_ON()
should be issued here.
Jan
>
> /*hold this lock for avoiding breaking link between
> * pcistub and xen_pcibk when AER is in processing
--
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