coredump: use task comm instead of (unknown)

If we don't know the file corresponding to the binary (i.e. exe_file is unknown), use "task->comm (path unknown)" instead of simple "(unknown)" as suggested by ak.

The fallback is the same as %e except it will append "(path unknown)".

Signed-off-by Jiri Slaby <[email protected]>

Cc Alan Cox <[email protected]>

Cc Al Viro <[email protected]>

Cc Andi Kleen <[email protected]>

---
 fs/exec.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

fs/exec.c +0 -0

index 5ee7562..0a4d281 100644

Quoted 25 lines · On Wed, 4 May 2011 09:32:34 +0200 Jiri Slaby <[email protected]> wrote:

If we don't know the file corresponding to the binary (i.e. exe_file is unknown), use "task->comm (path unknown)" instead of simple "(unknown)" as suggested by ak.

The fallback is the same as %e except it will append "(path unknown)".

Signed-off-by Jiri Slaby <[email protected]>

Cc Alan Cox <[email protected]>

Cc Al Viro <[email protected]>

Cc Andi Kleen <[email protected]>

---
 fs/exec.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

fs/exec.c +1 -1

index 5ee7562..0a4d281 100644
@@ -1555,7 +1555,7 @@ static int cn_print_exe_file(struct core_name *cn)
 
 	exe_file = get_mm_exe_file(current->mm);
 	if (!exe_file)
-		return cn_printf(cn, "(unknown)");
+		return cn_printf(cn, "%s (path unknown)", current->comm);
 

fs/exec.c static int cn_print_exe_file(struct core_name *cn) · line 1561

Quoted 2 lines

fs/exec.c +0 -0

 	pathbuf = kmalloc(PATH_MAX, GFP_TEMPORARY);
 	if (!pathbuf) {

Direct access to current->comm is racy since we added prctl(PR_SET_NAME).

Hopefully John Stultz will soon be presenting us with a %p modifier for displaying task_struct.comm.

But we should get this settled pretty promptly as this is a form of userspace-visible API. Use get_task_comm() for now.

Also, there's nothing which prevents userspace from rewriting task->comm to something which contains slashes (this seems bad). If that is done, your patch will do Bad Things - it should be modified to use cn_print_exe_file()'s slash-overwriting codepath.

Direct access to current->comm is racy since we added prctl(PR_SET_NAME).

Quoted 2 lines · Andrew Morton

Direct access to current->comm is racy since we added prctl(PR_SET_NAME).

A passer-by's question. Did we change below one

char *get_task_comm(char *buf, struct task_struct *tsk)

{
	/* buf must be at least sizeof(tsk->comm) in size */
	task_lock(tsk);
	strncpy(buf, tsk->comm, sizeof(tsk->comm));
	task_unlock(tsk);
	return buf;
}

since some archs may do like

char *strncpy(char *dest, const char *src, size_t n)

{
	size_t len = __strnend(src, n) - src;
	__builtin_memset(dest + len, 0, n - len);
	__builtin_memcpy(dest, src, len);
	return dest;
}

( arch/s390/lib/string.c ) after adding prctl(PR_SET_NAME)?

Quoted 3 lines

char *strncpy(char *dest, const char *src, size_t n)

{
	size_t len = __strnend(src, n) - src;

Quoted 2 lines

	__builtin_memset(dest + len, 0, n - len);
	__builtin_memcpy(dest, src, len);

Quoted 2 lines

	return dest;
}

Quoted 3 lines · Andrew Morton

Quoted 3 lines

char *strncpy(char *dest, const char *src, size_t n)

{
	size_t len = __strnend(src, n) - src;

If src was overwritten by prctl(PR_SET_NAME) at this moment (i.e. after len was calculated),

Quoted 2 lines

Quoted 2 lines

	__builtin_memset(dest + len, 0, n - len);
	__builtin_memcpy(dest, src, len);

won't this result in inconsistent copying of src when length of src has changed by prctl(PR_SET_NAME)?

Quoted 2 lines

Quoted 2 lines

	return dest;
}

This strncpy() assumes that length of src won't change within the function. I thought prctl(PR_SET_NAME) might break such assumption.

PR_SET_NAME uses set_task_comm() which has appropriate locking to protect against get_task_comm().

If kernel code directly accesses task->comm without taking task_lock() then yes, it's racy.

Hopefully John Stultz will soon be presenting us with a %p modifier for displaying task_struct.comm.