linux-kernel - Re: [PATCH v7 3.2-rc2 3/30] uprobes: register/unregister probes.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 Dec 2011 19:11:36 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux-mm <linux-mm@...ck.org>, Ingo Molnar <mingo@...e.hu>,
	Andi Kleen <andi@...stfloor.org>,
	Christoph Hellwig <hch@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Roland McGrath <roland@...k.frob.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Anton Arapov <anton@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Stephen Wilson <wilsons@...rt.ca>
Subject: Re: [PATCH v7 3.2-rc2 3/30] uprobes: register/unregister probes.

> 
> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/