Ok ... this would (I suspect, just from code reading, no bytes were
harmed in actual testing of this) have a minor change to how white
space is handled writing integer flags to cpuset files, and a minor
inconstency.
1) Existing cpuset code lets you set a flag (e.g. cpu_exclusive) by doing:
echo '1 rumplestiltskin' > cpu_exclusive # same as: echo 1 >
cpu_exclusive
With this patch, that probably fails, EINVAL.
2) With this patch, one can write "1" or "1\n" to cpuset integer files, but one
cannot successfully write "1\r\n" or "1 " or "1 \n". However, for the
cpuset
control files that take strings, not single integers, one -can- have any mix
of trailing white space.
So far as I know, I have no requirement to write rumplestiltskin to cpuset
files ;).
So I'm content to let the minor change in (1) pass without further comment.
I'd like to recommend consideration of the following patch, to address the
minor inconsistency of (2), and to save a few bytes of kernel text space.
=======
From: Paul Jackson <[EMAIL PROTECTED]>
Strip all trailing whitespace (such as carriage returns)
when parsing integer writes to cgroup files, not just
one trailing newline if present.
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Cc: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- 2.6.24-mm1.orig/kernel/cgroup.c 2008-02-16 04:20:33.000000000 -0800
+++ 2.6.24-mm1/kernel/cgroup.c 2008-02-16 19:00:41.207478218 -0800
@@ -1321,10 +1321,7 @@ static ssize_t cgroup_write_uint(struct
return -EFAULT;
buffer[nbytes] = 0; /* nul-terminate */
-
- /* strip newline if necessary */
- if (nbytes && (buffer[nbytes-1] == '\n'))
- buffer[nbytes-1] = 0;
+ strstrip(buffer); /* strip -just- trailing whitespace */
val = simple_strtoull(buffer, &end, 0);
if (*end)
return -EINVAL;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
