Re: [PATCH v4 4/5] blktrace: break out of blktrace setup on concurrent calls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 09, 2020 at 06:09:38PM -0700, Bart Van Assche wrote:
> 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?

We'd have to add something like a linked list. Right now I'm just
clarifying things which were not clear before. What you describe is
a functional feature change. I'm just trying to fix a bug and clarify
limitations.

> 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?

blk device argument can be NULL here. sg-generic is one case.

 Luis



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux