On Thu, Jul 26, 2007 at 01:35:36PM -0700, Andrew Morton wrote:
> On Thu, 26 Jul 2007 16:20:18 -0400 Neil Horman <[email protected]> wrote:
>
> > If you'd like to back them all out, I have them
> > all in a git tree here, and I can repost (say early next week when I finish
> > local testing) as a patch sequence, with all my screw-ups properly fixed,
> > and with an appropriate changelog describing the whole sequence.
>
> hm, I have six fixes here against
> allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe.patch
> and I always worry that some might get lost.
>
> How many more patches have you after this one?
I think the best organization that I could give you would leave me with one
patch remaining, for a total of three that you would have to carry:
Patch 1) Removing the RLIMIT_CORE restriction on core_dumps in do_coredump and
the core_dump methods from fs/binfmt_*.c
Patch 2) Add the ability to parse arguments out of
/proc/sys/kernel/core_pattern, along with the ability to specify the origional
RLIMIT_CORE size as an option.
Patch 3) fix up some pre-existing bugs that I found while doing the other work.
Specifically I found that call_usermodehelper_pipe waits for the usermodehelper
to exit. Since we are redirecting stdin for the helper to a pipe, any reader of
the pipe will cause a deadlock in the do_coredump path. I want to fix up that
and a few simmilar bugs.
You have the first two as you know, and I plan to be done with the third on
friday or monday. Just let me know if you would like me to repost the first two
with the third as a sequence set.
As far as the changelog for these three (or six, if you want to count the
interviening fixes separately), you can use this:
For some time now /proc/sys/core_pattern has allowed for the specification that
the output desitination of a core dump be a pipe to a user space process, rather
than a file system location. This enables a class of applications that allows
for intellegent handling of application crashes. While the pipe core_pattern
infrastrucutre is beneficial, it is lacking in certain points. Specifically it
is unable to dump cores if a users core dump ulimit is too low, despite the fact
that no data need be written to a filesystem. It is also lacking in the sense
that while an application can be specified as the reader end of the pipe,
arguments cannot be currently passed to this application. This set of patches
seeks to improve this infrastructure by:
1) Ignoring RLIMIT_CORE restrictions when the core destination is a pipe,
relying instead on user space security to prevent oversubscription of resources
2) Allowing arguments to be specified and passed to applications specified in
core_pattern
3) Fixing a few pre-existing bugs discovered during the aforementioned two
development points.
Thanks and Regards
Neil
P.S. Will, please send me email addresses for relevant interested parties from
ubuntu, and I'll happily copy them on these patches.
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
