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]
Message-Id: <200901161222.56272.jesse.barnes@intel.com>
Date:	Fri, 16 Jan 2009 12:22:55 -0800
From:	Jesse Barnes <jesse.barnes@...el.com>
To:	Len Brown <lenb@...nel.org>
Cc:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	linux-acpi@...r.kernel.org,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, shaohua.li@...el.com
Subject: Re: ACPI hotplug panic with current git head

On Friday, January 16, 2009 12:08 pm Len Brown wrote:
> > > It looks like acpi_pci_get_bridge_handle() is returning NULL, so this
> > > is the fix that works for me.
> >
> > I'm sorry for troubling you, and thank you for your patience.
> >
> > The patch seems to avoid the kernel panic, but I still don't know
> > why acpi_pci_get_bridge_handle() returns NULL here. I assumed
> > it should return non-NULL value here. So I'd like to investigate
> > it more.
>
> Kenji,
> I'd like to push jejb's 1-liner upstream now.
> It make sense, and it prevents a boot panic regression
> that I'd rather not have others experience in rc2.
>
> I agree that it is important to hotplug for you to figure out
> why this machine runs down that path in the first place,
> and I'm sure that James will continue to work with you
> on that after the 1-liner is in.
>
> thanks
> Len Brown, Intel Open Source Technology Center
>
> > > diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> > > b/drivers/pci/hotplug/acpiphp_glue.c index f09b101..803d9dd 100644
> > > --- a/drivers/pci/hotplug/acpiphp_glue.c
> > > +++ b/drivers/pci/hotplug/acpiphp_glue.c
> > > @@ -266,6 +266,8 @@ static int detect_ejectable_slots(struct pci_bus
> > > *pbus) int found = acpi_pci_detect_ejectable(pbus);
> > >  	if (!found) {
> > >  		acpi_handle bridge_handle = acpi_pci_get_bridge_handle(pbus);
> > > +		if (!bridge_handle)
> > > +			return 0;
> > >  		acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge_handle, (u32)1,
> > >  				    is_pci_dock_device, (void *)&found, NULL);
> > >  	}


Agreed.  It's funky that we're getting back a NULL here, but we definitely 
don't want people's machines to crash while we figure out what's going 
wrong...

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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