Message ID | 20231031120526.11502-3-nick.forrington@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b90f:0:b0:403:3b70:6f57 with SMTP id t15csp185554vqg; Tue, 31 Oct 2023 05:06:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHRLAY10f0t2IKrnVnKiBAQDZWvOyyQSN5ZOGj9dNTOGLGQ2fgT2eXWD2FXFl8O28INzSVX X-Received: by 2002:a17:90a:eacf:b0:27c:f8f4:fedb with SMTP id ev15-20020a17090aeacf00b0027cf8f4fedbmr11128795pjb.21.1698753980796; Tue, 31 Oct 2023 05:06:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698753980; cv=none; d=google.com; s=arc-20160816; b=NUAJliso9PMyhs3SfMEtRT+CII7lEE1whhIcXTRn/njrVOTae40prEUAkcMbbGBVR5 kPH1j6JXdmXCXRLHaLDgGIM0774qnWhxFSk34M3m3KVBA32fqehr8I7VNpKRqdQNNXmC XkE4CwYqe7oaoxK+eRY8RyWCco/H8bNeGgvN/h0jVlkwrQaiecQErpKEJ419OeaKI8xT 2Et4P7nQuqNy/AJ+4xKnYwJ6ebxT2RjHTkXjn4Farw6oPr2OnQaTyeWXS39trh8saXxG AYecEag7bUp/vdvA7S5NAIhNqkgn1xwOBZnfylclQy0rAi4iXwHdAfn2HqqtOGxcDOZg FJ8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=unQCNHn15pZD9q2hOMJWVPBCaA1gljjOf72eHGk7BnY=; fh=KZwJI2IhX2NkYw3UI/ow2q4exUfD2a8wOZqtpxoZpb8=; b=c2RmIExpD+yzO087AgAGQMzHS0VFPeTd6BEYUZ9qKngjBsv0XhjMmfkVYnOm7WtEls l5i/q17bJB03c8wTy6squpbZdVFIFMMUswW9pVvqttS9v9D80L3G+UVJgijyY8AZMSTK wOlr7BhpnlRFtxUNPkr5w+k7DLcLkiAvvmCpW0ftZtB0NgQSeMeLGIX/I4nXslB3WlUf phRxLLi0+QZ2kUsDTgscLoYIOj1HWNj40Fs23w/iBeec5hzQCByuNsmG3IfmS7nBwndk 5Squ+dzIzo+chJv5T/aCdD1ubroX7WBm8Dd76mXdNDxVCBUa7GAr2hGjVpQeudo+qQCH oGhg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id c4-20020a17090ab28400b0027762fed4a0si885342pjr.11.2023.10.31.05.06.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 05:06:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 3724680C710D; Tue, 31 Oct 2023 05:06:17 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344094AbjJaMGD (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 33 others); Tue, 31 Oct 2023 08:06:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344145AbjJaMGA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 31 Oct 2023 08:06:00 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C2516558E; Tue, 31 Oct 2023 05:05:50 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E225E139F; Tue, 31 Oct 2023 05:06:31 -0700 (PDT) Received: from dsg-hive-n1sdp-01.. (dsg-hive-n1sdp-01.cambridge.arm.com [10.2.2.18]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C27EE3F738; Tue, 31 Oct 2023 05:05:48 -0700 (PDT) From: Nick Forrington <nick.forrington@arm.com> To: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Cc: Nick Forrington <nick.forrington@arm.com>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, Arnaldo Carvalho de Melo <acme@redhat.com> Subject: [PATCH 2/2] perf lock info: Enforce exactly one of --map and --thread Date: Tue, 31 Oct 2023 12:05:25 +0000 Message-ID: <20231031120526.11502-3-nick.forrington@arm.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231031120526.11502-1-nick.forrington@arm.com> References: <20231031120526.11502-1-nick.forrington@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 31 Oct 2023 05:06:17 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781272653990111941 X-GMAIL-MSGID: 1781272653990111941 |
Series |
Perf lock improvements
|
|
Commit Message
Nick Forrington
Oct. 31, 2023, 12:05 p.m. UTC
Improve error reporting for command line arguments.
Display error/usage if neither --map or --thread are specified (rather
than a non user-friendly error "Unknown type of information").
Display error/usage if both --map and --thread are specified (rather
than ignoring "--map" and displaying only thread information).
Signed-off-by: Nick Forrington <nick.forrington@arm.com>
---
tools/perf/builtin-lock.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
Comments
Em Tue, Oct 31, 2023 at 12:05:25PM +0000, Nick Forrington escreveu: > Improve error reporting for command line arguments. > > Display error/usage if neither --map or --thread are specified (rather > than a non user-friendly error "Unknown type of information"). > > Display error/usage if both --map and --thread are specified (rather > than ignoring "--map" and displaying only thread information). Shouldn't one of them be the default so that we type less for the most common usage? - Arnaldo > Signed-off-by: Nick Forrington <nick.forrington@arm.com> > --- > tools/perf/builtin-lock.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c > index 3aa8ba5ad928..cf29f648d291 100644 > --- a/tools/perf/builtin-lock.c > +++ b/tools/perf/builtin-lock.c > @@ -2021,6 +2021,27 @@ static int check_lock_report_options(const struct option *options, > return 0; > } > > +static int check_lock_info_options(const struct option *options, > + const char * const *usage) > +{ > + if (!info_map && !info_threads) { > + pr_err("Requires one of --map or --threads\n"); > + parse_options_usage(usage, options, "map", 0); > + parse_options_usage(NULL, options, "threads", 0); > + return -1; > + > + } > + > + if (info_map && info_threads) { > + pr_err("Cannot show map and threads together\n"); > + parse_options_usage(usage, options, "map", 0); > + parse_options_usage(NULL, options, "threads", 0); > + return -1; > + } > + > + return 0; > +} > + > static int check_lock_contention_options(const struct option *options, > const char * const *usage) > > @@ -2709,6 +2730,10 @@ int cmd_lock(int argc, const char **argv) > if (argc) > usage_with_options(info_usage, info_options); > } > + > + if (check_lock_info_options(info_options, info_usage) < 0) > + return -1; > + > /* recycling report_lock_ops */ > trace_handler = &report_lock_ops; > rc = __cmd_report(true); > -- > 2.42.0 > >
On 31/10/2023 15:38, Arnaldo Carvalho de Melo wrote: > Em Tue, Oct 31, 2023 at 12:05:25PM +0000, Nick Forrington escreveu: >> Improve error reporting for command line arguments. >> >> Display error/usage if neither --map or --thread are specified (rather >> than a non user-friendly error "Unknown type of information"). >> >> Display error/usage if both --map and --thread are specified (rather >> than ignoring "--map" and displaying only thread information). > Shouldn't one of them be the default so that we type less for the most > common usage? > > - Arnaldo > There isn't an obvious choice (to me) for which would be the default. Both options display completely different data/outputs, so I think it makes sense to be explicit about which data is requested. An alternative could be to use sub-commands e.g. "perf lock info threads" or just "perf lock threads", although changing the existing options would be more disruptive. Cheers, Nick >> Signed-off-by: Nick Forrington <nick.forrington@arm.com> >> --- >> tools/perf/builtin-lock.c | 25 +++++++++++++++++++++++++ >> 1 file changed, 25 insertions(+) >> >> diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c >> index 3aa8ba5ad928..cf29f648d291 100644 >> --- a/tools/perf/builtin-lock.c >> +++ b/tools/perf/builtin-lock.c >> @@ -2021,6 +2021,27 @@ static int check_lock_report_options(const struct option *options, >> return 0; >> } >> >> +static int check_lock_info_options(const struct option *options, >> + const char * const *usage) >> +{ >> + if (!info_map && !info_threads) { >> + pr_err("Requires one of --map or --threads\n"); >> + parse_options_usage(usage, options, "map", 0); >> + parse_options_usage(NULL, options, "threads", 0); >> + return -1; >> + >> + } >> + >> + if (info_map && info_threads) { >> + pr_err("Cannot show map and threads together\n"); >> + parse_options_usage(usage, options, "map", 0); >> + parse_options_usage(NULL, options, "threads", 0); >> + return -1; >> + } >> + >> + return 0; >> +} >> + >> static int check_lock_contention_options(const struct option *options, >> const char * const *usage) >> >> @@ -2709,6 +2730,10 @@ int cmd_lock(int argc, const char **argv) >> if (argc) >> usage_with_options(info_usage, info_options); >> } >> + >> + if (check_lock_info_options(info_options, info_usage) < 0) >> + return -1; >> + >> /* recycling report_lock_ops */ >> trace_handler = &report_lock_ops; >> rc = __cmd_report(true); >> -- >> 2.42.0 >> >>
On Wed, Nov 1, 2023 at 7:35 AM Nick Forrington <nick.forrington@arm.com> wrote: > > > On 31/10/2023 15:38, Arnaldo Carvalho de Melo wrote: > > Em Tue, Oct 31, 2023 at 12:05:25PM +0000, Nick Forrington escreveu: > >> Improve error reporting for command line arguments. > >> > >> Display error/usage if neither --map or --thread are specified (rather > >> than a non user-friendly error "Unknown type of information"). > >> > >> Display error/usage if both --map and --thread are specified (rather > >> than ignoring "--map" and displaying only thread information). > > Shouldn't one of them be the default so that we type less for the most > > common usage? > > > > - Arnaldo > > > > There isn't an obvious choice (to me) for which would be the default. > > Both options display completely different data/outputs, so I think it > makes sense to be explicit about which data is requested. Maybe we can default to display both. :) Thanks, Namhyung > > > An alternative could be to use sub-commands e.g. "perf lock info > threads" or just "perf lock threads", although changing the existing > options would be more disruptive. > > > Cheers, > Nick > > >> Signed-off-by: Nick Forrington <nick.forrington@arm.com> > >> --- > >> tools/perf/builtin-lock.c | 25 +++++++++++++++++++++++++ > >> 1 file changed, 25 insertions(+) > >> > >> diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c > >> index 3aa8ba5ad928..cf29f648d291 100644 > >> --- a/tools/perf/builtin-lock.c > >> +++ b/tools/perf/builtin-lock.c > >> @@ -2021,6 +2021,27 @@ static int check_lock_report_options(const struct option *options, > >> return 0; > >> } > >> > >> +static int check_lock_info_options(const struct option *options, > >> + const char * const *usage) > >> +{ > >> + if (!info_map && !info_threads) { > >> + pr_err("Requires one of --map or --threads\n"); > >> + parse_options_usage(usage, options, "map", 0); > >> + parse_options_usage(NULL, options, "threads", 0); > >> + return -1; > >> + > >> + } > >> + > >> + if (info_map && info_threads) { > >> + pr_err("Cannot show map and threads together\n"); > >> + parse_options_usage(usage, options, "map", 0); > >> + parse_options_usage(NULL, options, "threads", 0); > >> + return -1; > >> + } > >> + > >> + return 0; > >> +} > >> + > >> static int check_lock_contention_options(const struct option *options, > >> const char * const *usage) > >> > >> @@ -2709,6 +2730,10 @@ int cmd_lock(int argc, const char **argv) > >> if (argc) > >> usage_with_options(info_usage, info_options); > >> } > >> + > >> + if (check_lock_info_options(info_options, info_usage) < 0) > >> + return -1; > >> + > >> /* recycling report_lock_ops */ > >> trace_handler = &report_lock_ops; > >> rc = __cmd_report(true); > >> -- > >> 2.42.0 > >> > >>
Em Wed, Nov 01, 2023 at 11:00:42PM -0700, Namhyung Kim escreveu: > On Wed, Nov 1, 2023 at 7:35 AM Nick Forrington <nick.forrington@arm.com> wrote: > > > > > > On 31/10/2023 15:38, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Oct 31, 2023 at 12:05:25PM +0000, Nick Forrington escreveu: > > >> Improve error reporting for command line arguments. > > >> > > >> Display error/usage if neither --map or --thread are specified (rather > > >> than a non user-friendly error "Unknown type of information"). > > >> > > >> Display error/usage if both --map and --thread are specified (rather > > >> than ignoring "--map" and displaying only thread information). > > > Shouldn't one of them be the default so that we type less for the most > > > common usage? > > > > > > - Arnaldo > > > > > > > There isn't an obvious choice (to me) for which would be the default. > > > > Both options display completely different data/outputs, so I think it > > makes sense to be explicit about which data is requested. > > Maybe we can default to display both. :) Yeah, that would be a better approach, I think. - Arnaldo > Thanks, > Namhyung > > > > > > > An alternative could be to use sub-commands e.g. "perf lock info > > threads" or just "perf lock threads", although changing the existing > > options would be more disruptive. > > > > > > Cheers, > > Nick > > > > >> Signed-off-by: Nick Forrington <nick.forrington@arm.com> > > >> --- > > >> tools/perf/builtin-lock.c | 25 +++++++++++++++++++++++++ > > >> 1 file changed, 25 insertions(+) > > >> > > >> diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c > > >> index 3aa8ba5ad928..cf29f648d291 100644 > > >> --- a/tools/perf/builtin-lock.c > > >> +++ b/tools/perf/builtin-lock.c > > >> @@ -2021,6 +2021,27 @@ static int check_lock_report_options(const struct option *options, > > >> return 0; > > >> } > > >> > > >> +static int check_lock_info_options(const struct option *options, > > >> + const char * const *usage) > > >> +{ > > >> + if (!info_map && !info_threads) { > > >> + pr_err("Requires one of --map or --threads\n"); > > >> + parse_options_usage(usage, options, "map", 0); > > >> + parse_options_usage(NULL, options, "threads", 0); > > >> + return -1; > > >> + > > >> + } > > >> + > > >> + if (info_map && info_threads) { > > >> + pr_err("Cannot show map and threads together\n"); > > >> + parse_options_usage(usage, options, "map", 0); > > >> + parse_options_usage(NULL, options, "threads", 0); > > >> + return -1; > > >> + } > > >> + > > >> + return 0; > > >> +} > > >> + > > >> static int check_lock_contention_options(const struct option *options, > > >> const char * const *usage) > > >> > > >> @@ -2709,6 +2730,10 @@ int cmd_lock(int argc, const char **argv) > > >> if (argc) > > >> usage_with_options(info_usage, info_options); > > >> } > > >> + > > >> + if (check_lock_info_options(info_options, info_usage) < 0) > > >> + return -1; > > >> + > > >> /* recycling report_lock_ops */ > > >> trace_handler = &report_lock_ops; > > >> rc = __cmd_report(true); > > >> -- > > >> 2.42.0 > > >> > > >>
On 08/11/2023 20:28, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 01, 2023 at 11:00:42PM -0700, Namhyung Kim escreveu: >> On Wed, Nov 1, 2023 at 7:35 AM Nick Forrington <nick.forrington@arm.com> wrote: >>> >>> On 31/10/2023 15:38, Arnaldo Carvalho de Melo wrote: >>>> Em Tue, Oct 31, 2023 at 12:05:25PM +0000, Nick Forrington escreveu: >>>>> Improve error reporting for command line arguments. >>>>> >>>>> Display error/usage if neither --map or --thread are specified (rather >>>>> than a non user-friendly error "Unknown type of information"). >>>>> >>>>> Display error/usage if both --map and --thread are specified (rather >>>>> than ignoring "--map" and displaying only thread information). >>>> Shouldn't one of them be the default so that we type less for the most >>>> common usage? >>>> >>>> - Arnaldo >>>> >>> There isn't an obvious choice (to me) for which would be the default. >>> >>> Both options display completely different data/outputs, so I think it >>> makes sense to be explicit about which data is requested. >> Maybe we can default to display both. :) > Yeah, that would be a better approach, I think. > > - Arnaldo > I'll submit an updated series for this, with the next update to patch 1/2 Thanks, Nick >> Thanks, >> Namhyung >> >>> >>> An alternative could be to use sub-commands e.g. "perf lock info >>> threads" or just "perf lock threads", although changing the existing >>> options would be more disruptive. >>> >>> >>> Cheers, >>> Nick >>> >>>>> Signed-off-by: Nick Forrington <nick.forrington@arm.com> >>>>> --- >>>>> tools/perf/builtin-lock.c | 25 +++++++++++++++++++++++++ >>>>> 1 file changed, 25 insertions(+) >>>>> >>>>> diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c >>>>> index 3aa8ba5ad928..cf29f648d291 100644 >>>>> --- a/tools/perf/builtin-lock.c >>>>> +++ b/tools/perf/builtin-lock.c >>>>> @@ -2021,6 +2021,27 @@ static int check_lock_report_options(const struct option *options, >>>>> return 0; >>>>> } >>>>> >>>>> +static int check_lock_info_options(const struct option *options, >>>>> + const char * const *usage) >>>>> +{ >>>>> + if (!info_map && !info_threads) { >>>>> + pr_err("Requires one of --map or --threads\n"); >>>>> + parse_options_usage(usage, options, "map", 0); >>>>> + parse_options_usage(NULL, options, "threads", 0); >>>>> + return -1; >>>>> + >>>>> + } >>>>> + >>>>> + if (info_map && info_threads) { >>>>> + pr_err("Cannot show map and threads together\n"); >>>>> + parse_options_usage(usage, options, "map", 0); >>>>> + parse_options_usage(NULL, options, "threads", 0); >>>>> + return -1; >>>>> + } >>>>> + >>>>> + return 0; >>>>> +} >>>>> + >>>>> static int check_lock_contention_options(const struct option *options, >>>>> const char * const *usage) >>>>> >>>>> @@ -2709,6 +2730,10 @@ int cmd_lock(int argc, const char **argv) >>>>> if (argc) >>>>> usage_with_options(info_usage, info_options); >>>>> } >>>>> + >>>>> + if (check_lock_info_options(info_options, info_usage) < 0) >>>>> + return -1; >>>>> + >>>>> /* recycling report_lock_ops */ >>>>> trace_handler = &report_lock_ops; >>>>> rc = __cmd_report(true); >>>>> -- >>>>> 2.42.0 >>>>> >>>>>
Em Mon, Nov 13, 2023 at 11:50:16AM +0000, Nick Forrington escreveu: > On 08/11/2023 20:28, Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 01, 2023 at 11:00:42PM -0700, Namhyung Kim escreveu: > > > On Wed, Nov 1, 2023 at 7:35 AM Nick Forrington <nick.forrington@arm.com> wrote: > > > > On 31/10/2023 15:38, Arnaldo Carvalho de Melo wrote: > > > > > Em Tue, Oct 31, 2023 at 12:05:25PM +0000, Nick Forrington escreveu: > > > > > > Improve error reporting for command line arguments. > > > > > > Display error/usage if neither --map or --thread are specified (rather > > > > > > than a non user-friendly error "Unknown type of information"). > > > > > > Display error/usage if both --map and --thread are specified (rather > > > > > > than ignoring "--map" and displaying only thread information). > > > > > Shouldn't one of them be the default so that we type less for the most > > > > > common usage? > > > > There isn't an obvious choice (to me) for which would be the default. > > > > Both options display completely different data/outputs, so I think it > > > > makes sense to be explicit about which data is requested. > > > Maybe we can default to display both. :) > > Yeah, that would be a better approach, I think. > I'll submit an updated series for this, with the next update to patch 1/2 Thanks, tried using b4 but it din't find a v2, will wait then. - Arnaldo
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c index 3aa8ba5ad928..cf29f648d291 100644 --- a/tools/perf/builtin-lock.c +++ b/tools/perf/builtin-lock.c @@ -2021,6 +2021,27 @@ static int check_lock_report_options(const struct option *options, return 0; } +static int check_lock_info_options(const struct option *options, + const char * const *usage) +{ + if (!info_map && !info_threads) { + pr_err("Requires one of --map or --threads\n"); + parse_options_usage(usage, options, "map", 0); + parse_options_usage(NULL, options, "threads", 0); + return -1; + + } + + if (info_map && info_threads) { + pr_err("Cannot show map and threads together\n"); + parse_options_usage(usage, options, "map", 0); + parse_options_usage(NULL, options, "threads", 0); + return -1; + } + + return 0; +} + static int check_lock_contention_options(const struct option *options, const char * const *usage) @@ -2709,6 +2730,10 @@ int cmd_lock(int argc, const char **argv) if (argc) usage_with_options(info_usage, info_options); } + + if (check_lock_info_options(info_options, info_usage) < 0) + return -1; + /* recycling report_lock_ops */ trace_handler = &report_lock_ops; rc = __cmd_report(true);