On Thu, Apr 16, 2020 at 06:20:54AM +0000, Luis Chamberlain wrote: > On Thu, Apr 16, 2020 at 01:47:50PM +0800, Ming Lei wrote: > > On Thu, Apr 16, 2020 at 05:25:24AM +0000, Luis Chamberlain wrote: > > > On Thu, Apr 16, 2020 at 10:10:36AM +0800, Ming Lei wrote: > > > > In theory, multiple partitions can be traced concurrently, but looks > > > > it never works, so it won't cause trouble for multiple partition trace. > > > > > > > > One userspace visible change is that blktrace debugfs dir name is switched > > > > to disk name from partition name in case of partition trace, will it > > > > break some utilities? > > > > > > How is this possible, its not clear to me, we go from: > > > > > > - q->debugfs_dir = debugfs_create_dir(kobject_name(q->kobj.parent), > > > - blk_debugfs_root); > > > > > > To this: > > > > > > + q->debugfs_dir = debugfs_create_dir(kobject_name(q->kobj.parent), > > > + blk_debugfs_root); > > > > > > > > > Maybe I am overlooking something. > > > > Your patch removes the blktrace debugfs dir: > > > > do_blk_trace_setup() > > > > - dir = debugfs_lookup(buts->name, blk_debugfs_root); > > - if (!dir) > > - bt->dir = dir = debugfs_create_dir(buts->name, blk_debugfs_root); > > - > > > > Then create blktrace attributes under the dir of q->debugfs_dir. > > > > However, buts->name could be one partition device name, but > > I can see how buts->name is set to bdevname() which expands to > disk_name(bdev->bd_disk, bdev->bd_part->partno, buf). > > > q->debugfs_dir has to be disk name. > > I can't see this, can you point me to where it is clear the > request_queue kobject's parent is sure to be the disk name? blk_register_queue(): ... ret = kobject_add(&q->kobj, kobject_get(&dev->kobj), "%s", "queue"); ... > > If it is different, the issue I don't think should be debugfs, but > the bigger issue would be that blktrace on two different partitions > would clash. > > Also, the *old* lookup intent on partitions always would fail on mq > and we'd end up creating a directory. > > I think we'd need to create a directory per partition, even when we > don't use blktrace. That makes this more complex than I'd hope for. Anyway, the current ABI can't be broken, also I'd suggest to understand how the userpace utility uses blktrace syscall interfaces first before figuring any new approach. Thanks, Ming