linux-btrace.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: linux-btrace@vger.kernel.org
Subject: Re: blktrace hangs after "--kill" option
Date: Mon, 05 Jan 2009 09:15:02 +0000	[thread overview]
Message-ID: <20090105091502.GF32491@kernel.dk> (raw)
In-Reply-To: <1230875278.8200.2.camel@vinaysridhar.in.ibm.com>

On Fri, Jan 02 2009, Vinay Sridhar wrote:
> Hello,
> 
> On executing "blktrace -k" on a running trace, the trace hangs. After
> killing the trace, rerunning it results in "BLKTRACESTOP: invalid
> argument" messages.
> 
> This was discussed earlier here:
> http://www.mail-archive.com/linux-btrace@vger.kernel.org/msg00229.html
> 
> But I dont see this fix to have been included as I'm still seeing this
> error with the the latest kernel. Could someone please indicate why this
> fix didnt go in? I was able to port the above suggested fix to 2.6.28.

I think I wanted to test it a bit more. I'll toss it in for 2.6.29 and
give it some testing! Thanks for the reminder...


> 
> 
> diff -Nuarp a/block/blktrace.c b/block/blktrace.c
> --- a/block/blktrace.c	2008-12-24 17:26:37.000000000 -0600
> +++ b/block/blktrace.c	2009-01-02 11:13:11.000000000 -0600
> @@ -181,59 +181,12 @@ EXPORT_SYMBOL_GPL(__blk_add_trace);
>  
>  static struct dentry *blk_tree_root;
>  static DEFINE_MUTEX(blk_tree_mutex);
> -static unsigned int root_users;
> -
> -static inline void blk_remove_root(void)
> -{
> -	if (blk_tree_root) {
> -		debugfs_remove(blk_tree_root);
> -		blk_tree_root = NULL;
> -	}
> -}
> -
> -static void blk_remove_tree(struct dentry *dir)
> -{
> -	mutex_lock(&blk_tree_mutex);
> -	debugfs_remove(dir);
> -	if (--root_users = 0)
> -		blk_remove_root();
> -	mutex_unlock(&blk_tree_mutex);
> -}
> -
> -static struct dentry *blk_create_tree(const char *blk_name)
> -{
> -	struct dentry *dir = NULL;
> -	int created = 0;
> -
> -	mutex_lock(&blk_tree_mutex);
> -
> -	if (!blk_tree_root) {
> -		blk_tree_root = debugfs_create_dir("block", NULL);
> -		if (!blk_tree_root)
> -			goto err;
> -		created = 1;
> -	}
> -
> -	dir = debugfs_create_dir(blk_name, blk_tree_root);
> -	if (dir)
> -		root_users++;
> -	else {
> -		/* Delete root only if we created it */
> -		if (created)
> -			blk_remove_root();
> -	}
> -
> -err:
> -	mutex_unlock(&blk_tree_mutex);
> -	return dir;
> -}
>  
>  static void blk_trace_cleanup(struct blk_trace *bt)
>  {
> -	relay_close(bt->rchan);
>  	debugfs_remove(bt->msg_file);
>  	debugfs_remove(bt->dropped_file);
> -	blk_remove_tree(bt->dir);
> +	relay_close(bt->rchan);
>  	free_percpu(bt->sequence);
>  	free_percpu(bt->msg_data);
>  	kfree(bt);
> @@ -336,7 +289,18 @@ static int blk_subbuf_start_callback(str
>  
>  static int blk_remove_buf_file_callback(struct dentry *dentry)
>  {
> +	struct dentry *parent = dentry->d_parent;
>  	debugfs_remove(dentry);
> +
> +	/*
> +	* this will fail for all but the last file, but that is ok. what we
> +	* care about is the top level buts->name directory going away, when
> +	* the last trace file is gone. Then we don't have to rmdir() that
> +	* manually on trace stop, so it nicely solves the issue with
> +	* force killing of running traces.
> +	*/
> +
> +	debugfs_remove(parent);
>  	return 0;
>  }
>  
> @@ -394,7 +358,15 @@ int do_blk_trace_setup(struct request_qu
>  		goto err;
>  
>  	ret = -ENOENT;
> -	dir = blk_create_tree(buts->name);
> +
> +	if (!blk_tree_root) {
> +		blk_tree_root = debugfs_create_dir("block", NULL);
> +		if (!blk_tree_root)
> +			return -ENOMEM;
> +	}
> +
> +	dir = debugfs_create_dir(buts->name, blk_tree_root);
> +
>  	if (!dir)
>  		goto err;
>  
> @@ -437,8 +409,6 @@ int do_blk_trace_setup(struct request_qu
>  
>  	return 0;
>  err:
> -	if (dir)
> -		blk_remove_tree(dir);
>  	if (bt) {
>  		if (bt->msg_file)
>  			debugfs_remove(bt->msg_file);
> 
> 
> 
> Vinay Sridhar,
> Linux Technology Center,
> IBM ISTL,
> Bangalore, India
> 
> 

-- 
Jens Axboe


  reply	other threads:[~2009-01-05  9:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-02  5:59 blktrace hangs after "--kill" option Vinay Sridhar
2009-01-05  9:15 ` Jens Axboe [this message]
2009-02-03  6:58 ` Vinay Sridhar
2009-02-03  7:06 ` Jens Axboe

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=20090105091502.GF32491@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=linux-btrace@vger.kernel.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 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).