From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: jeffxu@chromium.org
Cc: akpm@linux-foundation.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org, pedro.falcato@gmail.com,
willy@infradead.org, broonie@kernel.org, vbabka@suse.cz,
Liam.Howlett@oracle.com, rientjes@google.com,
keescook@chromium.org
Subject: Re: [PATCH v3 0/5] Increase mseal test coverage
Date: Fri, 30 Aug 2024 20:17:06 +0100 [thread overview]
Message-ID: <9f2f751e-2acb-4a27-93cb-767628b38236@lucifer.local> (raw)
In-Reply-To: <20240830180237.1220027-1-jeffxu@chromium.org>
On Fri, Aug 30, 2024 at 06:02:32PM GMT, jeffxu@chromium.org wrote:
> From: Jeff Xu <jeffxu@chromium.org>
>
> This series increase the test coverage of mseal_test by:
>
> Add check for vma_size, prot, and error code for existing tests.
> Add more testcases for madvise, munmap, mmap and mremap to cover
> sealing in different scenarios.
>
> The increase test coverage hopefully help to prevent future regression.
> It doesn't change any existing mm api's semantics, i.e. it will pass on
> linux main and 6.10 branch.
This is a big improvement in detail, thanks.
>
> Note: in order to pass this test in mm-unstable, mm-unstable must have
> Liam's fix on mmap [1]
>
> [1] https://lore.kernel.org/linux-kselftest/vyllxuh5xbqmaoyl2mselebij5ox7cseekjcvl5gmzoxxwd2he@hxi4mpjanxzt/#t
This is already in mm-unstable so this is redundant, and as Liam explained,
his new v8 series will contain this fix too, and his old version will be
unwound before new applied, so at no time will this be relevant.
>
> History:
> V3:
> - no-functional change, incooperate feedback from Pedro Falcato
>
> V2:
> - https://lore.kernel.org/linux-kselftest/20240829214352.963001-1-jeffxu@chromium.org/
> - remove the mmap fix (Liam R. Howlett will fix it separately)
> - Add cover letter (Lorenzo Stoakes)
I think I asked for more than this :)
> - split the testcase for ease of review (Mark Brown)
>
> V1:
> - https://lore.kernel.org/linux-kselftest/20240828225522.684774-1-jeffxu@chromium.org/
>
>
> Jeff Xu (5):
> selftests/mseal_test: Check vma_size, prot, error code.
> selftests/mseal: add sealed madvise type
> selftests/mseal: munmap across multiple vma ranges.
> selftests/mseal: add more tests for mmap
> selftests/mseal: add more tests for mremap
>
> tools/testing/selftests/mm/mseal_test.c | 830 ++++++++++++++++++++++--
> 1 file changed, 763 insertions(+), 67 deletions(-)
>
> --
> 2.46.0.469.g59c65b2a67-goog
>
Overall having checked one patch in the series, I am quite concerned that
these tests are not testing what they suggest they do, are redundant, and I
have found numerous problems line-by-line.
I've also encountered copy/pasted blocks, comparing PROT_xxx fields to
magic numbers, and it generally feels really rushed.
I feel like it might be worth taking some time on the next respin to really
think carefully about how these functions work, checking man pages and
source, and getting some understanding of what it is we really need to
assert about mseal() behaviour.
We're here to help you and want to be collaborative and help get mseal()
into a good state, so I'd like to suggest taking your time on the next
respin to really improve the quality and think carefully in each instance
_what_ you are testing and _why_.
And don't be afraid to ask questions and discuss these things with
us. We're happy to help!
Anyway, I am now off on a long weekend before my birthday, I wish you a
great weekend and hope we can find a way to move forward constructively
with this! :)
Thanks, Lorenzo
prev parent reply other threads:[~2024-08-30 19:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 18:02 jeffxu
2024-08-30 18:02 ` [PATCH v3 1/5] selftests/mseal_test: Check vma_size, prot, error code jeffxu
2024-08-30 18:02 ` [PATCH v3 2/5] selftests/mseal: add sealed madvise type jeffxu
2024-08-30 18:02 ` [PATCH v3 3/5] selftests/mseal: munmap across multiple vma ranges jeffxu
2024-08-30 18:02 ` [PATCH v3 4/5] selftests/mseal: add more tests for mmap jeffxu
2024-08-30 18:43 ` Lorenzo Stoakes
2024-08-30 19:22 ` Lorenzo Stoakes
2024-08-30 23:57 ` Jeff Xu
2024-09-07 19:27 ` Lorenzo Stoakes
2024-09-08 21:35 ` Pedro Falcato
2024-09-08 21:56 ` Pedro Falcato
2024-09-13 23:00 ` Jeff Xu
2024-09-13 23:00 ` Jeff Xu
2024-09-13 22:50 ` Jeff Xu
2024-09-18 13:18 ` Mark Brown
2024-09-20 16:37 ` Jeff Xu
2024-10-17 18:14 ` Jeff Xu
2024-10-17 18:28 ` Lorenzo Stoakes
2024-10-17 18:47 ` Jeff Xu
2024-10-17 19:00 ` Lorenzo Stoakes
2024-10-17 19:49 ` Jeff Xu
2024-10-18 6:37 ` Lorenzo Stoakes
2024-10-18 18:01 ` Jeff Xu
2024-10-18 20:51 ` Lorenzo Stoakes
2024-10-18 13:04 ` Mark Brown
2024-10-18 18:06 ` Jeff Xu
2024-10-18 18:37 ` Mark Brown
2024-10-18 19:32 ` Jeff Xu
2024-10-18 19:52 ` Lorenzo Stoakes
2024-10-18 20:28 ` Shuah Khan
2024-10-18 20:30 ` Shuah Khan
2024-10-18 21:05 ` Mark Brown
2024-10-19 0:10 ` Jeff Xu
2024-10-21 14:59 ` Mark Brown
2024-08-30 18:02 ` [PATCH v3 5/5] selftests/mseal: add more tests for mremap jeffxu
2024-08-30 19:17 ` Lorenzo Stoakes [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=9f2f751e-2acb-4a27-93cb-767628b38236@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=jeffxu@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pedro.falcato@gmail.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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