[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <516475EB.7030508@linaro.org>
Date: Tue, 09 Apr 2013 13:11:23 -0700
From: John Stultz <john.stultz@...aro.org>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: David Rientjes <rientjes@...gle.com>,
John Stultz <johnstul@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [patch] fs, proc: truncate /proc/pid/comm writes to first TASK_COMM_LEN
bytes
On 04/09/2013 01:03 PM, Andrew Morton wrote:
>> cc: John Stultz <johnstul@...ibm.com>
> I don't know if that address still works.
No, that email is no longer active. Thanks for noticing this.
> From: David Rientjes <rientjes@...gle.com>
> Subject: fs, proc: truncate /proc/pid/comm writes to first TASK_COMM_LEN bytes
>
> Currently, a write to a procfs file will return the number of bytes
> successfully written. If the actual string is longer than this, the
> remainder of the string will not be be written and userspace will complete
> the operation by issuing additional write()s.
>
> Hence
>
> $ echo -n "abcdefghijklmnopqrs" > /proc/self/comm
>
> results in
>
> $ cat /proc/$$/comm
> pqrs
>
> since the final four bytes were written with a second write() since
> TASK_COMM_LEN == 16. This is obviously an undesired result and not
> equivalent to prctl(PR_SET_NAME). The implementation should not need to
> know the definition of TASK_COMM_LEN.
That's embarrassing, thanks for catching it!
> This patch truncates the string to the first TASK_COMM_LEN bytes and
> returns the bytes written as the length of the string written so the
> second write() is suppressed.
>
> $ cat /proc/$$/comm
> abcdefghijklmno
>
> Signed-off-by: David Rientjes <rientjes@...gle.com>
> Cc: John Stultz <john.stultz@...aro.org>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Acked-by: John Stultz <john.stultz@...aro.org>
--
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/
Powered by blists - more mailing lists