lkml.org 
[lkml]   [2006]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Proper /proc/pid/cmdline behavior when command line is corrupt?
Jan Engelhardt wrote:
> Hi Edward,

>>that the environment buffer is assumed to immediately follow the
>>command line buffer.
>
>
> The environment buffer is not assumed to be there, it is _known_ to come right
> after the argument string, because that is how the kernel sets it up on execve
> (for x86 at least).

Is that in a spec somewhere? Otherwise, I would argue that it isn't
_known_ to come right after the argument string, it just _happens_ to
come right after the argument string. This could change in future kernels.



>>I'm currently working on a patch that removes the one page limit on
>>the returned command line buffer but I'm not convinced I should
>>retain this behavior.
>
>
> I think yes. proc_pid_cmdline() has these lines:
>
> len = mm->arg_end - mm->arg_start
> * if (len > PAGE_SIZE)
> * len = PAGE_SIZE;
> res = access_process_vm(task, mm->arg_start, buffer, len, 0);
>
>
> and @buffer is allocated in the caller as only one page:

True, but that's an arbitrary limitation which I'm in the process of
removing. I have a new version of proc_pid_cmdline() which will return
the entire commandline buffer no matter what its length. If the
grab-more-data-from-environment-buffer behavior is actually broken, I'd
rather not propagate it to the new code.

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

\
 
 \ /
  Last update: 2006-09-08 19:19    [W:0.769 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site