Messages in this thread | | | Date | Fri, 08 Sep 2006 10:16:51 -0700 | From | Edward Falk <> | Subject | Re: 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/
| |