Re: Changes in fork ?

From: Sergey Kubushin (ksi@ksi-linux.com)
Date: Mon Jan 24 2000 - 05:15:33 EST


On 23 Jan 2000, Nick Holloway wrote:

> root@chaos.analogic.com (Richard B. Johnson) writes:
> > On Fri, 21 Jan 2000, Sergey Kubushin wrote:
> > > I have a question about fork() (?) behaviour. The problem shows itself as
> > > truncated lines in ps output on processes that are forked outta daemons
> > > which use setproctitle() (from sendmail sources) such as sendmail, inetd
> > > etc. All's fine on 2.2.xx kernels, but I have the following under 2.3.xx :
> > >
> > > === Cut ===
> > > 22352 ? S 0:00 sendmail: accepting connectio
> > > 22353 ? S 0:00 \_ sendmail: LAA14150 relay1.cha
> >
> > Yes. This was previously reported by myself. Basically, what the
> > daemons are doing is:
> >
> > int main (int argc, *argv[])
> > { /* setproctitle() */
> > strcpy(argv[0], "New Name to be seen by `ps`");
> >
> > This is NotGood(tm) because no child knows how much space was
> > available for the string. However, it's been done for ages. New
> > /proc/###/cmdline code (where `ps` gets the command-line), now
> > only allows you to read the length of the initial allocation.
>
> Normally the implementations of setproctitle() are a little more careful
> than that. They use the processes environment space in addition to the
> argument space. This does rely on them being contiguous memory areas.

Can one rely on argv and env being contigous memory area? Getting it another
way - can the proposed patch be applied with no side effects? Sendmail's
setproctitle does work the a.m. way, i.e. it uses the environment space in
addition to the argument space so it looks like a right way to set a proc
title...

> Looking as binfmt_elf and binfmt_aout, this still appears to be true in
> 2.3.40, so the previous behaviour can be restored by limiting the area
> returned in /proc/$$/cmdline to be env_end, instead of arg_end.

What was the reason behind making such a change? It could be simply an
overlooked typo, but it could also be done for some good reason. Can
somebody enlighten me? It have to be fixed if it IS a typo. And it looks
like a typo, 'coz we have to fix helluva lotta programs which do use
setproctitle if it is not. Falling back to the old kernel behaviour would
be much less pain then fixing all the applications that use to change their
argv for ps...

> Note that the contents returned in /proc/$$/environ are already trashed
> by code that uses setproctitle().
>
> --- /usr/src/linux-2.3/fs/proc/base.c Sun Jan 23 10:50:53 2000
> +++ base.c Sun Jan 23 11:45:03 2000
> @@ -120,7 +120,7 @@
> struct mm_struct *mm = task->mm;
> int res = 0;
> if (mm) {
> - int len = mm->arg_end - mm->arg_start;
> + int len = mm->env_end - mm->arg_start;
> if (len > PAGE_SIZE)
> len = PAGE_SIZE;
> res = access_process_vm(task, mm->arg_start, buffer, len, 0);
>
> --
> `O O' | Nick.Holloway@alfie.demon.co.uk
> // ^ \\ | http://www.alfie.demon.co.uk/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>

===========================================================================
Sergey Kubushin aka the Tamer < > The impossible we do immediately.
e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
===========================================================================

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



This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:11 EST