Re: + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree

Re: + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree

[Oleg Nesterov]

@@ -1424,6 +1424,28 @@ static void k_getrusage(struct task_stru
 			} while (t != p);
 			break;
 
+		case PR_SET_PROCTITLE_AREA: {
+			struct mm_struct *mm = current->mm;
+			unsigned long addr = arg2;
+			unsigned long len = arg3;
+			unsigned long end = arg2 + arg3;
+
+			if (len > PAGE_SIZE)
+				return -EINVAL;
+
+			if (addr >= end)
+				return -EINVAL;
+
+			if (!access_ok(VERIFY_READ, addr, len))
+				return -EFAULT;
+
+			mutex_lock(&mm->arg_lock);
+			mm->arg_start = addr;
+			mm->arg_end = end;
+			mutex_unlock(&mm->arg_lock);

This looks like the merging error, I guess this code should go into
sys_prct(), not k_getrusage().


The patch adds mm_struct->arg_lock mutex. Can't we reuse mm->mmap_sem?
A bit ugly to have mm->arg_lock just to synchronize sys_prctl() and
proc_pid_cmdline(), imho.

Yes, we can't do access_process_vm() under ->mmap_sem, but we can add
the new helper, say, access_process_vm_locked(tsk, mm, ...) which does
the actual work. Then proc_pid_cmdline() can take mmap_sem for reading,
read arg_start/arg_end and call access_process_vm_locked().

No?

Oleg.

Re: + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree

[Alan Cox]

> Yes, we can't do access_process_vm() under ->mmap_sem, but we can add
> the new helper, say, access_process_vm_locked(tsk, mm, ...) which does
> the actual work. Then proc_pid_cmdline() can take mmap_sem for reading,
> read arg_start/arg_end and call access_process_vm_locked().

It might not be a bad idea if whoever wrote it spent about 60 seconds
thinking about maths overflow as well. I'm not sure some of the tools
will react too well if end is before start.

Re: + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree

[KOSAKI Motohiro]

2009/11/11 Oleg Nesterov <oleg@redhat.com>:
> @@ -1424,6 +1424,28 @@ static void k_getrusage(struct task_stru
>                        } while (t != p);
>                        break;
>
> +               case PR_SET_PROCTITLE_AREA: {
> +                       struct mm_struct *mm = current->mm;
> +                       unsigned long addr = arg2;
> +                       unsigned long len = arg3;
> +                       unsigned long end = arg2 + arg3;
> +
> +                       if (len > PAGE_SIZE)
> +                               return -EINVAL;
> +
> +                       if (addr >= end)
> +                               return -EINVAL;
> +
> +                       if (!access_ok(VERIFY_READ, addr, len))
> +                               return -EFAULT;
> +
> +                       mutex_lock(&mm->arg_lock);
> +                       mm->arg_start = addr;
> +                       mm->arg_end = end;
> +                       mutex_unlock(&mm->arg_lock);
>
> This looks like the merging error, I guess this code should go into
> sys_prct(), not k_getrusage().
>
>
> The patch adds mm_struct->arg_lock mutex. Can't we reuse mm->mmap_sem?
> A bit ugly to have mm->arg_lock just to synchronize sys_prctl() and
> proc_pid_cmdline(), imho.
>
> Yes, we can't do access_process_vm() under ->mmap_sem, but we can add
> the new helper, say, access_process_vm_locked(tsk, mm, ...) which does
> the actual work. Then proc_pid_cmdline() can take mmap_sem for reading,
> read arg_start/arg_end and call access_process_vm_locked().
>
> No?

There is unwritten reason. I hope to add /proc/[pid]/cmdline cache. It
help to avoid
ps getting stuck by mmap_sem.
But, I can accept your proposal on 2.6.32 timeframe. so, I'll make
this patch again.

Andrew, can you please drop this patch at once?

Re: + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree

[Timo Sirainen]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Wed, 2009-11-11 at 02:48 +0900, KOSAKI Motohiro wrote:
> There is unwritten reason. I hope to add /proc/[pid]/cmdline cache. It
> help to avoid
> ps getting stuck by mmap_sem.

Can you explain this further? When would it cache the value and when
would it be returned? I was at least hoping to avoid calling prctl()
every time when I want process title changed.

I think Solaris saves the first 80 chars of the initial cmdline to
kernel memory and gives that to ps. I guess doing something similar and
returning it only when userspace memory can't be accessed would be ok.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree

[KOSAKI Motohiro]

> On Wed, 2009-11-11 at 02:48 +0900, KOSAKI Motohiro wrote:
> > There is unwritten reason. I hope to add /proc/[pid]/cmdline cache. It
> > help to avoid
> > ps getting stuck by mmap_sem.
> 
> Can you explain this further? When would it cache the value and when
> would it be returned? I was at least hoping to avoid calling prctl()
> every time when I want process title changed.

Hmm...
I'm not intent it.

The setter's prctl() performance is not critical. Plus, current code
isn't so slow.

I mean ps -elf (or ps aux) read the /proc/pid/cmdline of all task.
It mean grabbing mmap_sem and read another task's mem for all task.
Then, A stress workload can kill ps performance easily.

Essentially, reading another process's memory is costly operation. but
it can be cached.

Some *BSD has similar mechanism.


Caution: This feature break SPT_ARGV style process title changing.
then, it should be optional feature and sould be able to enable by
admin's explicit operation.
2years after, probably this issue will disappear automatically. because
all setproctitle() using software try to use libc's setproctitle().
IOW, if libc has setproctitle(), nobody try to change own stack argv
string brutally.


> I think Solaris saves the first 80 chars of the initial cmdline to
> kernel memory and gives that to ps. I guess doing something similar and
> returning it only when userspace memory can't be accessed would be ok.

Linux does it too. but 16 chars.