linux-kernel - Re: [PATCH v2] rtla: Remove procps-ng dependency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1ebd6c1d-4409-df70-165c-6f181764a617@kernel.org>
Date:   Fri, 6 May 2022 17:39:58 +0200
From:   Daniel Bristot de Oliveira <bristot@...nel.org>
To:     Tao Zhou <tao.zhou@...ux.dev>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        linux-trace-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
        John Kacur <jkacur@...hat.com>, Daniel Wagner <dwagner@...e.de>
Subject: Re: [PATCH v2] rtla: Remove procps-ng dependency

On 5/6/22 17:06, Tao Zhou wrote:
> On Fri, Apr 29, 2022 at 03:01:48PM +0200,
> Daniel Bristot de Oliveira wrote:
> 
>> Daniel Wagner reported to me that readproc.h got deprecated. Also,
>> while the procps-ng library was available on Fedora, it was not available
>> on RHEL, which is a piece of evidence that it was not that used.
>>
>> rtla uses procps-ng only to find the PID of the tracers' workload.
>>
>> I used the procps-ng library to avoid reinventing the wheel. But in this
>> case, reinventing the wheel took me less time than the time we already
>> took trying to work around problems.
>>
>> Implement a function that reads /proc/ entries, checking if:
>> 	- the entry is a directory
>> 	- the directory name is composed only of digits (PID)
>> 	- the directory contains the comm file
>> 	- the comm file contains a comm that matches the tracers'
>> 	  workload prefix.
>> 	- then return true; otherwise, return false.
>>
>> And use it instead of procps-ng.
>>
>> Changes from V1:
>>   - Use a single buffer for comm and comm_path
>>   - Cause an error in case of a too long command prefix
>>   - Do a close_dir()
>>   - Improve log messages
>>
>> Cc: John Kacur <jkacur@...hat.com>
>> Cc: Steven Rostedt <rostedt@...dmis.org>
>> Fixes: b1696371d865 ("rtla: Helper functions for rtla")
>> Reported-by: Daniel Wagner <dwagner@...e.de>
>> Signed-off-by: Daniel Bristot de Oliveira <bristot@...nel.org>


[...]

>> +
>>  /*
>> - * set_comm_sched_attr - set sched params to threads starting with char *comm
>> + * procfs_is_workload_pid - check if a procfs entry contains a comm_prefix* comm
>> + *
>> + * Check if the procfs entry is a directory of a process, and then check if the
>> + * process has a comm with the prefix set in char *comm_prefix. As the
>> + * current users of this function only check for kernel threads, there is no
>> + * need to check for the threads for the process.
>>   *
>> - * This function uses procps to list the currently running threads and then
>> - * set the sched_attr *attr to the threads that start with char *comm. It is
>> + * Return: True if the proc_entry contains a comm file with comm_prefix*.
>> + * Otherwise returns false.
>> + */
>> +static int procfs_is_workload_pid(const char *comm_prefix, struct dirent *proc_entry)
>> +{
>> +	char buffer[MAX_PATH];
>> +	int comm_fd, retval;
>> +	char*t_name;
> 
> Need a blank..
> char *t_name;


right

>> +
>> +	if (proc_entry->d_type != DT_DIR)
>> +		return 0;
>> +
>> +	if (*proc_entry->d_name == '.')
>> +		return 0;
>> +
>> +	/* check if the string is a pid */
>> +	for (t_name = proc_entry->d_name; t_name; t_name++) {
>> +		if (!isdigit(*t_name))
>> +			break;
>> +	}
>> +
>> +	if (*t_name != '\0')
>> +		return 0;
>> +
>> +	snprintf(buffer, MAX_PATH, "/proc/%s/comm", proc_entry->d_name);
>> +	comm_fd = open(buffer, O_RDONLY);
>> +	if (comm_fd < 0)
>> +		return 0;
>> +
>> +	memset(buffer, 0, MAX_PATH);
>> +	retval = read(comm_fd, buffer, MAX_PATH);
>> +
>> +	close(comm_fd);
>> +
>> +	if (retval <= 0)
>> +		return 0;
>> +
>> +	retval = strncmp(comm_prefix, buffer, strlen(comm_prefix));
>> +	if (retval)
>> +		return 0;
> 
> 
> Confused.
> 
> For example:
> comm_prefix is "osnoise/", buffer is "osnoise\n"(as said by comment below),
> strlen_prefix is 8. The return value of strncmp() is 1 and not set sched attr.

it should not set "osnoise" thread priority... so it is correct.

> Or use "osnoise" as the comm_prefix. Or am I miss something here.

I am looking for "osnoise/$CPU" threads, not "osnoise" threads. Run rtla osnoise
with log messages (-D) you will see it finding the expected threads.

>> +	/* comm already have \n */
>> +	debug_msg("Found workload pid:%s comm:%s", proc_entry->d_name, buffer);
>> +
>> +	return 1;
>> +}
>> +
>> +/*
>> + * set_comm_sched_attr - set sched params to threads starting with char *comm_prefix
>> + *
>> + * This function uses procps to list the currently running threads and then set the
> 
> s/procps/procfs/

right

Thanks
-- Daniel
> 
> Thanks,
> Tao