summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorSuresh Siddha <suresh.b.siddha@intel.com>2008-10-21 00:57:02 +0400
committerMauro Carvalho Chehab <mchehab@redhat.com>2008-11-11 13:11:21 +0300
commitd522af581c6abd0e064278345ca638b0553a93fa (patch)
tree4474cc407617de5e6350e9f982121c7bddc44501 /drivers
parent74084d33cb6221a5836a2a4438ec1bcf7a0797b0 (diff)
downloadlinux-d522af581c6abd0e064278345ca638b0553a93fa.tar.xz
V4L/DVB (9356): [PATCH] saa7134: fix resource map sanity check conflict
Impact: driver could possibly stomp on resources outside of its scope {mchehab@redhat.com: I got two versions of the same patch (identical, except for whitespacing). One authored by Andy Burns and another authored by Suresh Siddha. Due to that, I'm applying the one that has less CodingStyle errors. I'm also adding both comments and the SOB's for both patches, since they are both interesting} Suresh Siddha commented: Alexey Fisher reported: > resource map sanity check conflict: 0xcfeff800 0xcff007ff 0xcfe00000 > 0xcfefffff PCI Bus 0000:01 BAR base is located in the middle of the 4K page and the hardcoded size argument makes the request span two pages causing the conflict. Fix the hard coded size argument in ioremap(). Andy Burns commented: I have already sent this patch on the linux-dvb list, but it didn't get much attention, so re-sending direct, I hope you all don't mind. While attempting to run mythtv in a xen domU, I encountered problems loading the driver for my saa7134 card, with an error from ioremap(). This error was due to the driver allocating an incorrectly sized mmio area, which was trapped by xen's permission checks, but this would go un-noticed on a kernel without xen. My card has a 1K sized mmio area, I've had information that other cards have 2K areas, perhaps others have different sizes, yet the driver always attempts to map 4K. I realise that the granularity of mapping is the page size, which typically would be 4K, but unless the card's base address happens to fall on a 4K boundary (mine does not) then the base+4K will end up spanning two pages, and this is when the error occurs under xen. My patch uses the pci_resource_len macro to determine the size required for the user's particular card, instead of the hardcoded 4K value. I've tested with a couple of printk() inside ioremap() that the start address and size do get rounded to the closest page boundary. With this patch I am able to successfully load the saa7134 driver and run mythtv under xen with my card, subject to correct pollirq settings in case of shared IRQ, I am still seeing occasional DMA panics, which I think are related to swiotlb handling by dom0/domU, usually the panic occurs when changing mux, once tuned to a mux, 12 hour continuous recordings are possible without errors. Reported-by: Alexey Fisher <bug-track@fisher-privat.net> Tested-by: Alexey Fisher <bug-track@fisher-privat.net> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Andy Burns <andy@burns.net> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/media/video/saa7134/saa7134-core.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/drivers/media/video/saa7134/saa7134-core.c b/drivers/media/video/saa7134/saa7134-core.c
index 249184452949..dfbe08a9ad9b 100644
--- a/drivers/media/video/saa7134/saa7134-core.c
+++ b/drivers/media/video/saa7134/saa7134-core.c
@@ -941,7 +941,8 @@ static int __devinit saa7134_initdev(struct pci_dev *pci_dev,
dev->name,(unsigned long long)pci_resource_start(pci_dev,0));
goto fail1;
}
- dev->lmmio = ioremap(pci_resource_start(pci_dev,0), 0x1000);
+ dev->lmmio = ioremap(pci_resource_start(pci_dev, 0),
+ pci_resource_len(pci_dev, 0));
dev->bmmio = (__u8 __iomem *)dev->lmmio;
if (NULL == dev->lmmio) {
err = -EIO;