From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 2/3] cg: validate tstring alloc/free
Date: Thu, 17 Jul 2025 00:59:05 -0400 [thread overview]
Message-ID: <aHiDGZJuyo/aKr2T@oracle.com> (raw)
In-Reply-To: <9fe85ab0-3a7d-626c-b382-0392c55e7502@oracle.com>
On Wed, Jul 16, 2025 at 08:45:19PM -0400, Eugene Loh wrote:
> On 7/16/25 20:22, Kris Van Hees wrote:
>
> > On Wed, Jul 16, 2025 at 07:07:59PM -0400, Eugene Loh wrote:
> > > I was a little concerned about this patch, but also wanted to expedite
> > > review. FWIW, testing shows
> > >
> > > test/unittest/builtinvar/tst.psinfo-bug21974606.d:
> > > test/unittest/builtinvar/tst.psinfo-bug22561297.d:
> > > test/unittest/builtinvar/tst.psinfo.d:
> > > test/unittest/builtinvar/tst.psinfo1.d:
> > > test/unittest/fbtprovider/tst.entryargs2.sh:
> > > test/unittest/funcs/copyinstr/tst.copyinstr-high-maxsize.d:
> > > test/unittest/funcs/copyinstr/tst.copyinstr-low-maxsize.d:
> > > test/unittest/funcs/copyinstr/tst.copyinstr-no-maxsize.d:
> > > test/unittest/funcs/copyinstr/tst.copyinstr.d:
> > > test/unittest/proc/tst.exec.sh:
> > > test/unittest/proc/tst.execfail.ENOENT.sh:
> > > test/unittest/proc/tst.execfail.sh:
> > > test/unittest/proc/tst.pr_psargs.d:
> > > test/unittest/proc/tst.pr_psargs_other_task.d:
> > > test/unittest/usdt/tst.argmap-typed-partial.d:
> > > test/unittest/usdt/tst.argmap-typed.d:
> > > test/unittest/variables/bvar/tst.execargs.d:
> > > test/demo/spec/specopen.d:
> > >
> > > test/unittest/dif/bcopy.d:
> > >
> > > failing on every VM. (Well, bcopy is listed separately since we skip it on
> > > ARM.) I'll try to put together a patch, but let me know if you already knew
> > > about this and have a fix.
> > I am looking into it as well. Clearly, this patch is catching issues as
> > expected.
>
> I guess, but those issues should be fixed before the patch is applied? I'll
> move onto something else unless you think it's a good idea for two of us to
> be looking at this at once. I do not understand, though, why we check if
> dnp->dn_kind is DT_NODE_FUNC or DT_NODE_OP1 or DT_NODE_OP2 or DT_NODE_OP3 or
> DT_NODE_DEXPR.
They are being fixed before it is applied. In fact, all but 1 are now fixed.
Patch comes tomorrow sometim after I am not overheating anymore.
next prev parent reply other threads:[~2025-07-17 4:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 19:50 [PATCH 2/3] cg: validate tstring alloc/free Kris Van Hees
2025-07-16 4:45 ` Eugene Loh
2025-07-16 23:07 ` Eugene Loh
2025-07-17 0:22 ` Kris Van Hees
2025-07-17 0:45 ` Eugene Loh
2025-07-17 4:59 ` Kris Van Hees [this message]
2025-07-17 18:20 ` Kris Van Hees
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=aHiDGZJuyo/aKr2T@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=eugene.loh@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.