From: Steven Rostedt <rostedt@goodmis.org>
To: Ross Zwisler <zwisler@google.com>
Cc: Stevie Alvarez <stevie.6strings@gmail.com>,
linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH 2/5] histograms: traceeval initialize
Date: Wed, 2 Aug 2023 17:39:13 -0400 [thread overview]
Message-ID: <20230802173913.2de6686d@gandalf.local.home> (raw)
In-Reply-To: <20230802210721.GB2416079@google.com>
On Wed, 2 Aug 2023 15:07:21 -0600
Ross Zwisler <zwisler@google.com> wrote:
> > diff --git a/src/histograms.c b/src/histograms.c
> > new file mode 100644
> > index 0000000..13830e4
> > --- /dev/null
> > +++ b/src/histograms.c
> > @@ -0,0 +1,285 @@
> > +
> > +/* SPDX-License-Identifier: MIT */
> > +/*
> > + * libtraceeval histogram interface implementation.
> > + *
> > + * Copyright (C) 2023 Google Inc, Stevie Alvarez <stevie.6strings@gmail.com>
> > + */
> > +
> > +#include <histograms.h>
> > +#include <stdio.h>
> > +#include <stdbool.h>
> > +#include <string.h>
> > +#include <stdarg.h>
> > +
> > +/**
> > + * Iterate over @keys, which should be an array of struct traceeval_type's,
> > + * until reaching an instance of type TRACEEVAL_TYPE_NONE.
> > + * @i should be a declared integer type.
> > + */
> > +#define for_each_key(i, keys) \
> > + for (i = 0; (keys)[(i)].type != TRACEEVAL_TYPE_NONE; (i)++)
> > +
> > +/** A key-value pair */
> > +struct entry {
> > + union traceeval_data *keys;
> > + union traceeval_data *vals;
> > +};
> > +
> > +/** A table of key-value entries */
> > +struct hist_table {
> > + struct entry *map;
> > + size_t nr_entries;
> > +};
> > +
> > +/** Histogram */
> > +struct traceeval {
> > + struct traceeval_type *def_keys;
> > + struct traceeval_type *def_vals;
> > + struct hist_table *hist;
> > +};
>
> Should this be called something else? 'struct traceeval' is already defined
> in src/trace-analysis.c in this same codebase, and the other def is used all
> over the place in include/traceeval.h.
Yeah, we could call it something slightly different for now, but the goal
is that it will supersede the struct traceeval in trace-analysis.c, and the
code there will be removed.
We haven't hit version 1.0 yet because I hated the old API and until 1.0 is
reached, the API is allowed to change.
>
> > +
> > +/** Iterate over results of histogram */
> > +struct traceeval_iterator {}; // TODO
> > +
> > +/**
> > + * Print error message.
> > + * Additional arguments are used with respect to fmt.
> > + */
> > +static void print_err(const char *fmt, ...)
> > +{
> > + va_list ap;
> > +
> > + va_start(ap, fmt);
> > + vfprintf(stderr, fmt, ap);
> > + va_end(ap);
> > + fprintf(stderr, "\n");
> > +}
> > +
> > +// TODO
> > +int traceeval_compare(struct traceeval *orig, struct traceeval *copy)
> > +{
> > + return -1;
> > +}
> > +
> > +/**
> > + * Resize a struct traceeval_type array to a size of @size + 1.
> > + *
> > + * Returns a pointer to the resized array, or NULL if the provided pointer was
> > + * freed to due lack of memory.
> > + */
> > +static struct traceeval_type *type_realloc(struct traceeval_type *defs,
>
> Probably should have been feedback for patch 1, but 'traceeval_type' also has
> a collision. 'struct traceeval_type' is defined in include/histograms.h, and
> 'enum traceeval_type' is defined in include/libtraceeval.h.
>
> IMO even if the compiler lets us do this, we shouldn't because it'll confuse
> cscope/LSMs/grep and people reading the code.
Again, I think it may be fine, as we will eventually remove the old code.
>
> > + size_t size)
> > +{
> > + struct traceeval_type *tmp_defs = NULL;
> > + tmp_defs = realloc(defs,
> > + (size + 1) * sizeof(struct traceeval_type));
> > + if (!tmp_defs)
> > + goto fail_type_realloc;
> > + return tmp_defs;
> > +
> > +fail_type_realloc:
> > + for (int i = 0; i < size; i++) {
> > + if (defs[i].name)
> > + free(defs[i].name);
>
> Because the extra entries returned by realloc() are uninitialized, I think you
> risk trying to free 'name' values that are non-NULL but not real pointers.
>
> Should you instead try to iterate from 0 until you find an entry with type
> TRACEEVAL_TYPE_NONE? Or do you guarantee elsewhere that all 'name' pointers
> are either valid or NULL? If so, it might be good to do that initialization
> in this function so the free path makes sense in the same context and so new
> users of this function don't violate that assumption.
I believe I mentioned the same thing (or similar) in my reply.
-- Steve
>
> > + }
> > + free(defs);
> > + return NULL;
> > +}
> > +
> > +/**
> > + * Clone traceeval_type array @defs to the heap. Must be terminated with
> > + * an instance of type TRACEEVAL_TYPE_NONE.
> > + * Returns NULL if @defs is NULL, or a name is not null terminated.
>
next prev parent reply other threads:[~2023-08-02 21:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 19:04 [PATCH 1/5] histograms: initial histograms interface Stevie Alvarez
2023-07-28 19:04 ` [PATCH 2/5] histograms: traceeval initialize Stevie Alvarez
2023-07-28 22:03 ` Steven Rostedt
2023-08-02 21:07 ` Ross Zwisler
2023-08-02 21:39 ` Steven Rostedt [this message]
2023-07-28 19:04 ` [PATCH 3/5] histograms: traceeval release Stevie Alvarez
2023-07-28 22:07 ` Steven Rostedt
2023-08-02 21:54 ` Ross Zwisler
2023-08-02 22:20 ` Steven Rostedt
2023-08-02 22:21 ` Steven Rostedt
2023-07-28 19:04 ` [PATCH 4/5] histograms: traceeval compare Stevie Alvarez
2023-07-28 22:25 ` Steven Rostedt
2023-08-02 22:51 ` Ross Zwisler
2023-07-28 19:04 ` [PATCH 5/5] histograms: Add struct traceeval unit tests Stevie Alvarez
2023-07-28 22:30 ` Steven Rostedt
2023-08-03 16:27 ` Ross Zwisler
2023-07-28 20:25 ` [PATCH 1/5] histograms: initial histograms interface Steven Rostedt
2023-07-31 20:53 ` Stevie Alvarez
2023-07-31 21:04 ` Steven Rostedt
2023-08-01 19:08 ` Stevie Alvarez
2023-08-01 19:29 ` Steven Rostedt
2023-08-01 0:36 ` Ross Zwisler
2023-08-01 1:25 ` Steven Rostedt
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=20230802173913.2de6686d@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=stevie.6strings@gmail.com \
--cc=zwisler@google.com \
/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;
as well as URLs for NNTP newsgroup(s).