On Mon, Mar 21, 2022 at 7:15 PM Roman Gushchin <roman.gushchin@xxxxxxxxx> wrote: > > > > On Mar 21, 2022, at 5:13 PM, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Sun, Mar 20, 2022 at 9:58 AM Roman Gushchin <roman.gushchin@xxxxxxxxx> wrote: > >> > >> > >>>> On Mar 19, 2022, at 11:08 PM, Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > >>> > >>> Since we have alread switched to memcg-based memory accouting and control, > >>> we don't need RLIMIT_MEMLOCK any more. > >>> > >>> Signed-off-by: Yafang Shao <laoar.shao@xxxxxxxxx> > >>> Cc: Roman Gushchin <roman.gushchin@xxxxxxxxx> > >>> > >>> --- > >>> RLIMIT_MEMLOCK is still used in bpftool and libbpf, but it may be useful > >>> for backward compatibility, so I don't cleanup them. > >> > >> Hi Yafang! > >> > >> As I remember, we haven’t cleaned selftests up with the same logic: it’s nice to be able to run the same version of tests on older kernels. > >> > > > > It should be fine, at least for test_progs and test_progs-no_alu32. > > Libbpf now does this automatically if running in "libbpf 1.0" mode. > > Didn’t know this, thanks! Do we link all tests with it? Yep, every selftest inevitably relies on libbpf. We just need to make sure to enable that 1.0 mode with libbpf_set_strict_mode() call. > > > > > Yafang, please make sure that all the test binaries you are cleaning > > up have libbpf_set_strict_mode(LIBBPF_STRICT_ALL) (test_progs does > > already). You might need to clean up some SEC() definitions, in case > > we still missed some non-conforming ones, though. > > If so, no objections to the patch from my side. > > Thank you!
