From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Jonas Rebmann <jre@pengutronix.de>, Kees Cook <kees@kernel.org>,
Andy Shevchenko <andy@kernel.org>,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de,
Brendan Higgins <brendan.higgins@linux.dev>,
David Gow <david@davidgow.net>, Rae Moar <raemoar63@gmail.com>
Subject: Re: [PATCH 0/5] lib/string_helpers: fixes and test cases for string_unescape()
Date: Wed, 16 Sep 2026 17:04:47 -0700 [thread overview]
Message-ID: <20260916170447.f8b7df928c7f8b6841adec0f@linux-foundation.org> (raw)
In-Reply-To: <20260916231336.GA2777429@google.com>
On Wed, 16 Sep 2026 23:13:36 +0000 Eric Biggers <ebiggers@kernel.org> wrote:
> On Wed, Sep 16, 2026 at 02:36:23PM -0700, Andrew Morton wrote:
> > On Wed, 16 Sep 2026 19:38:05 +0200 Jonas Rebmann <jre@pengutronix.de> wrote:
> >
> > > This series fixes two bugs in string_unescape() regarding the
> > > destination buffer length. Both fixes are accompanied with kunit tests
> > > which would fail without the fixes.
> > >
> > > To make this possible, preparatory patches 1 and 2 improve and clean up
> > > testing helpers and 3 introduces test_unescape_one() which allows for
> > > targeted testing of the string_unescape() function.
> >
> > Sashiko complains about uncheched kunit_kzalloc() return val.
> >
> > https://sashiko.dev/#/patchset/20260916-string_unescape-v1-0-7f8bd986fa33@pengutronix.de
> >
> > I wonder whether we really need the usual allocation-failure semantics
> > in kunit. Can we just make the kunit memory allocation functions abort
> > on error?
>
> FWIW, having KUNIT_ASSERT_NOT_NULL built-in to kunit_kmalloc() et al
> sounds good to me. It's not clear to me why it wasn't done that way.
> Maybe so that assertion failures show the correct file and line number?
> But that can be solved by making them macros.
>
> As-is, every test has to check for NULL, which is unnecessary
> boilerplate. It's also resulted in test-specific wrapper functions that
> work around this, like alloc_buf() in lib/crypto/tests/test-utils.h.
>
> If a fallible version is needed in rare cases, it could be underscored:
> __kunit_kmalloc(). But I'm not sure any test needs that.
Sure.
Simply doing kthread_exit() when we're in the middle of something is
rather rude - it'll leak things. I doubt if anyone cares about that much
if they're engaged in poking around with kunit tests. otoh, small GFP_KERNEL
allocation failures are close to can't-happen.
One thought is to create a fake struct device in kunit, use
devm_kzalloc everywhere then get kunit_try_catch_throw() to release the
device. Reuse the devm_ code's tracking and garbage-collecting
infrastructure. But it just isn't worthwhile. Make the kunit layer
say "ha ha, you lost some memory" and leave it at that...
prev parent reply other threads:[~2026-09-17 0:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 17:38 Jonas Rebmann
2026-09-16 17:38 ` [PATCH 1/5] lib/tests: string_helpers: check null terminator too Jonas Rebmann
2026-09-17 7:14 ` Andy Shevchenko
2026-09-17 8:58 ` Jonas Rebmann
2026-09-17 9:07 ` Andy Shevchenko
2026-09-16 17:38 ` [PATCH 2/5] lib/tests: string_helpers: drop unused parameters Jonas Rebmann
2026-09-17 7:18 ` Andy Shevchenko
2026-09-17 8:58 ` Jonas Rebmann
2026-09-16 17:38 ` [PATCH 3/5] lib/tests: string_helpers: introduce test_string_unescape_one Jonas Rebmann
2026-09-17 7:21 ` Andy Shevchenko
2026-09-17 8:58 ` Jonas Rebmann
2026-09-17 9:08 ` Andy Shevchenko
2026-09-17 9:56 ` Jonas Rebmann
2026-09-17 12:17 ` Andy Shevchenko
2026-09-16 17:38 ` [PATCH 4/5] lib/string_helpers: use full destination buffer in string_unescape() Jonas Rebmann
2026-09-17 7:45 ` Andy Shevchenko
2026-09-17 9:02 ` Jonas Rebmann
2026-09-16 17:38 ` [PATCH 5/5] lib/string_helpers: fix counting of remaining bytes " Jonas Rebmann
2026-09-17 8:04 ` Andy Shevchenko
2026-09-16 21:36 ` [PATCH 0/5] lib/string_helpers: fixes and test cases for string_unescape() Andrew Morton
2026-09-16 23:13 ` Eric Biggers
2026-09-17 0:04 ` Andrew Morton [this message]
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=20260916170447.f8b7df928c7f8b6841adec0f@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andy@kernel.org \
--cc=brendan.higgins@linux.dev \
--cc=david@davidgow.net \
--cc=ebiggers@kernel.org \
--cc=jre@pengutronix.de \
--cc=kees@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=raemoar63@gmail.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
all inboxes | Powered by JetHome®