Patch "blktrace: break out of blktrace setup on concurrent calls" has been added to the 4.14-stable tree

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

 



This is a note to let you know that I've just added the patch titled

    blktrace: break out of blktrace setup on concurrent calls

to the 4.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     blktrace-break-out-of-blktrace-setup-on-concurrent-c.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 66ac9d124f4a86f850c00317ddb83d3bf139256c
Author: Luis Chamberlain <mcgrof@xxxxxxxxxx>
Date:   Fri Jun 5 16:58:36 2020 +0200

    blktrace: break out of blktrace setup on concurrent calls
    
    [ Upstream commit 1b0b283648163dae2a214ca28ed5a99f62a77319 ]
    
    We use one blktrace per request_queue, that means one per the entire
    disk.  So we cannot run one blktrace on say /dev/vda and then /dev/vda1,
    or just two calls on /dev/vda.
    
    We check for concurrent setup only at the very end of the blktrace setup though.
    
    If we try to run two concurrent blktraces on the same block device the
    second one will fail, and the first one seems to go on. However when
    one tries to kill the first one one will see things like this:
    
    The kernel will show these:
    
    ```
    debugfs: File 'dropped' in directory 'nvme1n1' already present!
    debugfs: File 'msg' in directory 'nvme1n1' already present!
    debugfs: File 'trace0' in directory 'nvme1n1' already present!
    ``
    
    And userspace just sees this error message for the second call:
    
    ```
    blktrace /dev/nvme1n1
    BLKTRACESETUP(2) /dev/nvme1n1 failed: 5/Input/output error
    ```
    
    The first userspace process #1 will also claim that the files
    were taken underneath their nose as well. The files are taken
    away form the first process given that when the second blktrace
    fails, it will follow up with a BLKTRACESTOP and BLKTRACETEARDOWN.
    This means that even if go-happy process #1 is waiting for blktrace
    data, we *have* been asked to take teardown the blktrace.
    
    This can easily be reproduced with break-blktrace [0] run_0005.sh test.
    
    Just break out early if we know we're already going to fail, this will
    prevent trying to create the files all over again, which we know still
    exist.
    
    [0] https://github.com/mcgrof/break-blktrace
    
    Signed-off-by: Luis Chamberlain <mcgrof@xxxxxxxxxx>
    Signed-off-by: Jan Kara <jack@xxxxxxx>
    Reviewed-by: Bart Van Assche <bvanassche@xxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 304a164f5e7e7..9a55c5bc52434 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -15,6 +15,9 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  *
  */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include <linux/kernel.h>
 #include <linux/blkdev.h>
 #include <linux/blktrace_api.h>
@@ -504,6 +507,16 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
 	 */
 	strreplace(buts->name, '/', '_');
 
+	/*
+	 * bdev can be NULL, as with scsi-generic, this is a helpful as
+	 * we can be.
+	 */
+	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;



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux