On Wed, Jun 23, 2010 at 04:04:10PM +0900, Kenji Kaneshige wrote:
> I encountered the problem that /proc/bus/pci/XX/YY is not removed even
> after the corresponding device is hot-removed, if the file is still
> being opened. In addtion, accessing this file in this situation causes
> kernel panic (see below).
>
> Becasue the pci_proc_detach_device() doesn't call remove_proc_entry()
> if struct proc_dir_entry->count > 1, access to /proc/bus/pci/XX/YY
> would refer to struct pci_dev that was already freed.
>
> Though I don't know why the check for proc_dir_entry->count was added,
> I don't think it is needed. Removing this check fixes the problem.
>
> Steps to reproduce
> ------------------
> # cd /sys/bus/pci/slots/2/
> # PROC_BUS_PCI_FILE=/proc/bus/pci/`awk -F: '{print $2"/"$3}' < address`.0
> # sleep 10000 < $PROC_BUS_PCI_FILE &
> # echo 0 > power
> # while true; do cat $PROC_BUS_PCI_FILE > /dev/null; done
Those last 2 lines only work as root, right?
> Oops Messages
> -------------
> BUG: unable to handle kernel NULL pointer dereference at 00000042
> IP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0
> *pdpt = 000000002185e001 *pde = 0000000476a79067
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:1c.0/0000:10:00.0/local_cpus
> Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq ipv6 dm_mirror dm_region_hash dm_log dm_mod e1000e i2c_i801 i2c_core iTCO_wdt igb sg pcspkr dca iTCO_vendor_support ext4 mbcache jbd2 sd_mod crc_t10dif lpfc mptsas scsi_transport_fc mptscsih mptbase scsi_tgt scsi_transport_sas [last unloaded: microcode]
>
> Pid: 2997, comm: cat Not tainted 2.6.34-kk #32 SB/PRIMEQUEST 1800E
> EIP: 0060:[<c05c82d5>] EFLAGS: 00010046 CPU: 19
> EIP is at pci_user_read_config_dword+0x65/0xa0
> EAX: 00000002 EBX: e44f1800 ECX: e144df14 EDX: 155668c7
> ESI: 00000087 EDI: 00000000 EBP: e144df40 ESP: e144df0c
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Process cat (pid: 2997, ti=e144c000 task=e26f2570 task.ti=e144c000)
> Stack:
> c09ceac0 c0570f72 ffffffff 08c57000 00000000 00001000 e44f1800 c05d2404
> <0> e144df40 00001000 00000000 00001000 08c57000 3093ae50 e420cb40 e358d5c0
> <0> c05d2300 fffffffb c054984f e144df9c 00008000 08c57000 e358d5c0 00008000
> Call Trace:
> [<c0570f72>] ? security_capable+0x22/0x30
> [<c05d2404>] ? proc_bus_pci_read+0x104/0x220
> [<c05d2300>] ? proc_bus_pci_read+0x0/0x220
> [<c054984f>] ? proc_reg_read+0x5f/0x90
> [<c05497f0>] ? proc_reg_read+0x0/0x90
> [<c050694d>] ? vfs_read+0x9d/0x190
> [<c04958f4>] ? audit_syscall_entry+0x204/0x230
> [<c0506a81>] ? sys_read+0x41/0x70
> [<c0402f1f>] ? sysenter_do_call+0x12/0x28
> Code: b4 26 00 00 00 00 b8 20 88 b1 c0 c7 44 24 08 ff ff ff ff e8 3e 52 22 00 f6 83 24 04 00 00 20 75 34 8b 43 08 8d 4c 24 08 8b 53 1c <8b> 70 40 89 4c 24 04 89 f9 c7 04 24 04 00 00 00 ff 16 89 c6 f0
> EIP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0 SS:ESP 0068:e144df0c
> CR2: 0000000000000042
>
> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@xxxxxxxxxxxxxx>
>
> ---
> drivers/pci/proc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> Index: linux-2.6.34/drivers/pci/proc.c
> ===================================================================
> --- linux-2.6.34.orig/drivers/pci/proc.c
> +++ linux-2.6.34/drivers/pci/proc.c
> @@ -431,8 +431,6 @@ int pci_proc_detach_device(struct pci_de
> struct proc_dir_entry *e;
>
> if ((e = dev->procent)) {
> - if (atomic_read(&e->count) > 1)
> - return -EBUSY;
> remove_proc_entry(e->name, dev->bus->procdir);
> dev->procent = NULL;
> }
This looks good to me, it's been there for forever :)
Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
