[apparmor] [patch] regression tests: make sysctl(2) test a bit more resiliant

[Seth Arnold]

On Thu, Jul 23, 2015 at 01:45:35AM -0700, Steve Beattie wrote:
> Hello,
> 
> In testing against the 4.1 kernel, the syscall_sysctl testcase started
> failing even in the unconfined case. What the test program does is
> attempt to adjust the kernel.threads-max sysctl to be slightly larger
> and see if the operation succeeds by reading the value back out. It
> also attempts to save the original value and restore it. The test
> was failing because (in VMs at least) the default value chosen by
> the kernel for the kernel.threads-max setting was high enough that
> attempts to increase it would be ignored (likely to prevent too much
> use of kernel memory by threads), helpfully without any message being
> report to dmesg. Thus, the initial read of the current value would
> succeed, the write of that value + 1024 would appear to succeed,
> but then reading the value back out and comparing it to the expected
> value would fail, as it would still be the original value, not the
> expected new value.
> 
> This patch attempts to address this by first attempting to raise
> the value, and if that does not appear to work, to then attempt
> to lower it.  It also refactors the code a bit by creating helper
> functions to perform the actual sysctl(2) calls to make the code a
> bit easier to read.
> 
> Nominated for 2.10 and 2.9.

Acked-by: Seth Arnold <seth.arnold at canonical.com>
acked for both

A few questions inline:

>  int main(int argc, char *argv[])
>  {
>  	int save_max_threads, new_max_threads, read_new_max_threads;
> -	int name[] = {CTL_KERN, KERN_MAX_THREADS};
>  	int readonly = 0;
>  	
> +	if ((argc > 1) && strcmp(argv[1],"ro") == 0)
>  		readonly = 1;
>  
> +	if (read_max_threads(&save_max_threads) != 0)
>  		return 1;
>  
>  	/* printf("Kernel max threads (saved) is %d\n", save_max_threads); */
>  
> @@ -41,36 +64,39 @@ int main(int argc, char *argv[])
>  
>  	new_max_threads = save_max_threads + 1024;
>  
> +	if (write_max_threads(new_max_threads) != 0)
>  		return 1;
>  
> +	if (read_max_threads(&read_new_max_threads) != 0)
>  		return 1;
>  

At this point, a 'return 1' leaves the system with _probably_ higher max
threads than we started with. Is there any way for this to fail if we've
made it this far?

>  	/* printf("Kernel max threads (new) is %d\n", read_new_max_threads); */
>  
>  	if (read_new_max_threads != new_max_threads) {
> +		/* the kernel possibly rejected our updated max threads
> +		 * as being too large; try decreasing max threads. */
> +
> +		new_max_threads = save_max_threads - 1024;
> +
> +		if (write_max_threads(new_max_threads) != 0)
> +			return 1;
> +
> +		if (read_max_threads(&read_new_max_threads) != 0)
> +			return 1;

.. same here, but probably fewer max threads.

Is there any danger of max threads being between 0 and 1023 to start? It
seems unlikely, and this is test code, but I figured I'd ask.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20150723/c9b8e573/attachment.pgp>