lkml.org 
[lkml]   [2006]   [Sep]   [8]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 08 Sep 2006 10:16:51 -0700
FromEdward Falk <>
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 17:19    [from the cache]
©2003-2008