Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1227873

Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses for 32-bit traces

From Steven Rostedt <rostedt@goodmis.org>
Newsgroups linux.kernel
Subject Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses for 32-bit traces
Date 2015-09-18 15:50 +0200
Message-ID <qa4d4-4d9-9@gated-at.bofh.it> (permalink)
References <q9Fom-1Tl-15@gated-at.bofh.it> <q9Hgt-4Dp-1@gated-at.bofh.it> <q9IPg-6Ov-27@gated-at.bofh.it> <q9Jii-7CU-3@gated-at.bofh.it> <qa1yz-or-33@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, 18 Sep 2015 11:55:47 +0100
Kapileshwar Singh <kapileshwar.singh@arm.com> wrote:

> >>> Perhaps we need to make addr into a unsigned long long, and then add:
> >>>
> >>>       addr = (pevent->long_size == 8) ?
> >>>               *(unsigned long long *)(data + field->offset) :
> >>>               (unsigned long long )*(unsigned int *)(data + field->offset);
> > 
> > What about this? (untested)
> > 
> >     addr = *(uint64_t *)(data + field->offset) &
> >                         ((1ULL << pevent->long_size * 8) - 1);
> 
> I tested this and it works fine.

Except that I think it may be buggy.

> 
> > 
> > Do we also need to consider byte endians?  Maybe it'd be better adding
> > a helper to dereference pointers then..

Yes and no.

> 
> In this particular case, since the address is just a key for a lookup into the 
> printk_map, which seems like a (addr -> const char *) mapping for string 
> literals in the trace file, the endian-ness should not matter (I could be wrong though).

Correct, which is why I said "no", BUT! this is why I think Namhyung's
version may be buggy (besides the overflow of the buffer).

If this is a 64 bit big endian reading a 32 bit little endian file, I
think the result will be incorrect.

The *(uint64_t *) will return a 64bit number, but the address (with
long_size == 4) only needs 32bits. Thus, we are getting 32 more bits
than needed. Let's say the address is 0x12345678 that is loaded in the
file. Being little endian, it would be loaded as "78 56 34 12". Let's
say the 32bits after that is 0xDEADBEEF, loaded as "EF BE AD DE". Now
the number returned to addr (being a 64 bit big endian) would be:
0x785643412EFBEADDE  But then we do the shift:

 (1ULL << pevent->long_size * 8) - 1; which would leave us with:

0xEFBEADDE

Not what we wanted.

My version only reads the necessary bytes, and also wont suffer from
reading past the data size of the buffer (which is another bug).

-- Steve



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] tools lib traceevent: Mask higher bits of str addresses for 32-bit traces Kapileshwar Singh <kapileshwar.singh@arm.com> - 2015-09-17 13:20 +0200
  Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses  for 32-bit traces Steven Rostedt <rostedt@goodmis.org> - 2015-09-17 15:20 +0200
    Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses  for 32-bit traces Kapileshwar Singh <kapileshwar.singh@arm.com> - 2015-09-17 17:00 +0200
      Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses  for 32-bit traces Namhyung Kim <namhyung@kernel.org> - 2015-09-17 17:30 +0200
        Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses  for 32-bit traces Kapileshwar Singh <kapileshwar.singh@arm.com> - 2015-09-18 13:00 +0200
          Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses  for 32-bit traces Steven Rostedt <rostedt@goodmis.org> - 2015-09-18 15:50 +0200
            Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses  for 32-bit traces Kapileshwar Singh <kapileshwar.singh@arm.com> - 2015-09-18 16:30 +0200

csiph-web