linux-kernel - Re: PATCH? trace_remove_event_call() should fail if call is active

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]

Message-ID: <51D38F8D.3010708@hitachi.com>
Date:	Wed, 03 Jul 2013 11:42:21 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: PATCH? trace_remove_event_call() should fail if call is active

(2013/07/03 7:23), Oleg Nesterov wrote:
> On 07/02, Oleg Nesterov wrote:
>>
>> So please ignore modules ;)
> 
> Or lets discuss the change above.

No, I think this still doesn't ensure that we can remove dynamic
event safely. Since the event is related to several files under
events/ dir and buffer instances, someone can just stay open the
files while the event is removed and read/write it.
Perhaps, we need per-event_call refcounter not per-trace_array
one, and do as below.

Open file:
 -> lock event_mutex
 -> find event_call and event_file
 -> get event_call
 -> unlock event_mutex

Close:
 -> lock event_mutex
 -> put event_call
 -> unlock event_mutex

Remove event (via kprobe_events):
 -> lock event_mutex
 -> find event_call
 -> -EBUSY if event is enabled or refcount != 0
    (here, no one accessing the event and not enabled)
 -> unregister_kprobe
 -> remove event
 -> unlock event_mutex

The key is holding event_mutex *and* getting refcount
under any operation.
And of course, we can unregister the kprobe outside of
the event_mutex, but it still need a synchronize_sched
for safety.

 -> lock event_mutex
 -> wait_for_rcu (to ensure no disabled kprobe accesses the event)
 -> find event_call
 -> -EBUSY if event is enabled or refcount != 0
    (here, no one accessing the event and not enabled)
 -> remove event
 -> unlock event_mutex
 -> unregister_kprobe

Thank you,


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
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/