Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 10 Nov 2020 11:08:48 +0100
From:   Jiri Olsa <jolsa@redhat.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Jiri Olsa <jolsa@kernel.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Namhyung Kim <namhyung@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Michael Petlan <mpetlan@redhat.com>,
        Song Liu <songliubraving@fb.com>,
        Ian Rogers <irogers@google.com>,
        Stephane Eranian <eranian@google.com>,
        Alexey Budankov <alexey.budankov@linux.intel.com>,
        Andi Kleen <ak@linux.intel.com>,
        Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH 03/24] perf: Add build id data in mmap2 event
Message-ID: <20201110100848.GB387652@krava>
References: <20201109215415.400153-1-jolsa@kernel.org>
 <20201109215415.400153-4-jolsa@kernel.org>
 <20201110080716.GU2594@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201110080716.GU2594@hirez.programming.kicks-ass.net>
Precedence: bulk

On Tue, Nov 10, 2020 at 09:07:16AM +0100, Peter Zijlstra wrote:
> On Mon, Nov 09, 2020 at 10:53:54PM +0100, Jiri Olsa wrote:
> > Adding support to carry build id data in mmap2 event.
> > 
> > The build id data replaces maj/min/ino/ino_generation
> > fields, whichc are also used to identify map's binary,
> > so it's ok to replace them with build id data:
> > 
> >   union {
> >           struct {
> >                   u32       maj;
> >                   u32       min;
> >                   u64       ino;
> >                   u64       ino_generation;
> >           };
> >           struct {
> >                   u8        build_id[20];
> >                   u8        build_id_size;
> 
> What's the purpose of a size field for a fixed size array? Also, I'd

at the moment there's SHA build id using 20 bytes and MD5 is using 16
bytes, so build_id_size tells which one is in

I was considering adding another enum instead, but buildid is defined
just by the size of the hash, so size seemed better.. if in future
there's another type added and fits within 20 bytes we're ok, if it's
bigger we're screwed anyway

> flip the order of these fields, first have the size and then the array.

ok

jirka

> 
> >                   u8        __reserved_1;
> >                   u16       __reserved_2;
> >           };
> >   };
> > 
> > Replaced maj/min/ino/ino_generation fields give us size
> > of 24 bytes. We use 20 bytes for build id data, 1 byte
> > for size and rest is unused.
>