[openib-general] Re: [PATCH] fork support

[Michael S. Tsirkin]

Quoting r. Roland Dreier <rolandd at cisco.com>:
> Subject: Re: [PATCH] fork support
> 
> Thanks for doing this.  I'm actually at the Kernel Summit right now,
> so I'll see what lobbying I can do.

Thanks! Would it be easier, or harder, if I post this at lkml?

> Overall looks good, although I have a few comments:
> 
>  - This patch allows userspace to remove VM_DONTCOPY from vmas even if
>    the kernel set it.

Well, we'll need it to deregister stuff, wont we?

>    Right now, VM_DONTCOPY is not used except for a
>    couple of DRM drivers, so I'm not sure if this matters or not.

Right. I think its fine as it is - those drivers probably can switch
to using mprotect when its in.

>    If
>    it is a problem, I guess the answer is to create a VM_USERDONTCOPY
>    that works just like VM_DONTCOPY and have PROT_DONTCOPY affect that.


A somewhat bigger problem is that a legacy application that plays with
mprotect on registered buffers can accidentally remove VM_DONTCOPY just
by doing mprotect(PROT_WRITE|PROT_READ).
I toyed with an idea of yet another flag, say PROT_EXTENDED,
that says: dont ignore PROT_DONTCOPY.
So that

mprotect(PROT_WRITE|PROT_READ) doesnt touch VM_DONTCOPY
mprotect(PROT_EXTENDED) clears PROT_DONTCOPY
mprotect(PROT_EXTENDED|PROT_DONTCOPY) clears PROT_DONTCOPY

I went for simplicity. Do you think the above a good idea?

>  - I know this isn't your fault, but is it time to try and move all
>    the common PROT_XXX defines somewhere to avoid so much duplication?
> 
>  - R.
> 

Most of it is duplication, but some architectures define
PROT_ flags slightly differently. Easy to do ... let me know what do you
think.

-- 
MST