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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
