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
| ||
|
Date: Fri, 15 Jan 2016 16:49:13 -0300 From: Arnaldo Carvalho de Melo <acme@...nel.org> To: Stephane Eranian <eranian@...gle.com> Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Namhyung Kim <namhyung@...il.com>, LKML <linux-kernel@...r.kernel.org>, Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>, "ak@...ux.intel.com" <ak@...ux.intel.com> Subject: Re: [RFC] perf record: missing buildid for callstack modules Em Fri, Jan 15, 2016 at 10:58:48AM -0800, Stephane Eranian escreveu: > On Fri, Jan 15, 2016 at 1:34 AM, Peter Zijlstra <peterz@...radead.org> wrote: > > On Thu, Jan 14, 2016 at 05:59:48PM -0800, Stephane Eranian wrote: > >> Peter, > >> > >> On Thu, Jan 14, 2016 at 3:36 AM, Peter Zijlstra <peterz@...radead.org> wrote: > >> > On Thu, Jan 14, 2016 at 12:27:34PM +0100, Ingo Molnar wrote: > >> >> > + * u32 filename_len; > >> >> > + * char filename[2+]; > >> > > >> >> Acked-by: Ingo Molnar <mingo@...nel.org> > >> > > >> > except of course that sizeof(u32) == 4 :/ > > > >> There is no padding here. Are you concerned about running out of bits > >> in filename_len? > > > > No, I just made a mess of it :-) > > > > filename_len should have been u16 and filename should then be 6+8n in > > size. > > > why don't you make it more explicit: > u16 filename_len > u16 extra_len > then it would be clear what is what, no field with dual meaning. > Now, that assumes that no pathname can be longer than 65535 bytes. There is no requirement for the filename to start at a u64 boundary, right? So it can start right after the filename_len, be it u16 or u32, and that extra_len can be computed as Peter described right here: > >> Any extension possible because header.size - sizeof(mmap3) - > >> filename_len sizing what's after filename, right? So, no need to have that extra_len :-) Ah PATH_MAX is 4096, so I guess u16 should be enough, no? - Arnaldo > > Right, current MMAP records use the remaining size as the filename > > length, but by explicitly specifying that we can add optional fields. > > > > These fields must be after filename_len, otherwise you'd not be able to > > find filename_len and you could not compute the extra size. And given > > alignment constraints it makes sense to do it after filename[]. > > > > So suppose we wanted to also add atime and ctime, we could do. > > > > PERF_RECORD_MMAP3 { > > ... > > u16 filename_len; > > char filename[6+8n]; > > > > if (extra_size >= 16) { > > u64 stime; > > u64 ctime; > > }; > > } > > > > or something like that.
Powered by blists - more mailing lists