On 11/8/13, 2:34 AM, Jiri Olsa wrote:
>> +	if (ftruncate(fd, len) != 0)
>> +		pr_err("ftruncate failed\n");
>
> I think we should fail here and dont let the finishing
> code run on probably corrupted file.
>
> the code that process build IDs could even get stuck

Yes, I'll fix that in v5.

It also got me to thinking about failure scenarios -- like out of space. 
I was looking at this path using a size-limited tmpfs (max 1M) and 
writing perf.data into it.

Today (without this mmap output page) if the write() fails due to lack 
of space then perf emits the message:
   failed to write perf data, error: No space left on device

and stops — killing the workload too. Trying to read and process the 
perf.data file fails with a SIGBUS error.  I just sent a patch this 
addresses that problem.

Using that patch as a start point and moving to mmap-based output if the 
filesystem runs out of space the memcpy generates a SIGBUS and we need 
to jump out of the memcpy. The attached fixes that problem.

Any objections to using a sigjmp? Other option is to die in the signal 
handler.  That option is harder to clean up.

David