Re: [PATCH] linux-2.6.16.51 gzipped core dump patch
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] linux-2.6.16.51 gzipped core dump patch
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: linux-kernel@vger.kernel.org
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,
)) {
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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, )) {
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] linux-2.6.16.51 gzipped core dump patch
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: linux-kernel@vger.kernel.org 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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] linux-2.6.16.51 gzipped core dump patch
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: linux-kernel@vger.kernel.org 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... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] linux-2.6.16.51 gzipped core dump patch
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: linux-kernel@vger.kernel.org
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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] linux-2.6.16.51 gzipped core dump patch
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
