Messages in this thread | | | Date | Fri, 2 Sep 2011 19:48:06 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/1 v2]: coredump: use current->group_leader->comm instead of current->comm |
| |
On 09/02, Earl Chew wrote: > > Oleg, > > >> The patterns %n or %N are the same as %e and %E except that they > >> use current->group_leader->comm instead of current->comm. > > > > I simply do not know what is better. Alan has a point imho, "might > > break stuff" is true. > > > > OTOH, %p always reports tgid, not tid... > > Which speaks partly to my notion of "consistency".
That is why I mentioned it with "otoh" ;)
> I viewed my original change as more "consistent" because it > yielded the attribute alluded to in the documentation --- the > same value for all threads in the one process: > > - Consistent with the documentation > - Consistent with respect to process name (as opposed to thread name) > > >> A core dump can be triggered from any task in a group, > > > > Indeed. The important case is the private/synchronous signals like > > SIGSEGV, you can see the name of the thread which triggered the crash. > > While that is true, it doesn't seem to have been the original intent as > per the %e documentation.
May be. May be not. I do not know.
> Should get_mm_exe_file() just use current->group_leader->comm since it's > meant to be process specific anyway,
Probably. Although group_leader->comm is thread specific too, but at least we do not use the "random" thread. My only point was, imho this doesn't deserve another option.
> and there isn't an existing code base > for %E ?
Who knows? But once again, we use ->comm in the very unlikely case.
And let me repeat just in case. I do not argue, I agree either way.
Oleg.
| |