From: Matthew Wilcox <matthew@wil.cx>
To: Alex Chiang <achiang@hp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
bjorn.helgaas@hp.com, kaneshige.kenji@jp.fujitsu.com,
linux-pci <linux-pci@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI Hotplug: acpiphp: don't store a pci_dev in acpiphp_func
Date: Fri, 22 May 2009 05:36:22 -0600 [thread overview]
Message-ID: <20090522113622.GA14692@parisc-linux.org> (raw)
In-Reply-To: <20090521222115.GC8792@ldl.fc.hp.com>
On Thu, May 21, 2009 at 04:21:15PM -0600, Alex Chiang wrote:
> In other words, if acpiphp has claimed a PCI device, and that
> device is logically removed, then acpiphp may oops when it
> attempts to access it again.
>
> # echo 1 > /sys/bus/pci/devices/$device/remove
> # echo 0 > /sys/bus/pci/slots/$slot/power
>
> The root cause of this oops is that the logical remove ("echo 1 >
> /sys/bus/pci/devices/$device/remove") destroyed the pci_dev. The
> pci_dev struct itself wasn't deallocated because acpiphp kept a
> reference, but some of its fields became invalid.
>
> acpiphp doesn't have any real reason to keep a pointer to a
> pci_dev around. It can always derive it using pci_get_slot().
>
> If a logical remove destroys the pci_dev, acpiphp won't find it
> and is thus prevented from causing mischief.
>
> Reported-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Signed-off-by: Alex Chiang <achiang@hp.com>
I think this is the right approach. The more minimal way to fix this
would be to check that the pdev was valid before destroying it ... but
I approve of deleting more code from acpiphp ;-) You do end up doing
slightly more work in the remove case, but this is such an infrequent
operation that it really doesn't matter.
Reviewed-by: Matthew Wilcox <willy@linux.intel.com>
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2009-05-22 11:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 22:21 [PATCH] PCI Hotplug: acpiphp: don't store a pci_dev in acpiphp_func Alex Chiang
2009-05-22 11:36 ` Matthew Wilcox [this message]
2009-05-25 23:55 ` Kenji Kaneshige
2009-05-27 9:05 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090522113622.GA14692@parisc-linux.org \
--to=matthew@wil.cx \
--cc=achiang@hp.com \
--cc=bjorn.helgaas@hp.com \
--cc=jbarnes@virtuousgeek.org \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.