Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
