[LTP] [PATCH v2 8/8] Rewrite userns08.c using new LTP API

[Andrea Cervesato]

Hi Petr,

I can check it, but it will probably take some time because I'm not 
familiar with that particular scenario. Can we go ahead with the 
patch-set anyway?

Andrea

On 3/23/22 13:54, Petr Vorel wrote:
>> Hi!
>>> ./userns08 -i50
>>> tst_kconfig.c:82: TINFO: Parsing kernel config '/proc/config.gz'
>>> tst_test.c:1456: TINFO: Timeout per run is 0h 05m 00s
>>> userns08.c:65: TPASS: Denied write access to ./restricted : EACCES (13)
>>> userns08.c:65: TPASS: Denied write access to ./restricted : EACCES (13)
>>> userns08.c:65: TPASS: Denied write access to ./restricted : EACCES (13)
>>> userns08.c:65: TPASS: Denied write access to ./restricted : EACCES (13)
>>> userns08.c:65: TPASS: Denied write access to ./restricted : EACCES (13)
>>> userns08.c:36: TBROK: clone3 failed: ENOSPC (28)
>>> Something needs to be closed after each run.
>> ENOSPC means that we created too many user namespaces. The problem is
>> likely that we are creating the namespaces faster than they are being
>> asynchronously cleaned up in the kernel. Adding sleep(1) to the
>> clone_newuser() function gives kernel enough time to clean the
>> namespaces and the test works with any -i. Also note that we get the
>> exact same failure if we execute the test a few times in a row, i.e.
>> for i in `seq 10`; do
>> 	./userns08
>> done
> +1
>
>> The original test fails in the same way, so while it should be fixed,
>> it's not really reason to block this patchset.
> Agree (I forget to write I suspected the problem wasn't new in this patchset).
>
>> And the only correct fix would be retrying the clone() on ENOSPC in the
>> SAFE_CLONE().
> +1. I suppose Andrea will have look into it (otherwise I'll do it).
>
> Kind regards,
> Petr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220323/8a81b865/attachment-0001.htm>