All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>, Jens Axboe <jens.axboe@oracle.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/7] blktrace: remove blk_probe_mutex
Date: Sun, 22 Mar 2009 14:04:14 +0800	[thread overview]
Message-ID: <49C5D4DE.30002@cn.fujitsu.com> (raw)
In-Reply-To: <20090320130309.GJ30407@ghostprotocols.net>

Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 20, 2009 at 09:48:26AM +0800, Li Zefan escreveu:
>> blk_register_tracepoints() always returns 0, so make it return void, thus
>> we don't need to use blk_probe_mutex to protect blk_probes_ref.
>>
>> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> 
> Historic reasons, when I first worked on this I found all those WARN_ONs
> in blk_register_tracepoints a bogosity that should be later fixed, but
> to reduce the patch size I never got around to submit the proper patch,
> so I don't think that the fix is what you suggests, here it is what I
> had before I removed the non-essential parts of the patch:
> 

I though register_trace_xxx() will fail only when there is a name collision,
in this case WARN_ON() and return 0 should be reasonable. But I just dig into
the code and found it may allocate memory and thus might return ENOMEM, so
I guess it's better to check the return value, though it will hardly happen
in real-life..

> +static void blk_tracer_error(const char *name)
> +{
> +	pr_info("blk trace: Couldn't activate tracepoint "
> +		"probe to block_%s\n", name);
> +}
> +
> +#define register_trace_block(tpoint)				     \
> +	ret = register_trace_block_##tpoint(blk_add_trace_##tpoint); \
> +	if (ret) { 						     \
> +		blk_tracer_error(#tpoint);			     \
> +		goto *exit_point;		  		     \
> +	} else							     \
> +		exit_point = &&fail_deprobe_##tpoint;
> +	
> +
> +#define fail_trace_block(tpoint)	\
> +	fail_deprobe_##tpoint:		\
> +		unregister_trace_block_##tpoint(blk_add_trace_##tpoint)
> +
> +static int tracing_blk_register(void)
> +{
> +	int ret;
> +	void *exit_point = &&error;
> +
> +	register_trace_block(rq_abort);
> +	register_trace_block(rq_insert);
> +	register_trace_block(rq_issue);
> +	register_trace_block(rq_requeue);
> +	register_trace_block(rq_complete);
> +	register_trace_block(bio_bounce);
> +	register_trace_block(bio_backmerge);
> +	register_trace_block(bio_frontmerge);
> +	register_trace_block(bio_queue);
> +	register_trace_block(getrq);
> +	register_trace_block(sleeprq);
> +	register_trace_block(plug);
> +	register_trace_block(unplug_timer);
> +	register_trace_block(unplug_io);
> +	register_trace_block(split);
> +	register_trace_block(remap);
> +
> +	return 0;
> +
> +	fail_trace_block(remap);
> +	fail_trace_block(split);
> +	fail_trace_block(unplug_io);
> +	fail_trace_block(unplug_timer);
> +	fail_trace_block(plug);
> +	fail_trace_block(sleeprq);
> +	fail_trace_block(getrq);
> +	fail_trace_block(bio_queue);
> +	fail_trace_block(bio_frontmerge);
> +	fail_trace_block(bio_backmerge);
> +	fail_trace_block(bio_bounce);
> +	fail_trace_block(rq_complete);
> +	fail_trace_block(rq_requeue);
> +	fail_trace_block(rq_issue);
> +	fail_trace_block(rq_insert);
> +	fail_trace_block(rq_abort);
> +error:
> +	return ret;
> +}
> +
> +static void tracing_blk_unregister(void)
> +{
> +	unregister_trace_block_remap(blk_add_trace_remap);
> +	unregister_trace_block_split(blk_add_trace_split);
> +	unregister_trace_block_unplug_io(blk_add_trace_unplug_io);
> +	unregister_trace_block_unplug_timer(blk_add_trace_unplug_timer);
> +	unregister_trace_block_plug(blk_add_trace_plug);
> +	unregister_trace_block_sleeprq(blk_add_trace_sleeprq);
> +	unregister_trace_block_getrq(blk_add_trace_getrq);
> +	unregister_trace_block_bio_queue(blk_add_trace_bio_queue);
> +	unregister_trace_block_bio_frontmerge(blk_add_trace_bio_frontmerge);
> +	unregister_trace_block_bio_backmerge(blk_add_trace_bio_backmerge);
> +	unregister_trace_block_bio_complete(blk_add_trace_bio_complete);
> +	unregister_trace_block_bio_bounce(blk_add_trace_bio_bounce);
> +	unregister_trace_block_rq_complete(blk_add_trace_rq_complete);
> +	unregister_trace_block_rq_requeue(blk_add_trace_rq_requeue);
> +	unregister_trace_block_rq_issue(blk_add_trace_rq_issue);
> +	unregister_trace_block_rq_insert(blk_add_trace_rq_insert);
> +	unregister_trace_block_rq_abort(blk_add_trace_rq_abort);
> +	tracepoint_synchronize_unregister();
> +}
> 
> Regards,
> 
> - Arnaldo
> 
> 

  reply	other threads:[~2009-03-22  6:04 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-20  1:47 [PATCH 0/7] blktrace: various cleanups and fixes Li Zefan
2009-03-20  1:47 ` [PATCH 1/7] blktrace: fix possible memory leak Li Zefan
2009-03-20 10:25   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20 12:53   ` [PATCH 1/7] " Arnaldo Carvalho de Melo
2009-03-21 15:18   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20  1:48 ` [PATCH 2/7] blktrace: make blk_tracer_enabled a bool flag Li Zefan
2009-03-20  8:47   ` Frederic Weisbecker
2009-03-20 10:26   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20 12:58   ` [PATCH 2/7] " Arnaldo Carvalho de Melo
2009-03-21 15:18   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20  1:48 ` [PATCH 3/7] blktrace: remove blk_probe_mutex Li Zefan
2009-03-20  8:50   ` Frederic Weisbecker
2009-03-20 10:26   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20 13:03   ` [PATCH 3/7] " Arnaldo Carvalho de Melo
2009-03-22  6:04     ` Li Zefan [this message]
2009-03-22 15:09       ` Arnaldo Carvalho de Melo
2009-03-21 15:18   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20  1:48 ` [PATCH 4/7] blktrace: don't increase blk_probes_ref if failed to setup blk trace Li Zefan
2009-03-20 10:26   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20 13:04   ` [PATCH 4/7] " Arnaldo Carvalho de Melo
2009-03-21 15:18   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20  1:49 ` [PATCH 5/7] blktrace: report EBUSY correctly Li Zefan
2009-03-20 10:26   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20 13:10   ` [PATCH 5/7] " Arnaldo Carvalho de Melo
2009-03-21 15:18     ` Ingo Molnar
2009-03-21 15:19   ` [tip:tracing/blktrace] " Li Zefan
2009-03-20  1:49 ` [PATCH 6/7] blktrace: remove sysfs_blk_trace_enable_show/store() Li Zefan
2009-03-20  3:33   ` Li Zefan
2009-03-20 10:26     ` [tip:tracing/blktrace] " Li Zefan
2009-03-21 15:19     ` Li Zefan
2009-03-20 13:07   ` [PATCH 6/7] " Arnaldo Carvalho de Melo
2009-03-20  1:49 ` [PATCH 7/7] blktrace: avoid accessing NULL bdev->bd_disk Li Zefan
2009-03-20  2:34   ` Li Zefan
2009-03-20 10:26     ` [tip:tracing/blktrace] " Li Zefan
2009-03-21 15:19     ` Li Zefan
2009-03-20 13:08   ` [PATCH 7/7] " Arnaldo Carvalho de Melo
2009-03-20 10:20 ` [PATCH 0/7] blktrace: various cleanups and fixes Ingo Molnar
2009-03-20 11:09   ` Ingo Molnar
2009-03-23 14:48     ` Steven Rostedt

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=49C5D4DE.30002@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.