From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] [PATCH] Expose kernel tracer to user-space
Date: Tue, 26 Jun 2012 13:01:09 -0400 [thread overview]
Message-ID: <20120626170109.GC23255@Krystal> (raw)
In-Reply-To: <4FE9CC91.5030301@gmail.com>
* Francis Giraldeau (francis.giraldeau at gmail.com) wrote:
> Le 2012-06-26 08:40, Mathieu Desnoyers a ?crit :
> >> +/*
> >> + * lttng_uevent_set_handler - set handler functions for uevent
> >> + *
> >> + * Access to handler code is protected with rwlock in order to
> >> + * prevent the optional module to be removed while in use.
> >> + */
> >> +
> >> +void lttng_uevent_set_handler(write_ops_t handler)
> >> +{
> >> + write_lock(&uevent_rwlock);
> >
> > write lock not necessary.
> >
> > if (!lttng_uevent_set_handler)
> > release refcount in prior handler's module.
> >
> > then:
> > take a refcount on the module that contains the handler address.
> > (explicit)
>
>
> The function now looks like this:
>
> void lttng_uevent_set_handler(struct file_operations *fops)
> {
> if (lttng_uevent_handler) {
> module_put(lttng_uevent_handler->owner);
> }
> if (fops && try_module_get(fops->owner)) {
> lttng_uevent_handler = fops;
> return;
> }
> lttng_uevent_handler = NULL;
> return;
> }
>
> The problem with this approach is that lttng_uevent can't be unloaded
> anymore:
>
> rmmod lttng_uevent
> ERROR: Module lttng_uevent is in use
>
> The module lttng_uevent can't be unloaded without unloading the module
> lttng_tracer. The function module_exit of lttng_uevent is never called,
> such that there is a chicken-and-egg situation. This problem was solved
> by using rwlock to access the handler pointer. In the rare event when
> unload module would occur while a trace event is recorded, the write
> lock was preventing to change the handler pointer while it's in use. But
> maybe there is another way to do it?
Good point, circular dependency on the destructor is not good, because
there is no way to unload the module.
Another way to do it is to use RCU. module unload contains a
synchronize_rcu() call, so you can protect your handler with:
/* Using RCU to protect against module removal */
rcu_read_lock();
handler = rcu_dereference(lttng_uevent_handler);
ret = handler(...)));
rcu_read_unlock;
return ret;
Thanks,
Mathieu
>
> Thanks!
>
> Francis Giraldeau
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
prev parent reply other threads:[~2012-06-26 17:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 23:24 Francis Giraldeau
2012-06-05 23:40 ` Francis Giraldeau
2012-06-26 6:40 ` Mathieu Desnoyers
2012-06-26 14:52 ` Francis Giraldeau
2012-06-26 17:01 ` Mathieu Desnoyers [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120626170109.GC23255@Krystal \
--to=mathieu.desnoyers@efficios.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox