From: Kees Cook <kees@kernel.org>
To: Tiffany Yang <ynaffit@google.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@android.com,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Christian Brauner" <brauner@kernel.org>,
"Carlos Llamas" <cmllamas@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Brendan Higgins" <brendan.higgins@linux.dev>,
"David Gow" <davidgow@google.com>, "Rae Moar" <rmoar@google.com>,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com
Subject: Re: [PATCH v4 6/6] binder: encapsulate individual alloc test cases
Date: Wed, 16 Jul 2025 23:32:10 -0700 [thread overview]
Message-ID: <202507162326.5A827E93C@keescook> (raw)
In-Reply-To: <20250717011011.3365074-7-ynaffit@google.com>
On Wed, Jul 16, 2025 at 06:10:09PM -0700, Tiffany Yang wrote:
> Each case tested by the binder allocator test is defined by 3 parameters:
> the end alignment type of each requested buffer allocation, whether those
> buffers share the front or back pages of the allotted address space, and
> the order in which those buffers should be released. The alignment type
> represents how a binder buffer may be laid out within or across page
> boundaries and relative to other buffers, and it's used along with
> whether the buffers cover part (sharing the front pages) of or all
> (sharing the back pages) of the vma to calculate the sizes passed into
> each test.
>
> binder_alloc_test_alloc recursively generates each possible arrangement
> of alignment types and then tests that the binder_alloc code tracks pages
> correctly when those buffers are allocated and then freed in every
> possible order at both ends of the address space. While they provide
> comprehensive coverage, they are poor candidates to be represented as
> KUnit test cases, which must be statically enumerated. For 5 buffers and
> 5 end alignment types, the test case array would have 750,000 entries.
> This change structures the recursive calls into meaningful test cases so
> that failures are easier to interpret.
>
> Cc: Kees Cook <kees@kernel.org>
> Acked-by: Carlos Llamas <cmllamas@google.com>
> Signed-off-by: Tiffany Yang <ynaffit@google.com>
> [...]
> +struct binder_alloc_test_case_info {
> + char alignments[ALIGNMENTS_BUFLEN];
> + struct seq_buf alignments_sb;
This really screams for a struct-based way to in-place declare a
seq_buf. The current macro only works on the stack. I think this
will work; I'll send a patch once I get it tested:
#define DECLARE_SEQ_BUF(NAME, SIZE) \
char NAME##_buffer[size]; \
struct seq_buf NAME = { \
.buffer = &NAME##_buffer, \
.size = SIZE, \
}
But yes, this and the seq_buf_init below is correct.
Reviewed-by: Kees Cook <kees@kernel.org>
--
Kees Cook
next prev parent reply other threads:[~2025-07-17 6:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 1:10 [PATCH v4 0/6] binder: Set up KUnit tests for alloc Tiffany Yang
2025-07-17 1:10 ` [PATCH v4 1/6] binder: Fix selftest page indexing Tiffany Yang
2025-07-17 6:23 ` Kees Cook
2025-07-17 1:10 ` [PATCH v4 2/6] binder: Store lru freelist in binder_alloc Tiffany Yang
2025-07-17 6:23 ` Kees Cook
2025-07-17 1:10 ` [PATCH v4 3/6] kunit: test: Export kunit_attach_mm() Tiffany Yang
2025-07-17 1:10 ` [PATCH v4 4/6] binder: Scaffolding for binder_alloc KUnit tests Tiffany Yang
2025-07-17 1:10 ` [PATCH v4 5/6] binder: Convert binder_alloc selftests to KUnit Tiffany Yang
2025-07-17 6:33 ` Kees Cook
2025-07-17 1:10 ` [PATCH v4 6/6] binder: encapsulate individual alloc test cases Tiffany Yang
2025-07-17 6:32 ` Kees Cook [this message]
2025-07-17 7:34 ` Kees Cook
2025-07-17 14:41 ` [PATCH v4 0/6] binder: Set up KUnit tests for alloc Greg Kroah-Hartman
2025-07-21 16:22 ` Joel Fernandes
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=202507162326.5A827E93C@keescook \
--to=kees@kernel.org \
--cc=arve@android.com \
--cc=brauner@kernel.org \
--cc=brendan.higgins@linux.dev \
--cc=cmllamas@google.com \
--cc=davidgow@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=joelagnelf@nvidia.com \
--cc=kernel-team@android.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maco@android.com \
--cc=rmoar@google.com \
--cc=surenb@google.com \
--cc=tkjos@android.com \
--cc=ynaffit@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 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.