diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2018-05-17 15:17:33 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2018-05-17 15:35:02 -0700 |
commit | 5ab8271899658042fabc5ae7e6a99066a210bc0e (patch) | |
tree | 6961d8faa53d7e2f535d14acc3bb8536a268fb8d /fs/nfs/nfs4state.c | |
parent | e4b4e441323b7988a344f88d7ee3f8fcb17db048 (diff) | |
download | linux-proc-cmdline.tar.bz2 |
fs/proc: simplify and clarify get_mm_cmdline() functionproc-cmdline
We have some very odd semantics for reading the command line through
/proc, because we allow people to rewrite their own command line pretty
much at will, and things get positively funky when you extend your
command line past the point that used to be the end of the command line,
and is now in the environment variable area.
But our weird semantics doesn't mean that we should write weird and
complex code to handle them.
So re-write get_mm_cmdline() to be much simpler, and much more explicit
about what it is actually doing and why. And avoid the extra check for
"is there a NUL character at the end of the command line where I expect
one to be", by simply making the NUL character handling be part of the
normal "once you hit the end of the command line, stop at the first NUL
character" logic.
It's quite possible that we should stop the crazy "walk into
environment" entirely, but happily it's not really the usual case.
NOTE! We tried to really simplify and limit our odd cmdline parsing some
time ago, but people complained. See commit c2c0bb44620d ("proc: fix
PAGE_SIZE limit of /proc/$PID/cmdline") for details about why we have
this complexity.
Cc: Tejun Heo <tj@kernel.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/nfs/nfs4state.c')
0 files changed, 0 insertions, 0 deletions