linux-kernel - Re: [PATCH] sched: share task comm length value to userspace

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E652E41.1030308@mleia.com>
Date:	Mon, 05 Sep 2011 23:17:05 +0300
From:	Vladimir Zapolskiy <vz@...ia.com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] sched: share task comm length value to userspace

On 05.09.2011 22:47, Arjan van de Ven wrote:
> On Mon,  5 Sep 2011 21:38:01 +0300
> Vladimir Zapolskiy<vz@...ia.com>  wrote:
>
>> This change allows to get a defined length of task comm in
>> userspace. For a moment this value is implied at least in two cases:
>> * max length of comm value got from /proc/$pid/stat
>> * max string length argument of prctl(PR_[SG]ET_NAME, ...)
>>
>> For these reasons it becomes desirable to impart task comm max length
>> value to userspace.
>
> I'm sorry but I don't like doing this.
>
> The moment we do this, we never can increase it anymore since userspace
> might be using it for its own uses and we'd break it if we changed
> this value.
Thanks for a comment. Your objections are quite clear, and I don't like 
this solution as well, but eventually having that value in userspace is 
really desirable. However in assumption that this value is preserved 
fixed and won't be changed in reasonable perspective, the presented 
approach becomes the most evident and simple.

>
> If we need to export this, we should export it in /proc or /sys
> somewhere as a dynamic value.....
>
Let's do it in a proper way. What's the common practice to export such 
limit values? I suppose via /proc/sys/kernel, please correct me, if I'm 
wrong.

--
With best wishes,
Vladimir
--
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/