From: Petr Mladek <pmladek@suse.com>
To: "Tobin C. Harding" <me@tobin.cc>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Theodore Ts'o <tytso@mit.edu>, Kees Cook <keescook@chromium.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Tycho Andersen <tycho@docker.com>,
"Roberts, William C" <william.c.roberts@intel.com>,
Tejun Heo <tj@kernel.org>,
Jordan Glover <Golden_Miller83@protonmail.ch>,
Greg KH <gregkh@linuxfoundation.org>,
Joe Perches <joe@perches.com>, Ian Campbell <ijc@hellion.org.uk>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <wilal.deacon@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Chris Fries <cfries@google.com>,
Dave Weinstein <olorin@google.com>,
Daniel Micay <danielmicay@gmail.com>,
Djalal Haroun
Subject: Re: [PATCH 4/7] scripts/leaking_addresses: add reporting
Date: Wed, 8 Nov 2017 11:42:21 +0100 [thread overview]
Message-ID: <20171108104221.GH2652@pathway.suse.cz> (raw)
In-Reply-To: <1510112259-11572-5-git-send-email-me@tobin.cc>
On Wed 2017-11-08 14:37:36, Tobin C. Harding wrote:
> Currently script just dumps all results found. Potentially, this risks
> loosing single results among multiple duplicate results. We need some
> way of restricting duplicates to assist users of the script. It would
> also be nice if we got a report instead of raw results.
>
> Duplicates can be defined in various ways, instead of trying to find a
> single perfect solution we can present the user with various options to
> display the output. Doing so will typically lead to users wanting to
> view the output multiple times. Currently we scan the kernel each time,
> this is slow and unnecessary. We can expedite the process by writing the
> results to file for subsequent viewing.
>
> Add sub-commands `scan` and `format`. Display output as a report instead
> of raw results. Add --raw flag to view raw results. Save results to
> file. For subsequent calls to `format` parse output file instead of
> re-scanning.
>
> Signed-off-by: Tobin C. Harding <me@tobin.cc>
> ---
> scripts/leaking_addresses.pl | 201 ++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 187 insertions(+), 14 deletions(-)
>
> diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
> index 719ed0aaede7..4c31e935319b 100755
> --- a/scripts/leaking_addresses.pl
> +++ b/scripts/leaking_addresses.pl
> @@ -21,14 +21,19 @@ use File::Spec;
> use Cwd 'abs_path';
> use Term::ANSIColor qw(:constants);
> use Getopt::Long qw(:config no_auto_abbrev);
> +use File::Spec::Functions 'catfile';
>
> my $P = $0;
> my $V = '0.01';
>
> -# Directories to scan.
> +# Directories to scan (we scan `dmesg` also).
> my @DIRS = ('/proc', '/sys');
>
> # Command line options.
> +my $output = "scan.out";
The hard-coded filename and its use is dangerous. Nobody expects that
this kind of script writes/re-writes a file on the system.
> +my $suppress_dmesg = 0;
> +my $squash_by_path = 0;
> +my $raw = 0;
> my $help = 0;
> my $debug = 0;
>
> @@ -70,21 +75,34 @@ sub help
> my ($exitcode) = @_;
>
> print << "EOM";
> -Usage: $P [OPTIONS]
> +
> +Usage: $P COMMAND [OPTIONS]
> Version: $V
>
> +Commands:
> +
> + scan Scan the kernel (savesg raw results to file and runs `format`).
> + format Parse results file and format output.
The later formatting/filtering might be useful but the use
of the hard coded file is strange. Also it is pity that
the script does not do anything useful out of box.
I suggest to remove the commands and do the scan out of box.
It should not store anything on the disk by default.
Then we could define following options:
-o, --output=<file> Store raw results into file for later formatting.
-i, --input=<file> Read raw result from file and just format them.
Well, it is still somehow non-intuitive. It might help to
be more explicit:
-o, --output-raw=<file>
-i, --input-raw=<file>
> Options:
>
> - -d, --debug Display debugging output.
> - -h, --help, --version Display this help and exit.
> + -o, --output=<file> Raw results output file, used for later formatting.
> + --suppress-dmesg Do not show dmesg results.
> + --squash-by-path Show one result per unique path.
I would personally add also option for the default mode:
--squash-by-filename Show one result per unique filename
(default).
In fact, I would personally use --squash-by-path or even --raw by
default. These provide easy to understand output. While the
--squash-by-filename mode has pretty good results but
it is quite non-intuitive.
Best Regards,
Petr
next prev parent reply other threads:[~2017-11-08 10:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 3:37 [PATCH 0/7] scripts/leaking_addresses: add summary report Tobin C. Harding
2017-11-08 3:37 ` [PATCH 1/7] scripts/leaking_addresses: use tabs not spaces Tobin C. Harding
2017-11-08 3:37 ` [PATCH 2/7] scripts/leaking_addresses: remove dead code Tobin C. Harding
2017-11-08 3:37 ` [PATCH 3/7] scripts/leaking_addresses: remove command line options Tobin C. Harding
2017-11-08 3:37 ` [PATCH 4/7] scripts/leaking_addresses: add reporting Tobin C. Harding
2017-11-08 10:42 ` Petr Mladek [this message]
2017-11-09 0:51 ` Tobin C. Harding
2017-11-08 3:37 ` [PATCH 5/7] scripts/leaking_addresses: add emailing results Tobin C. Harding
2017-11-08 10:16 ` Petr Mladek
2017-11-08 11:51 ` Greg KH
2017-11-09 0:58 ` Tobin C. Harding
2017-11-08 3:37 ` [PATCH 6/7] scripts/leaking_addresses: fix comment typo Tobin C. Harding
2017-11-08 3:37 ` [PATCH 7/7] scripts/leaking_addresses: don't parse usbmon Tobin C. Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171108104221.GH2652@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=Golden_Miller83@protonmail.ch \
--cc=Jason@zx2c4.com \
--cc=catalin.marinas@arm.com \
--cc=cfries@google.com \
--cc=danielmicay@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=ijc@hellion.org.uk \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=me@tobin.cc \
--cc=olorin@google.com \
--cc=pbonzini@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tycho@docker.com \
--cc=tytso@mit.edu \
--cc=wilal.deacon@arm.com \
--cc=william.c.roberts@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).