From: Andi Kleen <andi@firstfloor.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Christopher S. Aker" <caker@theshore.net>,
Randy Dunlap <randy.dunlap@oracle.com>,
Andi Kleen <andi@firstfloor.org>,
"Bill Rugolsky Jr." <brugolsky@telemetry-investments.com>,
linux-kernel@vger.kernel.org
Subject: Re: [Feature Request?] Inline compression of process core dumps
Date: 13 Apr 2007 14:23:51 +0200 [thread overview]
Message-ID: <p73d528799k.fsf@bingen.suse.de> (raw)
In-Reply-To: <20070413115526.69e61016@the-village.bc.nu>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > I saw that too, and unfortunately I don't know what what that condition
> > represents, either. It's the only other element in that if statement
> > that could make it take that path, so I'm assuming that's part of the
> > problem.
>
> Multiple mm's mean multiple threads with a different set of mappings,
> which would fit for UML. Either way there should be a check for !pipe
> before appending the pid
Here's a patch. It just doesn't do any formatting for the pipe case.
-Andi
Fix core to pipe for multithreaded processes
I also removed the BKL around format_corename because it seems unneeded.
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux-2.6.21-rc3-test/fs/exec.c
===================================================================
--- linux-2.6.21-rc3-test.orig/fs/exec.c
+++ linux-2.6.21-rc3-test/fs/exec.c
@@ -1501,9 +1501,6 @@ int do_coredump(long signr, int exit_cod
* lock_kernel() because format_corename() is controlled by sysctl, which
* uses lock_kernel()
*/
- lock_kernel();
- format_corename(corename, core_pattern, signr);
- unlock_kernel();
if (corename[0] == '|') {
/* SIGPIPE can happen, but it's just never processed */
if(call_usermodehelper_pipe(corename+1, NULL, NULL, &file)) {
@@ -1512,10 +1509,12 @@ int do_coredump(long signr, int exit_cod
goto fail_unlock;
}
ispipe = 1;
- } else
+ } else {
+ format_corename(corename, core_pattern, signr);
file = filp_open(corename,
O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE | flag,
0600);
+ }
if (IS_ERR(file))
goto fail_unlock;
inode = file->f_path.dentry->d_inode;
next prev parent reply other threads:[~2007-04-13 11:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-12 15:52 [Feature Request?] Inline compression of process core dumps Christopher S. Aker
2007-04-12 16:09 ` Bill Rugolsky Jr.
2007-04-12 16:18 ` Guillaume Chazarain
2007-04-12 16:28 ` Alan Cox
2007-04-12 16:42 ` Bill Rugolsky Jr.
2007-04-12 17:45 ` Andi Kleen
2007-04-13 2:22 ` Christopher S. Aker
2007-04-13 2:38 ` Randy Dunlap
2007-04-13 2:57 ` Christopher S. Aker
2007-04-13 4:21 ` Jeff Dike
2007-04-13 10:55 ` Alan Cox
2007-04-13 12:23 ` Andi Kleen [this message]
2007-04-13 14:59 ` Randy Dunlap
2007-04-13 15:43 ` Andi Kleen
2007-04-13 16:17 ` Alan Cox
2007-04-13 19:42 ` Andi Kleen
2007-04-13 12:39 ` Alan Cox
2007-04-13 13:38 ` Christopher S. Aker
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=p73d528799k.fsf@bingen.suse.de \
--to=andi@firstfloor.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=brugolsky@telemetry-investments.com \
--cc=caker@theshore.net \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox