[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e728acea-61c1-fcb5-489b-9be8cafe61ea@acm.org>
Date: Sat, 9 May 2020 18:09:38 -0700
From: Bart Van Assche <bvanassche@....org>
To: Luis Chamberlain <mcgrof@...nel.org>, axboe@...nel.dk,
viro@...iv.linux.org.uk, gregkh@...uxfoundation.org,
rostedt@...dmis.org, mingo@...hat.com, jack@...e.cz,
ming.lei@...hat.com, nstange@...e.de, akpm@...ux-foundation.org
Cc: mhocko@...e.com, yukuai3@...wei.com, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 4/5] blktrace: break out of blktrace setup on
concurrent calls
On 2020-05-08 20:10, Luis Chamberlain wrote:
> @@ -493,6 +496,12 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
> */
> strreplace(buts->name, '/', '_');
>
> + if (q->blk_trace) {
> + pr_warn("Concurrent blktraces are not allowed on %s\n",
> + buts->name);
> + return -EBUSY;
> + }
> +
> bt = kzalloc(sizeof(*bt), GFP_KERNEL);
> if (!bt)
> return -ENOMEM;
Is this really sufficient? Shouldn't concurrent do_blk_trace_setup()
calls that refer to the same request queue be serialized to really
prevent that debugfs attribute creation fails?
How about using the block device name instead of the partition name in
the error message since the concurrency context is the block device and
not the partition?
Thanks,
Bart.
Powered by blists - more mailing lists