Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp962107ybz; Wed, 15 Apr 2020 23:33:26 -0700 (PDT) X-Google-Smtp-Source: APiQypKsXCUbsiBts7PxCChDe1mudwmBQRBIu4npMI7niN1qXaEG5bZB6fDcvsFmd78J4VFiDKA4 X-Received: by 2002:a17:906:951:: with SMTP id j17mr8646464ejd.33.1587018806459; Wed, 15 Apr 2020 23:33:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587018806; cv=none; d=google.com; s=arc-20160816; b=edC5JVHkAt3XeaTNnntDjgxeJFxb5IflNgK32Z1gM8OOjiH2L/HadapyBPoEAlGfKr S/umvFS/juZNfhJ8oIVcWI+xG7DcRARNoxZo1hB9nVFYIjL8qPe4Z+TcF4+9SoX+tb2M 2f8AhOlJ4uAkhE4Zjjii+nCI19BLOGO+Fu0taxZIsQAMVd8KN/qTdyNSqSHcyk0qBHTv OrLOGMMgDoCBodkHNXxXjKIVJaWO4mU8bbiPMnhu4tG57o/H9/05EpucXVWRmLSFVYmx dNHJqW4wuyPWaZo8iTrj+fZhIv+EXP6iJpaqd/sqec9sDFJZ/b8ij+6dUeTVRjvuMeM0 ogQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=CROjKRbtqDNxSB0ktwOuky8CijTu7ExjL3TJ8Xjxjqw=; b=T7tggAj6fF2qKV2HiOUPVLbeHW0ZLeZiOg4KwSxPRJFkCNLicQDm050c1epVGTNYUd Ev4bL/1rurSZsgKcmWKcO0mKhmHFaGRXnq/SnGBTkKYhnO5N009ZkIKfXGpyghIQlMCm gXgiSO0kAcgZ9Xtt24lLa+rDtuf5rm2wKgB5S2SFYswtV9HdBVRDA21XC/PHk1gglgbl 4R/9BCVaCILY77p7XsITtRfd2wULRYimkp/WKkQ4xewvRRe279/0AmN3UlcmOSOmpT9m LcXs1ZNxNOnz4S8TFWV4kWzZqzqyaGfagLr0qJ+S2xdpGbDDOBoUDHnmFDj7/N7pT/wf 5a7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZyjhJwx0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m8si680820edb.237.2020.04.15.23.33.02; Wed, 15 Apr 2020 23:33:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZyjhJwx0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408078AbgDPG3s (ORCPT + 99 others); Thu, 16 Apr 2020 02:29:48 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:40927 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2407956AbgDPG3V (ORCPT ); Thu, 16 Apr 2020 02:29:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587018559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CROjKRbtqDNxSB0ktwOuky8CijTu7ExjL3TJ8Xjxjqw=; b=ZyjhJwx0LUq26OUvK3n8qBBCu1mZfLzXbMDmrGy0w5GRbh8TMfLf4sj7xJ/QW8QLBGAEyH 0Y54lRRFUKNcdrGDSSIOmgntzJA9g7fmNOQje134fr++jI86iqK7ANwsMovywwnNocCUxu 7UmmJhKZ4YIM2TGPuE62fDZcBU/YprE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-52-vOMOp-fePw6MlY42ywi5Nw-1; Thu, 16 Apr 2020 02:29:17 -0400 X-MC-Unique: vOMOp-fePw6MlY42ywi5Nw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C8A30802563; Thu, 16 Apr 2020 06:29:13 +0000 (UTC) Received: from T590 (ovpn-8-29.pek2.redhat.com [10.72.8.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E8A9312650D; Thu, 16 Apr 2020 06:29:01 +0000 (UTC) Date: Thu, 16 Apr 2020 14:28:56 +0800 From: Ming Lei To: Luis Chamberlain Cc: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, nstange@suse.de, akpm@linux-foundation.org, mhocko@suse.com, yukuai3@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Omar Sandoval , Hannes Reinecke , Michal Hocko , syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.com Subject: Re: [PATCH 2/5] blktrace: fix debugfs use after free Message-ID: <20200416062856.GD2723777@T590> References: <20200414041902.16769-1-mcgrof@kernel.org> <20200414041902.16769-3-mcgrof@kernel.org> <20200416021036.GA2717677@T590> <20200416052524.GH11244@42.do-not-panic.com> <20200416054750.GA2723777@T590> <20200416062054.GL11244@42.do-not-panic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200416062054.GL11244@42.do-not-panic.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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