linux-kernel - Re: [PATCH] perf record: Delete file if a failure occurs writing the perf data file

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: <20131112153440.GZ5056@laptop.programming.kicks-ass.net>
Date:	Tue, 12 Nov 2013 16:34:40 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	David Ahern <dsahern@...il.com>
Cc:	Ingo Molnar <mingo@...nel.org>, acme@...stprotocols.net,
	linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Mike Galbraith <efault@....de>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH] perf record: Delete file if a failure occurs writing the
 perf data file

On Tue, Nov 12, 2013 at 08:25:02AM -0700, David Ahern wrote:
> On 11/12/13, 8:04 AM, Peter Zijlstra wrote:
> >On Tue, Nov 12, 2013 at 07:51:16AM -0700, David Ahern wrote:
> >>> From man mmap:
> >>>        SIGBUS Attempted access to a portion of the buffer that
> >>>        does not correspond  to  the  file (for  example, beyond
> >>>        the end of the file, ...
> >
> >SIGBUS is basically the std fail for any fault; there's a ton more
> >reasons than listed in that manpage.
> >
> >Failing to dirty a page due to -ENOSPACE is one reason we'll
> >trigger SIGBUS -- as you already found in that memcpy to mmap() instead
> >of write() patch.
> 
> Sure. Lots of mmaps flying around, so to make sure we are on the same page
> in this case we are talking about perf-report reading a file via mmap.
> 
> If the file creation (be it memcpy to mmap() or write()) has a failure due
> to lack of space, then only a partial event is in the file -- e.g.,
> perf-header only. Trying to read the rest of the event leads to perf-report
> terminating due to SIGBUS. How should that condition be handled?
> 
> The patch in this thread deletes the file. Another option is to rewind the
> file to the last known good write (ie., length after last successful call to
> write_output).

I'd report a warning and continue with all events that you could read
upto that point.
--
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/