From patchwork Wed Apr 29 07:46:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11516339 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 37B3392C for ; Wed, 29 Apr 2020 07:46:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 04BD72076B for ; Wed, 29 Apr 2020 07:46:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04BD72076B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7A8518E000B; Wed, 29 Apr 2020 03:46:38 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 7315F8E0001; Wed, 29 Apr 2020 03:46:38 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 647338E000B; Wed, 29 Apr 2020 03:46:38 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 4D26C8E0001 for ; Wed, 29 Apr 2020 03:46:38 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 01F23824805A for ; Wed, 29 Apr 2020 07:46:38 +0000 (UTC) X-FDA: 76760110476.07.fuel77_39dec42cfd537 X-Spam-Summary: 2,0,0,5aafa2bcd43ac47b,d41d8cd98f00b204,mcgrof@gmail.com,,RULES_HIT:41:355:379:541:800:960:967:973:988:989:1260:1311:1314:1345:1359:1437:1515:1534:1542:1711:1730:1747:1777:1792:2393:2525:2559:2563:2682:2685:2693:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:5007:6119:6261:7903:8660:9025:9040:10004:11026:11658:11914:12043:12048:12294:12296:12297:12517:12519:12555:12679:12895:12986:13095:13148:13161:13229:13230:13894:14181:14394:14721:14824:21063:21080:21212:21324:21433:21444:21451:21627:21939:21990:30029:30054:30070,0,RBL:209.85.216.67:@gmail.com:.lbl8.mailshell.net-62.50.0.100 66.100.201.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:23,LUA_SUMMARY:none X-HE-Tag: fuel77_39dec42cfd537 X-Filterd-Recvd-Size: 4998 Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Apr 2020 07:46:37 +0000 (UTC) Received: by mail-pj1-f67.google.com with SMTP id y6so440133pjc.4 for ; Wed, 29 Apr 2020 00:46:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lbuhBnmZzFbDhZxSJ1ni5AOA61z3VyXXGZL4QHqGGx0=; b=cS3OKUcRWAQVo9am5pVghpTVNnIASbjYjS4VCoLJw0BrsVkmVg1ndz4EQ+SmkpqRYo gc9zHGo+bX/lhVbICjvvMZ+FiLSlwGVbaarpTwjz6Bz3SmMNSa30t7i4DXDOFWgHmp1J Hbq8aXevAWo1Jr26ChKyUMOAjWjqDvQSIAewo83XqjTbUMhMUJxzsge2FD1ncfd/7DsT bqwF5WhGU4YKmKJeDa44CVPQGmm/cChHxlyZ6pndz57n3W9VO6Q25DdbvWFALO9Npib0 bMkXDHgbxR4HE93/v1AEGzp5Osz9SBnl9GQPfgHyKQTAztosdxfgunplrLPRyT3vLj3e y2WA== X-Gm-Message-State: AGi0PubzNQy4a8px/JuoPqcNoLGDuJaf4wWRZ3D36AYVwx0sz6VbS9Fl SgKdV1qgaXTxKkapKarYLJ8= X-Google-Smtp-Source: APiQypKrREry4NDgPPBJilLfXP5Wql3EjomxOYfYxqGwUMX/NYY+ZmpZXVnkCpQ7jDJW/k/bn9/ubQ== X-Received: by 2002:a17:90a:e382:: with SMTP id b2mr1640417pjz.110.1588146396679; Wed, 29 Apr 2020 00:46:36 -0700 (PDT) Received: from 42.do-not-panic.com (42.do-not-panic.com. [157.230.128.187]) by smtp.gmail.com with ESMTPSA id r31sm387543pgl.86.2020.04.29.00.46.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2020 00:46:35 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 1548241DCA; Wed, 29 Apr 2020 07:46:30 +0000 (UTC) From: Luis Chamberlain To: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org, gregkh@linuxfoundation.org, rostedt@goodmis.org, mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com, nstange@suse.de, akpm@linux-foundation.org Cc: 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, Luis Chamberlain Subject: [PATCH v3 5/6] blktrace: break out of blktrace setup on concurrent calls Date: Wed, 29 Apr 2020 07:46:26 +0000 Message-Id: <20200429074627.5955-6-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200429074627.5955-1-mcgrof@kernel.org> References: <20200429074627.5955-1-mcgrof@kernel.org> MIME-Version: 1.0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 --- kernel/trace/blktrace.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index 5c52976bd762..383045f67cb8 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -4,6 +4,8 @@ * */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include @@ -516,6 +518,11 @@ static int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev, */ strreplace(buts->name, '/', '_'); + if (q->blk_trace) { + pr_warn("Concurrent blktraces are not allowed\n"); + return -EBUSY; + } + bt = kzalloc(sizeof(*bt), GFP_KERNEL); if (!bt) return -ENOMEM;