[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