[LTP] [PATCH v3 1/2] API/cgroup: Expose memory_recursiveprot V2 mount opt

[Li Wang]

On Mon, Feb 28, 2022 at 5:59 PM Richard Palethorpe <rpalethorpe@suse.de>
wrote:

> Hello Michal,
>
> Michal Koutný <mkoutny@suse.com> writes:
>
> > On Tue, Feb 22, 2022 at 12:45:46PM +0000, Richard Palethorpe <
> rpalethorpe@suse.com> wrote:
> >> This changes the effect of trunk nodes' memory.low and memory.min on
> >> their leaf nodes. So we need to change the expectations of some tests.
> >
> > How much are LTP runs striving to not affect environment?
>
> As a general rule we try to leave the environment as we found it so that
> testing is more deterministic. For the CGroup testing in particular I
> decided not to change anything so that we do not have to worry about how
> the init system will react.
>

+1

>
> > IIRC, the memory_recursiveprot is "remountable"; in the long-term it's
> > likely worth watching the memory_recursiveprot behavior only.
> >
> > I.e. instead of carrying two sets of expectations you can warp the
> > environment for the set that's more likely.
> >
> > Michal
>
> Thinking about it, the reason why I was testing without
> memory_recursiveprot is because I'm just direct booting the kernel with
> bash as init and running the test. So the LTP is mounting the CGroups
> and it should mount with memory_recursiveprot, but it is not.
>
> Probably we have to support older products as well which don't have
> memory_recursiveprot enabled and are using V2 (unlikely I guess, but it
> is safest to assume this is the case). So we can still run the test, but
> report CONF instead of PASS/FAIL. This way we will at least still catch
> kernel warnings and panics.
>

This sounds reasonable at least to me.

Reviewed-by: Li Wang <liwang@redhat.com>

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220301/e4553aa4/attachment.htm>