On Fri, 12 Sep 2014, Dave Hansen wrote: > On 09/12/2014 01:11 AM, Thomas Gleixner wrote: > > So what you are saying is, that if user space sets the pointer to NULL > > via the unregister prctl, kernel can safely ignore vmas which have the > > VM_MPX flag set. I really can't follow that logic. > > > > mmap_mpx(); > > prctl(enable mpx); > > do lots of crap which uses mpx; > > prctl(disable mpx); > > > > So after that point the previous use of MPX is irrelevant, just > > because we set a pointer to NULL? Does it just look like crap because > > I do not get the big picture how all of this is supposed to work? > > The prctl(register) is meant to be a signal from userspace to the kernel > to say, "I would like your help in managing these bounds tables". > prctl(unregister) is the opposite, meaning "I don't want your help any > more". Fine, but that's a totally different story. I can see the usefulness of this, but then it's a complete misnomer. It should be: prctl(EN/DISABLE_MPX_BT_MANAGEMENT) So this wants to be a boolean value and not some random user space address collected at some random point and then ignored until you do the magic cleanup. See the other reply. > If userspace uses MPX, it does not necessarily want the kernel to do > bounds table management all the time (or ever in some cases). Without > the prctl(), the kernel has no way of distinguishing what userspace wants. Fine with me, but it needs to be done proper. And proper means: ON/OFF The kernel has to handle the information for which context it allocated stuff and then tear it down when the context goes away. Relying on a user space address sampled at some random prctl point is just stupid. > > And then you need another bunch of logic in the prctl(disable mpx) > > path to cleanup the mess instead of just setting a random pointer to > > NULL. > > The bounds tables potentially represent a *lot* of state. If userspace > wants to temporarily turn off the kernel's MPX bounds table management, > it does not necessarily want that state destroyed. On the other hand, > if userspace feels the need to go destroying all the state, it is free > to do so and does not need any help to do so from the kernel. Fine with me, but the above still stands. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>