From patchwork Sat May 9 03:10:57 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 11537925 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 197FB139F for ; Sat, 9 May 2020 03:11:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E4469216FD for ; Sat, 9 May 2020 03:11:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4469216FD 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 DB9B690002A; Fri, 8 May 2020 23:11:04 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id D1C8C90001C; Fri, 8 May 2020 23:11:04 -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 AFAE690002A; Fri, 8 May 2020 23:11:04 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id 89FF490001C for ; Fri, 8 May 2020 23:11:04 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4B943824805A for ; Sat, 9 May 2020 03:11:04 +0000 (UTC) X-FDA: 76795704048.14.sleep76_7dba98eca1920 X-Spam-Summary: 2,0,0,65f1b88377d128d5,d41d8cd98f00b204,mcgrof@gmail.com,,RULES_HIT:41:355:379:541:800:960:967:973:988:989:1260:1311:1314:1345:1359:1431:1437:1515:1535:1542:1711:1730:1747:1777:1792:2393:2525:2538: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:13095:13148:13161:13229:13230:13894:14181:14394:14721:14824:21063:21080:21212:21324:21433:21444:21451:21627:21939:21990:30029:30054:30067:30070,0,RBL:209.85.210.193:@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: sleep76_7dba98eca1920 X-Filterd-Recvd-Size: 5079 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Sat, 9 May 2020 03:11:03 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id z1so1995697pfn.3 for ; Fri, 08 May 2020 20:11:03 -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=cEK33y5M3evHk3zepZBRBq1zuAEKJAta0bGSZcp5I7U=; b=SAmdD+wRwCQ/m0kUt/kNyzyjxusMpQhFRoI0DrtQ8FIPOlpWdEzH9m9k/lG9vj7nvW k3jpBgZFpQna4oHJsszR3ct6rWUqV0chGC2SmAL8JwwddevOUb1XWd2ol+QZsVdYk0ts PYCU6TNGrtUgURxduiS7Pv1n8QxUr29UkDVxpSFx7v9DuGOeBS/xnGf6y2FF6x8m5Die li6Az6M8464FDAVipaJEZwRcVfjUfWLQ9j7NdmO8Kx31i512at6HetZm9VDbI11bvoCt vIZaLY9bJaWneOR+q8N0nGBtu/GyxMFasUWM/LaF5sVUZaivHAkyGEqRcBh37wsQ7gr0 hZbg== X-Gm-Message-State: AGi0PuZCfaQLEULQkorvx+9vpvFoK13lujq65yhNs1OKTH7oHFigOsrb fxVwzfjOhVSCwFwEw/2Zk8E= X-Google-Smtp-Source: APiQypLJMN/211bTPotanM4jUsK4k4pu+kicwA68ZAITFqqfkEyvZgoqNiyBViyjSN8+owsWBeCmNA== X-Received: by 2002:a62:6545:: with SMTP id z66mr5765485pfb.87.1588993863018; Fri, 08 May 2020 20:11:03 -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 k186sm2518635pga.94.2020.05.08.20.11.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2020 20:11:00 -0700 (PDT) Received: by 42.do-not-panic.com (Postfix, from userid 1000) id 0657241D67; Sat, 9 May 2020 03:11:00 +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 v4 4/5] blktrace: break out of blktrace setup on concurrent calls Date: Sat, 9 May 2020 03:10:57 +0000 Message-Id: <20200509031058.8239-5-mcgrof@kernel.org> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20200509031058.8239-1-mcgrof@kernel.org> References: <20200509031058.8239-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 | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index 6c10a1427de2..bd5ec2184d46 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -3,6 +3,9 @@ * Copyright (C) 2006 Jens Axboe * */ + +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include @@ -493,6 +496,12 @@ 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 on %s\n", + buts->name); + return -EBUSY; + } + bt = kzalloc(sizeof(*bt), GFP_KERNEL); if (!bt) return -ENOMEM;