From: Oleg Nesterov <oleg@redhat.com>
To: Earl Chew <echew@ixiacom.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"andi@firstfloor.org" <andi@firstfloor.org>
Subject: Re: [PATCH 1/1 v2]: coredump: use current->group_leader->comm instead of current->comm
Date: Fri, 2 Sep 2011 19:48:06 +0200 [thread overview]
Message-ID: <20110902174806.GA9238@redhat.com> (raw)
In-Reply-To: <4E610DAE.4080607@ixiacom.com>
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.
next prev parent reply other threads:[~2011-09-02 17:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 17:01 [ PATCH 1/1 ] coredump: use current->group_leader->comm instead of current->comm Earl Chew
2011-09-01 18:55 ` Alan Cox
2011-09-01 19:12 ` [PATCH 1/1 v2]: " Earl Chew
2011-09-02 16:30 ` Oleg Nesterov
2011-09-02 17:09 ` Earl Chew
2011-09-02 17:48 ` Oleg Nesterov [this message]
2011-09-02 23:05 ` Earl Chew
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110902174806.GA9238@redhat.com \
--to=oleg@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=echew@ixiacom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.