lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131224125342.GC17780@ghostprotocols.net>
Date:	Tue, 24 Dec 2013 09:53:42 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	David Ahern <dsahern@...il.com>
Cc:	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH] perf stat: Do not show stats if workload fails

Em Mon, Dec 23, 2013 at 07:29:54PM -0500, David Ahern escreveu:
> On 12/23/13, 2:37 PM, Arnaldo Carvalho de Melo wrote:
> >int perf_evlist__start_workload(struct perf_evlist *evlist)
> >{
> >         if (evlist->workload.cork_fd > 0) {
> >                 char bf = 0;
> >                 /* Remove the cork, let it rip! */
> >                 int ret = write(evlist->workload.cork_fd, &bf, 1);
> >                 if (ret < 0)
> >                         perror("enable to write to pipe");
> >
> >                 close(evlist->workload.cork_fd);
> >                 return ret;
> >         }
> >         return 0;
> >}

> >Ret there is 1, so we need to change it to:

> >		return ret != 1 ? -1 : 0;

> >Right?
 
> Yes, nice catch.

But this doesn't really matters, if one uses the more usual:

	if (function() < 0)

pattern for error checking, there would be no problem, and we would only
be checking that we told perf_evlist__prepare_workload()'s fork branch
to call execvp, not to check what happens then, i.e. if it finds the
specified workload in the system's PATH, if there are no permission of
file format problems, etc.

The thing to check is perf_evlist__{prepare,start}_workload notification
errors using SIGUSR1, that we need to check for in the caller, and emit
the message, no?

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ