On Sat, May 23, 2020 at 12:32 PM Jamal Hadi Salim <j...@mojatatu.com> wrote:
>
> On 2020-05-22 9:33 p.m., Daniel Borkmann wrote:
> > On 5/18/20 3:00 PM, Jamal Hadi Salim wrote:
> >> ping?
> >>
> >> Note: these are trivial bug fixes.
> >
> > Looking at c0325b06382c ("bpf: replace snprintf with asprintf when
> > dealing with long buffers"),
> > I wonder whether it's best to just revert and redo cleanly from
> > scratch.. How much testing has
> > been performed on the original patch? We know it is causing regressions,
> > and looking Jamal's
> > 2nd patch we do have patterns all over the place wrt error path that go
> > like:
>
> Reverting c0325b06382c would work as well..
>
> Note: I believe Andrea's original goal was to just get rid of a
> compiler warning from sprintf(). Stephen suggested to use
> asprintf. Andrea's original solution to get rid of the compiler
> warning would suffice. Maybe then an additional code audit to
> ensure consistency on usage of s[n]printf could be done and
> resolved separately.
>Reverting c0325b06382c will for sure fix the segfault identified by Jamal and get rid of the problems highlighted by Daniel and others. To fix the s[n]printf truncation warning we can simply check for its return value. From the snprintf man page: "a return value of size or more means that the output was truncated." (caveat: until glibc 2.0.6 ret value for truncation is -1) Jamal: if this works for you, I can submit an alternative to this patch series doing what I proposed above. What do you think? Regards, Andrea > Thanks for taking the time Daniel. > > cheers, > jamal >
