linux-kernel - Re: [PATCH 1/2] perf tool: Refactor comm/tgid lookup

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <55196D0C.8060105@gmail.com>
Date:	Mon, 30 Mar 2015 09:34:36 -0600
From:	David Ahern <dsahern@...il.com>
To:	Jiri Olsa <jolsa@...hat.com>
CC:	acme@...nel.org, linux-kernel@...r.kernel.org,
	Don Zickus <dzickus@...hat.com>, Joe Mario <jmario@...hat.com>
Subject: Re: [PATCH 1/2] perf tool: Refactor comm/tgid lookup

On 3/30/15 2:01 AM, Jiri Olsa wrote:
> On Sun, Mar 29, 2015 at 04:30:01PM -0600, David Ahern wrote:
>
> SNIP
>
>> +	fd = open(filename, O_RDONLY);
>> +	if (fd < 0) {
>>   		pr_debug("couldn't open %s\n", filename);
>>   		return 0;
>>   	}
>>
>> -	while (!comm[0] || (tgid < 0)) {
>> -		if (fgets(bf, sizeof(bf), fp) == NULL) {
>> -			pr_warning("couldn't get COMM and pgid, malformed %s\n",
>> -				   filename);
>> -			break;
>> -		}
>> -
>> -		if (memcmp(bf, "Name:", 5) == 0) {
>> -			char *name = bf + 5;
>> -			while (*name && isspace(*name))
>> -				++name;
>> -			size = strlen(name) - 1;
>> -			if (size >= len)
>> -				size = len - 1;
>> -			memcpy(comm, name, size);
>> -			comm[size] = '\0';
>> -
>> -		} else if (memcmp(bf, "Tgid:", 5) == 0) {
>> -			char *tgids = bf + 5;
>> -			while (*tgids && isspace(*tgids))
>> -				++tgids;
>> -			tgid = atoi(tgids);
>> -		}
>> +	n = read(fd, bf, sizeof(bf) - 1);
>> +	close(fd);
>
> we have filename__read_str, which will read whole file into buffer,
> and you dont need to worry about the file size.. not that there's
> any worry wrt /proc/<pid>/status file, but who knows.. ;-)

hmmm.... I did not know about that function. But I don't think we want 
to use it for this case: This function is called a LOT (think 50k or 
100k threads) and we want to synthesize the threads as fast as possible. 
Using stack (like above) is much faster than dealing with malloc and 
free on each pass.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/