On Wed, 14 Oct 2020 11:35:17 -0400 Steven Rostedt <[email protected]> wrote:
> On Thu, 15 Oct 2020 00:11:04 +0900 > Masami Hiramatsu <[email protected]> wrote: > > > On Wed, 14 Oct 2020 09:38:13 -0400 > > Steven Rostedt <[email protected]> wrote: > > > > > > Hmm, would you mean we always run such conversion on printing the trace > > buffer for each entry? It could be much overhead because we need allocate > > memory (%p->%px increase 1 byte) and format conversion (with copying it). > > I was thinking of having a single buffer allocated to the iterator (could > increase in size when needed). Really, the output isn't that time critical, > and running a conversion on all events each time shouldn't be that bad. And > if it is, we could have a cache in the iter for a set of events to handle. > Note, the conversion only needs to happen for events that have a %p in the > fmt, and only those need to be cached. > > Then those buffers could be freed when the iter is freed. Ah, I got it. so you meant adding a buffer field to struct trace_iterator, correct? > > > Maybe we can avoid repeating it using a kind of cache, but it also consumes > > memory. And as I pointed, the security reason is meaningless because there > > are raw addresses in raw data which user can read... > > Could you tell me what is your point? Making the code change as small as > > possible? > > > > It's about not having to worry about this in the future. Otherwise, we'll > be playing whack-a-mole on making all %px in new trace events. Hmm, OK. I hope no one adds an event which shows both ptr and hashed ptr for making a database in the future ;) Let me try to re-implement it. Thank you, -- Masami Hiramatsu <[email protected]>
