The intent of this function is to get the cpt nearest to the
memory described by the MD.
There are three scenarios that must be handled:
1. The memory is described by an lnet_kiov_t structure
-> this describes kernel pages
2. The memory is described by a struct kvec
-> this describes kernel logical addresses
3. The memory is a contiguous buffer allocated via vmalloc
For case 1 and 2 we look at the first vector which contains
the data to be DMAed, taking into consideration the msg offset.
For case 2 we have to take the extra step of translating the kernel
logical address to a physical page using virt_to_page() macro.
For case 3 we need to use is_vmalloc_addr() and vmalloc_to_page to
get the associated page to be able to identify the CPT.
o2iblnd uses the same strategy when it's mapping the memory into
a scatter/gather list. Therefore, lnet_kvaddr_to_page() common
function was created to be used by both the o2iblnd and
lnet_cpt_of_md()
kmap_to_page() performs the high memory check which
lnet_kvaddr_to_page() does. However, unlike the latter it handles
the highmem case properly instead of calling LBUG. It's not
100% clear why the code was written that way. Since the legacy
code will need to still be maintained, adding kmap_to_page() will
not simplify the code. Furthermore, the behavior for kernels
which export kmap_to_page() will be different from kernels which
do not. At worst calling kmap_to_page() might mask some problems
which would've been caught by the LBUG earlier on. However, at
the time of this fix, that LBUG has never been observed.
Lustre-change: https://review.whamcloud.com/28165
Lustre-commit:
43b0e6328b113d9ee64e0b8a0cc35bff28eb3383
Signed-off-by: Amir Shehata <amir.shehata@intel.com>
Change-Id: I2c67e5df77d60112bf27f900e0325d189f193aed
Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: Sonia Sharma <sonia.sharma@intel.com>
Reviewed-by: Olaf Weber <olaf.weber@hpe.com>
Signed-off-by: Minh Diep <minh.diep@intel.com>
Reviewed-on: https://review.whamcloud.com/28400
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>