linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Luis Chamberlain <mcgrof@kernel.org>,
	axboe@kernel.dk, viro@zeniv.linux.org.uk,
	gregkh@linuxfoundation.org, rostedt@goodmis.org,
	mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com,
	nstange@suse.de, akpm@linux-foundation.org
Cc: mhocko@suse.com, yukuai3@huawei.com, martin.petersen@oracle.com,
	jejb@linux.ibm.com, linux-block@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 8/8] block: create the request_queue debugfs_dir on registration
Date: Sat, 20 Jun 2020 11:07:43 -0700	[thread overview]
Message-ID: <02112994-4cd7-c749-6bd7-66a772593c90@acm.org> (raw)
In-Reply-To: <20200619204730.26124-9-mcgrof@kernel.org>

On 2020-06-19 13:47, Luis Chamberlain wrote:
> We were only creating the request_queue debugfs_dir only
> for make_request block drivers (multiqueue), but never for
> request-based block drivers. We did this as we were only
> creating non-blktrace additional debugfs files on that directory
> for make_request drivers. However, since blktrace *always* creates
> that directory anyway, we special-case the use of that directory
> on blktrace. Other than this being an eye-sore, this exposes
> request-based block drivers to the same debugfs fragile
> race that used to exist with make_request block drivers
> where if we start adding files onto that directory we can later
> run a race with a double removal of dentries on the directory
> if we don't deal with this carefully on blktrace.
> 
> Instead, just simplify things by always creating the request_queue
> debugfs_dir on request_queue registration. Rename the mutex also to
> reflect the fact that this is used outside of the blktrace context.

There are two changes in this patch: a bug fix and a rename of a mutex.
I don't like it to see two changes in a single patch.

Additionally, is the new mutex name really better than the old name? The
proper way to use mutexes is to use mutexes to protect data instead of
code. Where is the documentation that mentions which member variable(s)
of which data structures are protected by the mutex formerly called
blk_trace_mutex? Since the new name makes it even less clear which data
is protected by this mutex, is the new name really better than the old name?

Thanks,

Bart.


  parent reply	other threads:[~2020-06-20 18:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19 20:47 [PATCH v7 0/8] blktrace: fix debugfs use after free Luis Chamberlain
2020-06-19 20:47 ` [PATCH v7 1/8] block: add docs for gendisk / request_queue refcount helpers Luis Chamberlain
2020-06-19 20:47 ` [PATCH v7 2/8] block: clarify context for refcount increment helpers Luis Chamberlain
2020-06-19 20:47 ` [PATCH v7 3/8] block: revert back to synchronous request_queue removal Luis Chamberlain
2020-06-19 20:47 ` [PATCH v7 4/8] blktrace: annotate required lock on do_blk_trace_setup() Luis Chamberlain
2020-06-20 17:02   ` Bart Van Assche
2020-06-19 20:47 ` [PATCH v7 5/8] loop: be paranoid on exit and prevent new additions / removals Luis Chamberlain
2020-06-20 17:11   ` Bart Van Assche
2020-06-22 12:27     ` Luis Chamberlain
2020-06-23  2:16       ` Bart Van Assche
2020-06-23 16:56         ` Luis Chamberlain
2020-06-23 17:05       ` Johannes Thumshirn
2020-06-24 12:08         ` Luis Chamberlain
2020-06-19 20:47 ` [PATCH v7 6/8] blktrace: fix debugfs use after free Luis Chamberlain
2020-06-20  7:29   ` Christoph Hellwig
2020-06-20 17:31   ` Bart Van Assche
2020-06-22 12:36     ` Luis Chamberlain
2020-06-19 20:47 ` [PATCH v7 7/8] blktrace: ensure our debugfs dir exists Luis Chamberlain
2020-06-20  7:29   ` Christoph Hellwig
2020-06-20 17:33   ` Bart Van Assche
2020-06-19 20:47 ` [PATCH v7 8/8] block: create the request_queue debugfs_dir on registration Luis Chamberlain
2020-06-20  7:30   ` Christoph Hellwig
2020-06-20 18:07   ` Bart Van Assche [this message]
2020-06-22 12:42     ` Luis Chamberlain
2020-06-23  3:18       ` Bart Van Assche
2020-06-20 21:18 ` [PATCH v7 0/8] blktrace: fix debugfs use after free 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=02112994-4cd7-c749-6bd7-66a772593c90@acm.org \
    --to=bvanassche@acm.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=jejb@linux.ibm.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=martin.petersen@oracle.com \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@suse.com \
    --cc=ming.lei@redhat.com \
    --cc=mingo@redhat.com \
    --cc=nstange@suse.de \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yukuai3@huawei.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;
as well as URLs for NNTP newsgroup(s).