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>
d522af581c