Hi,
The attached patch is based on Jan Frey's previous patch posted in 2004
for the Linux 2.4 kernel. It has been tested on X86 and MIPS platforms.
If the core pattern doesn't end in ".gz" it will be added to the name of
the core file. It's offered under GPL v2 without any warranties. If you
have any questions, please contact me directly at Mano.Pallewatta "at"
motorola.com.
Regards,
Methlal (Mano) Pallewatta
On Mon, Sep 03, 2007 at 08:49:00PM -0400, Pallewatta Mano-FPCD67 wrote:
> Hi,
> The attached patch is based on Jan Frey's previous patch posted in 2004
> for the Linux 2.4 kernel. It has been tested on X86 and MIPS platforms.
> If the core pattern doesn't end in ".gz" it will be added to the name of
> the core file. It's offered under GPL v2 without any warranties. If you
> have any questions, please contact me directly at Mano.Pallewatta "at"
> motorola.com.
This is silly, IMO - why do in kernel what can be done in userland? External
process can damn well gzip/bzip2/uuencode and post to alt.sex.cthulhu.binaries/
whatever. Just feed the usual data to its stdin...
This patch was developed for embedded systems which had limited space
for file storage. If an external process is to compress core files you
will need to store those files somewhere first as core dump output
cannot be directly fed to the stdin of compression program. Imagine
storing a 40 Meg core file in an embedded system. A few core files will
fill up the file system and some core files can get corrupted too.
Mano
-----Original Message-----
From: Al Viro [mailto:[email protected]]
Sent: Monday, September 03, 2007 6:38 PM
To: Pallewatta Mano-FPCD67
Cc: [email protected]
Subject: Re: [PATCH] linux-2.6.16.51 gzipped core dump patch
On Mon, Sep 03, 2007 at 08:49:00PM -0400, Pallewatta Mano-FPCD67 wrote:
> Hi,
> The attached patch is based on Jan Frey's previous patch posted in
2004
> for the Linux 2.4 kernel. It has been tested on X86 and MIPS
platforms.
> If the core pattern doesn't end in ".gz" it will be added to the name
of
> the core file. It's offered under GPL v2 without any warranties. If
you
> have any questions, please contact me directly at Mano.Pallewatta "at"
> motorola.com.
This is silly, IMO - why do in kernel what can be done in userland?
External
process can damn well gzip/bzip2/uuencode and post to
alt.sex.cthulhu.binaries/
whatever. Just feed the usual data to its stdin...
On Mon, Sep 03, 2007 at 10:32:00PM -0400, Pallewatta Mano-FPCD67 wrote:
> This patch was developed for embedded systems which had limited space
> for file storage. If an external process is to compress core files you
> will need to store those files somewhere first as core dump output
> cannot be directly fed to the stdin of compression program.
Why? Create a pipe, start a new process, put the reader struct file
into its descriptor table as stdin, do execve in new process and
pass the writer struct file to ->core_dump().
As the matter of fact, it's already done - see
lock_kernel();
ispipe = format_corename(corename, core_pattern, signr);
unlock_kernel();
if (ispipe) {
/* SIGPIPE can happen, but it's just never processed */
if(call_usermodehelper_pipe(corename+1, NULL, NULL, &file)) {
printk(KERN_INFO "Core dump to %s pipe failed\n",
corename);
goto fail_unlock;
}
} else
file = filp_open(corename,
O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE | flag,
0600);
in do_coredump(). So take a look at fs/exec.c:format_corename() and see
what to feed for it in order to get the equivalent of your patch.
core_patttern is set by sysctl (just say
echo [whatever] >/proc/sys/kernel/core_pattern
and don't forget quoting, since | should be the first character to indicate
that you want to pipe coredump through a helper).
I really don't see a reason to do that kind of work in the kernel, embedded
system or not.
This support was there in the 2.6.16.51 kernel. In fact there was no
call_usermodehelper_pipe().
Mano
-----Original Message-----
From: Al Viro [mailto:[email protected]]
Sent: Monday, September 03, 2007 8:27 PM
To: Pallewatta Mano-FPCD67
Cc: [email protected]
Subject: Re: [PATCH] linux-2.6.16.51 gzipped core dump patch
On Mon, Sep 03, 2007 at 10:32:00PM -0400, Pallewatta Mano-FPCD67 wrote:
> This patch was developed for embedded systems which had limited space
> for file storage. If an external process is to compress core files you
> will need to store those files somewhere first as core dump output
> cannot be directly fed to the stdin of compression program.
Why? Create a pipe, start a new process, put the reader struct file
into its descriptor table as stdin, do execve in new process and
pass the writer struct file to ->core_dump().
As the matter of fact, it's already done - see
lock_kernel();
ispipe = format_corename(corename, core_pattern, signr);
unlock_kernel();
if (ispipe) {
/* SIGPIPE can happen, but it's just never processed */
if(call_usermodehelper_pipe(corename+1, NULL, NULL,
&file)) {
printk(KERN_INFO "Core dump to %s pipe
failed\n",
corename);
goto fail_unlock;
}
} else
file = filp_open(corename,
O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE
| flag,
0600);
in do_coredump(). So take a look at fs/exec.c:format_corename() and see
what to feed for it in order to get the equivalent of your patch.
core_patttern is set by sysctl (just say
echo [whatever] >/proc/sys/kernel/core_pattern
and don't forget quoting, since | should be the first character to
indicate
that you want to pipe coredump through a helper).
I really don't see a reason to do that kind of work in the kernel,
embedded
system or not.
On Tue, Sep 04, 2007 at 12:04:37AM -0400, Pallewatta Mano-FPCD67 wrote:
> This support was there in the 2.6.16.51 kernel. In fact there was no
> call_usermodehelper_pipe().
So backport it, instead of creating an incompatible interface and headache
when you eventually rebase to later kernel.