Re: [PATCH]: allow individual core dump methods to be unlimited when sending to a pipe

On Tue, Jul 24, 2007 at 02:09:39AM -0700, Andrew Morton wrote:
On Sun, 22 Jul 2007 11:39:47 -0400 Neil Horman <nhorman@xxxxxxxxxxxxx> wrote:

This is a follow on to the patch entitled:
update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch
It allows individual core dump methods to have the core dump size limit passed
into them. Its more efficient than each method having to retrieve it on their
own, and it allows for do_coredump to specify a infinite limit in the event that
a pipe is configured in /proc/sys/kernel/core_pattern, in which case ulimit -c
should not apply.

Needed this warning fix:

fs/exec.c: In function 'do_coredump':
fs/exec.c:1761: warning: large integer implicitly truncated to unsigned type

diff -puN fs/exec.c~allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix fs/exec.c
--- a/fs/exec.c~allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix
+++ a/fs/exec.c
@@ -1703,7 +1703,7 @@ int do_coredump(long signr, int exit_cod
int fsuid = current->fsuid;
int flag = 0;
int ispipe = 0;
- u32 core_limit = current->signal->rlim[RLIMIT_CORE].rlim_cur;
+ unsigned long core_limit = current->signal->rlim[RLIMIT_CORE].rlim_cur;

audit_core_dumps(signr);

_

which makes me worry about how much care was taken here on 32/64 issues,
and crsos-arch issues (the underlying type for compat_ulong_t, for one).

Could you please go over it with a toothcomb, see if there are any other
slipups there?

Yes, I had noticed this yesterday aternoon as well, Andrew. Sorry about that.
Upon looking at it using unsigned long should be the superset of all the
definitions, so I'm working on a patch to align that, and am testing it on all
the arches I have available here (x86, x86_64, ia64, and perhaps ppc64 if I can
get hold of it). I also have a few more bugs that need fixing in the
core_pattern/pipe code as well as one more feature enhancement (the ability to
pass an argv array). I'll fix up the bugs first, and you can expect these
patches in the next day or two.

Thanks & Regards
Neil

Thanks.

--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@xxxxxxxxxxxxx
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/