I didn't notice this before: > + * This is volatile as it's the target of a DMA from the chip. > + */ > + > +static volatile uint64_t ipath_port0_rcvhdrtail[512] > + __attribute__ ((aligned(4096)));
... and then much later ... > + /* > + * kernel modules loaded into vmalloc'ed memory, > + * verify that when we assume that, map to phys, and back to virt, > + * that we get the right contents, so we did the mapping right. > + */ > + vpage = vmalloc_to_page((void *)ipath_port0_rcvhdrtail); > + if (vpage == NOPAGE_SIGBUS || vpage == NOPAGE_OOM) { > + _IPATH_UNIT_ERROR(t, "vmalloc_to_page for rcvhdrtail fails!\n"); > + ret = -ENOMEM; > + goto done; > + } This seems very wrong to me: there's no guarantee that a module will be loaded into memory that can be used as a DMA target. For example, on a non-cache-coherent architecture, I think this memory must be accessed through a non-cached mapping. I think the correct solution is to allocate a buffer for each device with pci_alloc_consistent() (or maybe dma_alloc_coherent()). (As a general comment, I'm still unhappy about how your driver has a static, fixed-size table of devices rather than allocating per-device data structures dynamically) - R. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general