[openib-general] [PATCH v2 1/7] IB/core - Add DMA mappingfunctions to allow device drivers to interpose
Or Gerlitz
ogerlitz at voltaire.com
Tue Dec 5 02:31:46 PST 2006
Ralph Campbell wrote:
> I appreciate your pointing out the potential problems. I agree that
> future kernel changes could certainly break existing drivers. That
> happens frequently even when following the guarantees.
Assuming "an implementation detail that could change any time and that
you should not rely on" is too much to my taste, so its left for the IB
maintainer to decide if to push it and for the kernel maintainer if to
accept it.
While discussing it with the group here a was made that a possible
solution for this problem would be on top of the suggested change call
kmap_atomic/kunmap_atomic in the ipath low level code before/after you
memcpy to/from a page provided to you by the IB consumer. But i am not
sure if it solves the problem of ib_dma_map_sg for an sg provided later
to the FMR code.
> I still don't understand how a valid struct page * (regardless of
> whether it is mapped into user space or not) can not have a valid
> kernel address when CONFIG_HIGHMEM is not defined for the current
> source base. In include/linux/mm.h, page_address() is defined as
> lowmem_page_address() which is defined as
> __va(page_to_pfn(page) << PAGE_SHIFT)
> which can only fail if there isn't a valid PFN for the page.
> I don't see how that can happen.
Looking on the matter again, I agree it can not fail for low memory with
nowadays kernel code.
Or.
More information about the general
mailing list