From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, lttng-dev@lists.lttng.org
Subject: Re: [tracepoint] cargo-culting considered harmful...
Date: Fri, 25 Jan 2013 12:30:30 -0500 [thread overview]
Message-ID: <20130125173030.GB23720@Krystal> (raw)
In-Reply-To: <20130125153159.GE4503@ZenIV.linux.org.uk>
* Al Viro (viro@ZenIV.linux.org.uk) wrote:
> On Fri, Jan 25, 2013 at 09:49:53AM -0500, Mathieu Desnoyers wrote:
> > static
> > void lttng_enumerate_task_fd(struct lttng_session *session,
> > struct task_struct *p, char *tmp)
> > {
> > struct fdtable *fdt;
> > struct file *filp;
> > unsigned int i;
> > const unsigned char *path;
> >
> > task_lock(p);
> > if (!p->files)
> > goto unlock_task;
> > spin_lock(&p->files->file_lock);
> > fdt = files_fdtable(p->files);
> > for (i = 0; i < fdt->max_fds; i++) {
> > filp = fcheck_files(p->files, i);
> > if (!filp)
> > continue;
> > path = d_path(&filp->f_path, tmp, PAGE_SIZE);
> > /* Make sure we give at least some info */
> > trace_lttng_statedump_file_descriptor(session, p, i,
> > IS_ERR(path) ?
> > filp->f_dentry->d_name.name :
> > path);
> > }
> > spin_unlock(&p->files->file_lock);
> > unlock_task:
> > task_unlock(p);
> > }
>
> *cringe*
>
> a) yes, it needs d_lock for that ->d_name access
> b) iterate_fd() is there for purpose; use it, instead of open-coding the
> damn loop. Something like
>
> struct ctx {
> char *page;
> struct lttng_session *session,
> struct task_struct *p;
> };
>
> static int dump_one(void *p, struct file *file, unsigned fd)
> {
> struct ctx *ctx = p;
> const char *s = d_path(&file->f_path, ctx->page, PAGE_SIZE);
> struct dentry *dentry;
> if (!IS_ERR(s)) {
> trace_lttng_statedump_file_descriptor(ctx->session, ctx->p, fd, s);
> return 0;
> }
> /* Make sure we give at least some info */
> dentry = file->f_path.dentry;
> spin_lock(&dentry->d_lock);
> trace_lttng_statedump_file_descriptor(ctx->session, ctx->p, fd,
> dentry->d_name);
> spin_unlock(&dentry->d_lock);
> return 0;
> }
>
> ...
> task_lock(p);
> iterate_fd(p->files, 0, dump_one, &(struct ctx){tmp, session, p});
> task_unlock(p);
>
> assuming it wouldn't be better to pass tmp/session/p as the single pointer
> to struct in the first place - I don't know enough about the callers of
> that sucker to tell. And yes, iterate_fd() will DTRT if given NULL as the
> first argument. The second argument is "which descriptor should I start
> from?", callback is called for everything present in the table starting from
> that place until it returns non-zero or the end of table is reached...
Thanks !! Modulo a couple of trivial nits, I've integrated your
suggestions. I'm creating a lttng_iterate_fd() wrapper for older kernels
(yeah.. we deal with kernels back to 2.6.32).
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
parent reply other threads:[~2013-01-25 17:30 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20130125153159.GE4503@ZenIV.linux.org.uk>]
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=20130125173030.GB23720@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=lttng-dev@lists.lttng.org \
--cc=viro@ZenIV.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).