Oleg Nesterov <oleg@xxxxxxxxxx> writes: > On 09/16, Will Drewry wrote: >> >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1467,6 +1467,13 @@ static int format_corename(char *corename, long signr) >> char *const out_end = corename + CORENAME_MAX_SIZE; >> int rc; >> int pid_in_pattern = 0; >> + pid_t pid = task_tgid_vnr(current); >> + >> + /* The pipe helper runs in the init namespace and should >> + * receive the matching pid until that changes. >> + */ >> + if (ispipe) >> + pid = task_tgid_nr(current); > > Agreed, it doesn't make sense to pass the "local" pid to the init ns. Yes, passing the local pid to the init pid namespace doesn't make a lot of sense. I have recently fixed unix domain sockets to avoid doing that kind of silliness. That said I don't think this is a complete fix. We also potentially have the same issue with the uts namespace and the user namespace. I believe the core file holds all of this information relative to the process that is dying, one elf note or other so we don't need to worry about information loss. As for how to implement this for the pid case can we simply grab the namespace at the ispipe stage and use task_tgid_nr_ns. Something like: pid_ns = current->nsproxy->pid_ns; if (is_pipe) pid_ns = &init_pid_ns; .... /* pid */ case 'p': pid_in_pattern = 1; rc = snprintf(out_ptr, out_end - out_ptr, "%d", task_tgid_pid_nr_ns(pid_ns, current)); if (rc > out_end - out_ptr) goto out; out_ptr += rc; break; Will you were saying something about complex namespacing (in particular the network namespace giving you problems). The network namespace has no influence over pipes so how does that come into play? I can imagine that it would be nice to have different core patterns depending on where you are in the process tree, so a container can do something different than the system outside of the container. Are you thinking along those lines, or are you imagining something else? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
