[ofiwg] [libfabric-users] mmap'ed kernel memory in fi_mr_reg

Jörn Schumacher joern.schumacher at cern.ch
Sat Nov 17 14:22:27 PST 2018


On 11/16/18 5:35 PM, Hefty, Sean wrote:
>> I am happy with this being a provider-specific extension for now. The
>> project that requires this will anyway only use the verbs provider.
>>
>> I do not think there is a fully reliable way of distinguishing
>> physical/virtual addresses. I spoke with our driver expert here who
>> cannot think of a way either. The provider-specific flag seems to be
>> the way to go, what do you think?
> 
> I agree this works fine.
> 
> The only alternative I can think of is to try a normal registration call, and if that fails, try again using the physical flag.  Would this work, or does the normal registration call succeed, but produce an unusable MR?

This would not work because of a subtlety of the physical memory 
registration. The reason is that actually NULL is passed as address in 
the call. Check the github link to my patch in the other E-Mail, there 
is a line that replaces the address with NULL.

If a user passes an illegal virtual address the call should fail. But if 
the libfabric call falls back to the physical address registration, this 
would then actually succeed as the address is replaced with NULL.

Cheers,
Jörn


More information about the ofiwg mailing list