After upgrade from 2.6.32-gentoo-r7 to 2.6.35-gentoo-r5 the following message show up in syslog when we run lsiutil for monitoring RAID status: The tool seems to work as usual. We have 2 LSI MPT-Fusion Adapters in the system. Sep 2 11:44:49 hostname kernel :: [ 4864.010853] WARNING: at drivers/pci/pci-sysfs.c:718 pci_mmap_fits+0xbe/0xc7() Sep 2 11:44:49 hostname kernel :: [ 4864.010853] WARNING: at drivers/pci/pci-sysfs.c:718 pci_mmap_fits+0xbe/0xc7() Sep 2 11:44:49 hostname kernel :: [ 4864.010856] Hardware name: PowerEdge R310 Sep 2 11:44:49 hostname kernel :: [ 4864.010856] Hardware name: PowerEdge R310 Sep 2 11:44:49 hostname kernel :: [ 4864.010860] process "lsiutil" tried to map 0x000df4f0-0x000df500 on 0000:03:00.0 BAR 0 (size 0x00000001) Sep 2 11:44:49 hostname kernel :: [ 4864.010860] process "lsiutil" tried to map 0x000df4f0-0x000df500 on 0000:03:00.0 BAR 0 (size 0x00000001) Sep 2 11:44:49 hostname kernel :: [ 4864.010863] Modules linked in: processor [last unloaded: usbhid] Sep 2 11:44:49 hostname kernel :: [ 4864.010863] Modules linked in: processor [last unloaded: usbhid] Sep 2 11:44:49 hostname kernel :: [ 4864.010870] Pid: 30735, comm: lsiutil Tainted: G W 2.6.35-gentoo-r5 #1 Sep 2 11:44:49 hostname kernel :: [ 4864.010870] Pid: 30735, comm: lsiutil Tainted: G W 2.6.35-gentoo-r5 #1 Sep 2 11:44:49 hostname kernel :: [ 4864.010872] Call Trace: Sep 2 11:44:49 hostname kernel :: [ 4864.010872] Call Trace: Sep 2 11:44:49 hostname kernel :: [ 4864.010877] [<ffffffff811fc292>] ? pci_mmap_fits+0xbe/0xc7 Sep 2 11:44:49 hostname kernel :: [ 4864.010877] [<ffffffff811fc292>] ? pci_mmap_fits+0xbe/0xc7 Sep 2 11:44:49 hostname kernel :: [ 4864.010882] [<ffffffff811fc292>] ? pci_mmap_fits+0xbe/0xc7 Sep 2 11:44:49 hostname kernel :: [ 4864.010882] [<ffffffff811fc292>] ? pci_mmap_fits+0xbe/0xc7 Sep 2 11:44:49 hostname kernel :: [ 4864.010887] [<ffffffff81037cbe>] ? warn_slowpath_common+0x78/0xa2 Sep 2 11:44:49 hostname kernel :: [ 4864.010887] [<ffffffff81037cbe>] ? warn_slowpath_common+0x78/0xa2 Sep 2 11:44:49 hostname kernel :: [ 4864.010891] [<ffffffff81037da7>] ? warn_slowpath_fmt+0x56/0x5e Sep 2 11:44:49 hostname kernel :: [ 4864.010891] [<ffffffff81037da7>] ? warn_slowpath_fmt+0x56/0x5e Sep 2 11:44:49 hostname kernel :: [ 4864.010897] [<ffffffff811fc292>] ? pci_mmap_fits+0xbe/0xc7 Sep 2 11:44:49 hostname kernel :: [ 4864.010897] [<ffffffff811fc292>] ? pci_mmap_fits+0xbe/0xc7 Sep 2 11:44:49 hostname kernel :: [ 4864.010903] [<ffffffff811fd60f>] ? proc_bus_pci_mmap+0x44/0x79 Sep 2 11:44:49 hostname kernel :: [ 4864.010903] [<ffffffff811fd60f>] ? proc_bus_pci_mmap+0x44/0x79 Sep 2 11:44:49 hostname kernel :: [ 4864.010908] [<ffffffff8111559c>] ? proc_reg_mmap+0x59/0x6e Sep 2 11:44:49 hostname kernel :: [ 4864.010908] [<ffffffff8111559c>] ? proc_reg_mmap+0x59/0x6e Sep 2 11:44:49 hostname kernel :: [ 4864.010913] [<ffffffff810b4304>] ? mmap_region+0x2eb/0x4ea Sep 2 11:44:49 hostname kernel :: [ 4864.010913] [<ffffffff810b4304>] ? mmap_region+0x2eb/0x4ea Sep 2 11:44:49 hostname kernel :: [ 4864.010918] [<ffffffff810b21ed>] ? get_unmapped_area+0xd7/0x139 Sep 2 11:44:49 hostname kernel :: [ 4864.010918] [<ffffffff810b21ed>] ? get_unmapped_area+0xd7/0x139 Sep 2 11:44:49 hostname kernel :: [ 4864.010923] [<ffffffff810b48f4>] ? sys_mmap_pgoff+0xf4/0x126 Sep 2 11:44:49 hostname kernel :: [ 4864.010923] [<ffffffff810b48f4>] ? sys_mmap_pgoff+0xf4/0x126 Sep 2 11:44:49 hostname kernel :: [ 4864.010928] [<ffffffff810dcc71>] ? sys_ioctl+0x3d/0x5c Sep 2 11:44:49 hostname kernel :: [ 4864.010928] [<ffffffff810dcc71>] ? sys_ioctl+0x3d/0x5c Sep 2 11:44:49 hostname kernel :: [ 4864.010933] [<ffffffff810028eb>] ? system_call_fastpath+0x16/0x1b Sep 2 11:44:49 hostname kernel :: [ 4864.010933] [<ffffffff810028eb>] ? system_call_fastpath+0x16/0x1b Sep 2 11:44:49 hostname kernel :: [ 4864.010936] ---[ end trace 09927e01d95394aa ]--- Reproducible: Always
*** Bug 335675 has been marked as a duplicate of this bug. ***
My colleague Martin Wilk has sent a patch set for this issue to kernel.org last week: The checks for valid mmaps of PCI resources made through /proc/bus/pci files that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several problems: 1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0, whereas under /sys/bus/pci/devices, the start of the resource corresponds to offset 0. This may lead to false negatives in pci_mmap_fits(), which implicitly assumes the /sys/bus/pci/devices layout. 2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads to false positives, because pci_mmap_fits() doesn't treat empty resources correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT) in this case!). 3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus WARNINGS for the first resources that don't fit until the correct one is found. On many controllers the first 2-4 BARs are used, and the others are empty. In this case, an mmap attempt will first fail on the non-empty BARs (including the "right" BAR because of 1.) and emit bogus WARNINGS because of 3., and finally succeed on the first empty BAR because of 2. This is certainly not the intended behaviour. The following patch addresses all 3 issues. Please review. Signed-off-by: Martin Wilck <Martin.Wilck@ts.fujitsu,com> --- a/drivers/pci/pci.h.orig 2010-09-01 06:57:20.000000000 +0200 +++ a/drivers/pci/pci.h 2010-10-20 18:44:22.000000000 +0200 @@ -14,7 +14,7 @@ extern void pci_remove_sysfs_dev_files(s extern void pci_cleanup_rom(struct pci_dev *dev); #ifdef HAVE_PCI_MMAP extern int pci_mmap_fits(struct pci_dev *pdev, int resno, - struct vm_area_struct *vma); + struct vm_area_struct *vmai, int is_proc); #endif int pci_probe_reset_function(struct pci_dev *dev); --- a/drivers/pci/proc.c.orig 2010-09-01 06:57:17.000000000 +0200 +++ a/drivers/pci/proc.c 2010-10-20 18:53:37.000000000 +0200 @@ -259,7 +259,7 @@ static int proc_bus_pci_mmap(struct file /* Make sure the caller is mapping a real resource for this device */ for (i = 0; i < PCI_ROM_RESOURCE; i++) { - if (pci_mmap_fits(dev, i, vma)) + if (pci_mmap_fits(dev, i, vma, 1)) break; } --- linux-2.6.32-71.el6.x86_64/drivers/pci/pci-sysfs.c 2010-09-01 06:57:17.000000000 +0200 +++ linux-2.6.32-71.el6.x86_64/drivers/pci/pci-sysfs.c.new 2010-10-21 01:34:58.000000000 +0200 @@ -675,17 +675,18 @@ void pci_remove_legacy_files(struct pci_ #ifdef HAVE_PCI_MMAP -int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma) +int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma, int is_proc) { - unsigned long nr, start, size; + unsigned long nr, start, size, pci_start; + if (pci_resource_len(pdev, resno) == 0) + return 0; nr = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; start = vma->vm_pgoff; size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1; - if (start < size && size - start >= nr) + pci_start = is_proc ? pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0; + if (start >= pci_start && start < pci_start + size && start + nr <= pci_start + size) return 1; - WARN(1, "process \"%s\" tried to map 0x%08lx-0x%08lx on %s BAR %d (size 0x%08lx)\n", - current->comm, start, start+nr, pci_name(pdev), resno, size); return 0; } @@ -715,8 +716,12 @@ pci_mmap_resource(struct kobject *kobj, if (i >= PCI_ROM_RESOURCE) return -ENODEV; - if (!pci_mmap_fits(pdev, i, vma)) + if (!pci_mmap_fits(pdev, i, vma, 0)) { + WARN(1, "process \"%s\" tried to map 0x%08lx bytes at page 0x%08lx on %s BAR %d (start 0x%16Lx, size 0x%16Lx)\n", + current->comm, vma->vm_end-vma->vm_start, vma->vm_pgoff, pci_name(pdev), i, + pci_resource_start(pdev, i), pci_resource_len(pdev, i)); return -EINVAL; + } /* pci_mmap_page_range() expects the same kind of entry as coming * from /proc/bus/pci/ which is a "user visible" value. If this is
Some days ago I upgraded the the problematic machine to kernel 2.6.37-r1 and the problem seems to be resolved. The messages can not be seen in syslog anymore :-)
