> > You could use the stuff from patch 29 to effectively disable the uprobe > and return -ENOMEM to whoemever is unregistering. Basically failing the > unreg. > > That way you can leave the uprobe in existance and half installed but > functionally fully disabled. Userspace (assuming we go back that far) > can then either re-try the removal later, or even reinstate it by doing > a register again or so. > > Its still not pretty, but its better than pretending the unreg > completed. > This approach has its own disadvantages. perf record which does the unregister_uprobe() might be get stuck under low memory conditions while it tries to complete unregistration. Also the user would be confused if the tracer is still collecting information, once the unregister_uprobe has returned an error. So I would still think using a kworker thread to complete unregistration on a low memory condition might be a better solution. While I work on getting the kworker thread implementation ready, we could use delay deleting the probe, set the not_run_handler flag and also see if we can remove the breakpoint while the breakpoint is hit. This way the only worse thing that can happen is the probed processes still take a hit. If the kworker thread were to face a low memory situation, then it will try to schedule another kworker thread or itself again (at a later point in time). I still need to investigate some more on this. -- Thanks and Regards Srikar -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>