On Fri, Jan 10, 2020 at 02:10:22PM +0200, Andy Shevchenko wrote: > On Fri, Jan 10, 2020 at 1:54 PM P J P <ppandit@xxxxxxxxxx> wrote: > > > > Hello Andy, Navid > > > > -> https://git.kernel.org/linus/ea5ab2e422de0ef0fc476fe40f0829abe72684cd > > > > I was trying to understand this NULL dereference. IIUC, pci_ioremap_bar() > > returning NULL indicates insufficient memory OR if the pci device is > > configured to use I/O port address, instead of memory mapped region. > > > > I was wondering if(or how) it is reproducible for unprivileged user? Do you > > happen to have a reproducer for it? > > It's very unlikely to see IRL such problem. Theoretically it may > happen if the system in question has a LOT of devices connected to PCI > and suddenly there is no window for a resource left (usually 4k) under > PCI Root Bridge. Other than that I can't imagine what can go wrong. > Ah, of course the virtual space starvation is another possibility. pci_ioremap_bar() can return NULL if the BAR is an I/O port BAR or if it's a memory BAR but we haven't assigned space for it. It's a good idea to check the return value of pci_ioremap_bar(). ea5ab2e422de ("8250_lpss: check null return when calling pci_ioremap_bar") looks like a valid patch to add that check. My guess is that the patch was prompted by a static checker like Coverity, not by an observed problem. In any event, this code is in a quirk only used for Intel Quark SoC X1000 HS-UART devices. drivers/dma/dw/core.c (for the Synopsys DesignWare DMA Controller) *does* use that pointer via dma_readl(), but the references in the commit log (drivers/dma/dw/core.c:1154 and drivers/dma/dw/core.c:1168) are obsolete and not very useful. Bjorn
