[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200501153423.GA12469@infradead.org>
Date: Fri, 1 May 2020 08:34:23 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Greg KH <gregkh@...uxfoundation.org>, axboe@...nel.dk,
viro@...iv.linux.org.uk, bvanassche@....org, rostedt@...dmis.org,
mingo@...hat.com, jack@...e.cz, ming.lei@...hat.com,
nstange@...e.de, akpm@...ux-foundation.org, 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 v3 5/6] blktrace: break out of blktrace setup on
concurrent calls
On Fri, May 01, 2020 at 03:06:26PM +0000, Luis Chamberlain wrote:
> > You have access to a block device here, please use dev_warn() instead
> > here for that, that makes it obvious as to what device a "concurrent
> > blktrace" was attempted for.
>
> The block device may be empty, one example is for scsi-generic, but I'll
> use buts->name.
Is blktrace on /dev/sg something we intentionally support, or just by
some accident of history? Given all the pains it causes I'd be tempted
to just remove the support and see if anyone screams.
Powered by blists - more mailing lists