Hi Lorenzo,
Regarding your proposal of moving mseal.c to vma.c for unit testing.
On Fri, Dec 6, 2024 at 9:04 AM Lorenzo Stoakes
<lorenzo.stoakes@xxxxxxxxxx> wrote:
> > >
> > > An aside - I actually think we need to move the bulk of this code to
> > > mm/vma.c - it makes absolutely no sense to keep the internals in this file,
> > > and that way we can userland test mseal functionality.
> > >
> > Is there a past discussion to read ? That will help me understand your
> > strategy of unit testing mm code.
> > Moving everything to vma.c, will lose log history, e.g. blame no
> > longer helps, did we consider alternatives ?
>
> Re; git blame - I'm not sure what alternative you think exists, and I've
> moved brk(), mmap(), etc. with a history spanning >30 years, so I'm not
> sure what blame history you're concerned about given how recent mseal is :)
>
> There is always code that gets moved or changed. You can't stay attached to
> your name appearing on a git blame line.
>
> Re: discussion, there's dozens of discussions and patch sets totalling ~3k
> lines of code... just search lore for vma testing, or search through my
> commits in mm/vma.c and you can see.
>
> I can put together links if you really need, but I think say [0] is a good
> motivating example of how I was able to actually write unit tests for VMA
> merge functionality which previously could not exist.
>
> In any case you can use the git blame -C option to 'see through' things like
> code moves.
>
> The whole point of this is to be able to _unit_ test functionality under
> circumstances that might be otherwise improbable/incredibly difficult to
> obtain if run as part of a kernel and self testing.
>
> Importantly it allows us to conduct fuzzing testing in future, something
> key and fundamental to security testing.
>
> I would say for somebody who has clearly stated his huge commitment to
> testing and how critically vital it is especially in the security realm,
> this is entirely something that is beneficial to the kernel and to mseal
> stability and security.
>
> If you want to see it 'in action', you can run the tests in
> tools/testing/vma via:
>
> $ make && ./vma
>
I want to express my support for unit testing and agree that more
testing would benefit mm. However, I'm unsure about the reasoning
behind moving code to vma.c in bulk. Could you please clarify this for
me?
In my understanding, unit tests can be conducted regardless of the
code's location once dependencies are addressed with stubs. Have you
considered adding mseal.c to the unittest makefile at the same level
as vma.c? Since mseal.c doesn't introduce new dependencies, i.e. it
operates directly on the vm_area_struct, so I would start with that.
I guess, for UT, you might need to change some functions' signatures,
e.g. remove static, if you want to test an internal function (e.g
mseal_fixup) , from your unit-test, but this is the same even after
moving them to vma.c.
There will be additional work of clean up including header (".h"),
still I believe this is the same work even after moving the code into
vma.c. You might still need to move the prototype of some functions
into vma.h or vma_internal.h (e.g. definition of MADV_FREE). But I
think this work is also orthogonal to where the mseal business logic
is located.
I understand the logic behind the current vma.c (on the linux_main
branch) and the unit test for the VMA merge functionality. However, if
your plan is to move all VMA-related code into vma.c, that means more
stubs are needed (depending on the boundary of the proposed unit
testing), and I don't understand how moving the code can help reduce
the amount of work or stubs (if that is the motivation).
To avoid spending too much of your time, if there are previous
discussions on this topic, please share links or a brief summary, so I
can study them first.
Thanks!
Best Regards,
-Jeff
> [0]https://lore.kernel.org/linux-mm/1c7a0b43cfad2c511a6b1b52f3507696478ff51a.1725040657.git.lorenzo.stoakes@xxxxxxxxxx/
>
> Thanks, Lorenzo
