public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ian Rogers <irogers@google.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org, bpf@vger.kernel.org,
	Howard Chu <howardchu95@gmail.com>
Subject: Re: [PATCH] perf trace: Fix unaligned access for augmented args
Date: Thu, 9 Jan 2025 18:10:13 -0300	[thread overview]
Message-ID: <Z4A7NdLPeXmplTXA@x1> (raw)
In-Reply-To: <Z4AZiTNhI9qKGYh3@x1>

On Thu, Jan 09, 2025 at 03:46:33PM -0300, Arnaldo Carvalho de Melo wrote:
> On Thu, Jan 02, 2025 at 12:12:47PM -0800, Namhyung Kim wrote:
> > Some version of compilers reported unaligned accesses in perf trace when
> > undefined-behavior sanitizer is on.  I found that it uses raw data in the
> > sample directly and assuming it's properly aligned.

> > Unlike other sample fields, the raw data is not 8-byte aligned because
> > there's a size field (u32) before the actual data.  So I added a static
> > buffer in syscall__augmented_args() and return it instead.  This is not
> > ideal but should work well as perf trace is single-threaded.
 
> > A better approach would be aligning the raw data by adding a 4-byte data
> > before the augmented args but I'm afraid it'd break the backward
> > compatibility.
  
> You mean for 'perf trace record' files?
 
> Older tools will not be able to process new files, while old files will
> be remain processable by new tools if we insert a u32 with zeroes before
> the size field, that way if the first u32 is not zero, we do as you do
> below and incur the cost of copying to that intermediary buffer,
> otherwise we read the real size in the next u32 and don't incur the cost
> of copying.
 
> Your fix below works as it incurs the cost all the time, which is ok for
> now, but as a follow up patch we can see if the approach I described
> above works.
 
> Applying.

Applied, and forget about my suggestion above, as we discussed this is
not feasible, I added these notes to your patch:

   Committer testing:
    
    To build with the undefined behaviour sanitizer:
    
     $ make CC=clang EXTRA_CFLAGS=-fsanitize=undefined -C tools/perf
    
    Checking if the resulting binary is instrumented:
    
      root@number:~# nm ~/bin/perf | grep ubsan | wc -l
      113
      root@number:~# nm ~/bin/perf | grep ubsan | tail -5
      000000000043d5b0 t _ZN7__ubsanL19UBsanOnDeadlySignalEiPvS0_
      000000000043ce50 T _ZNK7__ubsan5Value12getSIntValueEv
      000000000043cf40 T _ZNK7__ubsan5Value12getUIntValueEv
      000000000043d140 T _ZNK7__ubsan5Value13getFloatValueEv
      000000000043cfd0 T _ZNK7__ubsan5Value19getPositiveIntValueEv
      root@number:~#
    
    Now running something that will access timespec, as reported in the
    Closes URL:
    
      root@number:~# perf trace --max-events=1 -e *nano* sleep 1.1
      trace/beauty/timespec.c:10:64: runtime error: member access within misaligned address 0x7fc583cfb2a4 for type 'struct augmented_arg', which requires 8 byte alignment
      0x7fc583cfb2a4: note: pointer points here
        99 99 11 00 10 00 00 00  00 00 00 00 01 00 00 00  00 00 00 00 01 e1 f5 05  00 00 00 00 00 00 00 00
                    ^
      SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior trace/beauty/timespec.c:10:64
      <SNIP>
    
    As Namhyung said we need to make the raw_data to be 64-bit aligned,
    probably we need to add a PERF_SAMPLE_ALIGNED_RAW with a 64-bit raw_size
    instead of the current u32 done at kernel/events/core.c,
    perf_output_sample(), that perf_output_put(handle, raw->size) where
    raw->size is an u32 and then the raw_data is always 64-bit unaligned...
    
    After the patch:
    
      root@number:~# perf trace -e *nano* sleep 1.1
           0.000 (1100.064 ms): sleep/1984224 clock_nanosleep(rqtp: { .tv_sec: 1, .tv_nsec: 100000001 }, rmtp: 0x7fff5b3fe970) = 0
      root@number:~#


      reply	other threads:[~2025-01-09 21:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-02 20:12 [PATCH] perf trace: Fix unaligned access for augmented args Namhyung Kim
2025-01-06  8:20 ` Howard Chu
2025-01-09 18:46 ` Arnaldo Carvalho de Melo
2025-01-09 21:10   ` Arnaldo Carvalho de Melo [this message]

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=Z4A7NdLPeXmplTXA@x1 \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=howardchu95@gmail.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /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