From: Jeff Mahoney <jeffm@suse.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>, Tejun Heo <tj@kernel.org>,
Linux Kernel Maling List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] blktrace: fix race with open trace files and directory removal
Date: Fri, 27 Sep 2013 15:01:29 -0400 [thread overview]
Message-ID: <5245D609.1060809@suse.com> (raw)
In-Reply-To: <x49eh8adrg3.fsf@segfault.boston.devel.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
On 9/27/13 2:56 PM, Jeff Moyer wrote:
> Jeff Mahoney <jeffm@suse.com> writes:
>
>> On 9/27/13 2:43 PM, Jeff Moyer wrote:
>>> Jeff Mahoney <jeffm@suse.com> writes:
>>>
>>>> There's a bug in the blktrace client where it will stop and tear down
>>>> all of the tracing instances for devices it's opened whether it
>>>> successfully completed the setup or not.
>>>>
>>>> By starting multiple blktrace processes on the same device, it's possible
>>>> to permanently disable blktrace on that device. The cause is that when
>>>> the first blktrace process to exit tears down the directory structure,
>>>> the trace files are still held open. Debugfs removes the dentries for the
>>>> open files just fine but the relay implementation doesn't remove the
>>>> dentries until all of the references to the file are dropped. This means
>>>> that if there are open files when debugfs_remove is called for the device
>>>> directory, the directory is not empty and can't be removed. Since the
>>>> shutdown of the blktrace structure xchg's the structure out, there's no
>>>> way to clean up the directory and any new blktrace processes will fail
>>>> to start because it can't create the directory.
>>>>
>>>> This patch adds a kref to blk_trace so that we can release it after the
>>>> initial reference as well as all of the references accumulated by the
>>>> relay files are dropped.
>>>
>>> Can't we just do proper unwinding of errors in the do_blktrace_setup
>>> function? In other words, don't just blindly call blk_trace_free, but
>>> instead just undo anything we've done.
>>
>> No. It's not the setup that's causing the problem. It's one process
>> holding the trace files open while another process calls BLKTRACETEARDOWN.
>
> Ah, right. So, in that case I'd rather restrict the ioctl to just the
> process that setup the trace. Jens, Tejun, any opinions?
We'd also need to check to see if the task that started the trace is
still around.
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
prev parent reply other threads:[~2013-09-27 19:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 3:11 [PATCH] blktrace: fix race with open trace files and directory removal Jeff Mahoney
2013-09-27 18:43 ` Jeff Moyer
2013-09-27 18:53 ` Jeff Mahoney
2013-09-27 18:56 ` Jeff Moyer
2013-09-27 19:01 ` Jeff Mahoney [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=5245D609.1060809@suse.com \
--to=jeffm@suse.com \
--cc=axboe@kernel.dk \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@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 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.