Re: [PATCH v6 6/6] blktrace: fix debugfs use after free

[Luis Chamberlain <mcgrof@kernel.org>]

I like this, more below.

On Tue, Jun 09, 2020 at 08:06:02AM -0700, Christoph Hellwig wrote:
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index 432fa60e7f8808..44239f603379d5 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -492,34 +493,23 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
>  	 */
>  	strreplace(buts->name, '/', '_');
>  
> -	/*
> -	 * We have to use a partition directory if a partition is being worked
> -	 * on. The same request_queue is shared between all partitions.
> -	 */
> -	if (bdev && bdev != bdev->bd_contains) {
> -		dir = bdev->bd_part->debugfs_dir;
> -	} else if (IS_ENABLED(CONFIG_CHR_DEV_SG) &&
> -		   MAJOR(dev) == SCSI_GENERIC_MAJOR) {
> +	bt = kzalloc(sizeof(*bt), GFP_KERNEL);
> +	if (!bt)
> +		return -ENOMEM;
> +
> +	if (unlikely(!bdev)) {
>  		/*
> -		 * scsi-generic exposes the request_queue through the /dev/sg*
> -		 * interface but since that uses a different path than whatever
> -		 * the respective scsi driver device name may expose and use
> -		 * for the request_queue debugfs_dir. We have a dedicated
> -		 * dentry for scsi-generic then.
> +		 * When tracing something that is not a block device (e.g. the
> +		 * /dev/sg nodes), create debugfs directory on demand.  This
> +		 * directory will be remove when stopping the trace.

Is scsi-generic is the only unwanted ugly child blktrace has to deal
with? For some reason I thought drivers/md/md.c was one but it seems
like it is not. Do we have an easy way to search for these? I think
this would just affect how we express the comment only.

>  		 */
> -		dir = q->sg_debugfs_dir;
> +		dir = debugfs_create_dir(buts->name, blk_debugfs_root);
> +		bt->dir = dir;

The other chicken and egg problem to consider at least in the comments
is that the debugfs directory for these types of devices *have* an
exposed path, but the data structure is rather opaque to the device and
even blktrace.  Fortunately given the recent set of changes around the
q->blk_trace and clarifications around its use we have made it clear now
that so long as hold the q->blk_trace_mutex *and* check q->blk_trace we
*should* not race against two separate creations of debugfs directories,
so I think this is safe, so long as these indpendent drivers don't end
up re-using the same path for some other things later in the future, and
since we have control over what goes under debugfsroot block / I think
we should be good.

But I think that the concern for race on names may still be worth
explaining a bit here.

  Luis