Re: [PATCH] UserfaultFD: Rename uffd_api.bits into .features

[Pavel Emelyanov <xemul@parallels.com>]

On 05/07/2015 06:11 PM, Andrea Arcangeli wrote:
> On Thu, May 07, 2015 at 05:42:08PM +0300, Pavel Emelyanov wrote:
>> On 05/07/2015 05:33 PM, Andrea Arcangeli wrote:
>>> On Thu, May 07, 2015 at 05:28:46PM +0300, Pavel Emelyanov wrote:
>>>> Yup, this is very close to what I did in my set -- introduced a message to
>>>> report back to the user-space on read. But my message is more than 8+2*1 bytes,
>>>> so we'll have one message for 0xAA API and another one for 0xAB (new) one :)
>>>
>>> I slightly altered it to fix an issue with packet alignments so it'd
>>> be 16bytes.
>>>
>>> How big is your msg currently? Could we get to use the same API?
>>
>> Right now it's like this
>>
>> struct uffd_event {
>>         __u64 type;
>>         union {
>>                 struct {
>>                         __u64 addr;
>>                 } pagefault;
>>
>>                 struct {
>>                         __u32 ufd;
>>                 } fork;
>>
>>                 struct {
>>                         __u64 from;
>>                         __u64 to;
>>                         __u64 len;
>>                 } remap;
>>         } arg;
>> };
>>
>> where .type is your uffd_msg.event and the rest is event-specific.
> 
> So you have two more __u64.
> 
> In theory if msg.event == UFFD_EVENT_MREMAP you could have the "from"
> encoded in the msg.arg and then userland could read 16 more bytes
> knowing it'll get "to len" and we won't have to alter the UFFD_API for
> adding new EVENT that requires bigger msg size. But it's probably not
> worth it as an enter/exit kernel is way more costly than reading
> 16 more bytes, if we already know we need 32bytes in the end.
> 
> MADV_DONTNEED shouldn't need more bytes than mremap either.

Yes, this one only needs an address and length.

> I think it's ok if I enlarge it to 32bytes.

Cool, then we don't need the 2nd API for that :) At least for now.

>>
>>> UFFDIO_REGISTER_MODE_FORK
>>>
>>> or 
>>>
>>> UFFDIO_REGISTER_MODE_NON_COOPERATIVE would differentiate if you want
>>> to register for fork/mremap/dontneed events as well or only the
>>> default (UFFD_EVENT_PAGEFAULT).
>>
>> I planned to use this in UFFDIO_API call -- the uffdio_api.features will
>> be in-out argument denoting the bits user needs and reporting what kernel
>> can.
> 
> Ok I guess in-out and checking api.features is easier than checking
> the vma during the fault. That's ok for me, plus if needed the
> registration flag can still be added later in addition of the in-out
> api.features.
> 
> So I also need to error out the UFFDIO_API call if api.features is not
> zero, ok?

Exactly!

> After those two changes you should be ok with the same API?

Yes. Longer message (type + 3 u64-s) and the ability to request for extra
events is all I need. If you're OK with this being in the 0xAA API, then
let's do it. I'll rebase my patches again once this appears in your repo :)

> We may still need a new API later of course, it's hard to predict the
> future and all possible future usages of the userfaultfd... but
> perhaps this will be enough...

-- Pavel

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>