[PATCH] close_range: fd and max_fd are unsigned

[Dmitry V. Levin]

Hi,

On Thu, Mar 25, 2021 at 03:55:54AM +0000, Alyssa Ross wrote:
> The distinction is important, because close_range(2) says that having
> max_fd < fd is an error, but if you give the kernel 1U + INT_MAX as
> max_fd, it'll interpret it as unsigned.
> 
> Since we're working with ranges of file descriptors here, the
> particular properties of only the start and end file descriptors
> aren't really relevant, so it doesn't matter that we're losing fancy
> file descriptor printing in making this change.
> 
> Signed-off-by: Alyssa Ross <hi at alyssa.is>

I'm inclined to agree with your interpretation, fd and max_fd are indeed
unsigned integers rather than file descriptors, and there seems to be no
easy way to identify all file descriptors in the specified interval.

The proposed patch just changes the printer of close_range syscall,
but there are at least two more places that need more attention.
First is -P option: pathtrace_match_set tries to match fd and max_fd
assuming they are file descriptors.
Second is tests: tests/close_range* are checking the current behaviour,
they will fail if the printer of close_range syscall is changed this way.

> ---
>  src/close_range.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/close_range.c b/src/close_range.c
> index 3b11c170..4c267bdc 100644
> --- a/src/close_range.c
> +++ b/src/close_range.c
> @@ -12,11 +12,11 @@
>  SYS_FUNC(close_range)
>  {
>  	/* fd */
> -	printfd(tcp, tcp->u_arg[0]);
> +	tprintf("%u", (unsigned int)tcp->u_arg[0]);
>  	tprint_arg_next();
>  
>  	/* max_fd */
> -	printfd(tcp, tcp->u_arg[1]);
> +	tprintf("%u", (unsigned int)tcp->u_arg[1]);
>  	tprint_arg_next();

Please note that we are (slowly but surely) getting rid of raw tprintf
calls, the recommended way of printing these integers would be

	PRINT_VAL_U((unsigned int) tcp->u_arg[0]);
	...
	PRINT_VAL_U((unsigned int) tcp->u_arg[1]);


-- 
ldv