Re: [PATCH 0/4] coredump: core dump masking support v2
Hi! > > Can we simply add ulimit with boolean value, that says dump > > anon_shared... or not? It will be simpler and faster, because you'll > > not need locking. > > Yes, using ulimit will be simpler and faster, but less flexible. It is prefered in this case. > The core dump flags can be changed only before running the program. > If the user modifies the program, the user will be able to change the > flags anytime. But the user can't always modify the program. You can do ulimit then exec from wrapper. > I need the ability to change the core dump flags anytime. Then maybe right solution is to extend _ulimit_ to change anything anytime. But that's definitely separate patch. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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 0/4] coredump: core dump masking support v2
Hi, I'm sorry that I couldn't reply you sooner. Pavel Machek wrote: >>Okay, I'll adopt your idea in the next version. >>I'm going to provide the proc entry as follows: >> >> (1) /proc//core_flags/flags >> (2) /proc//core_flags/omit_anon_shared >> >>(1) is the same as current core_flags. It is for expert users. >>(2) corresponds to one bit in (1). >>If (2) is set to 1, anonymous shared memory of the process is never >>dumped. > > Now, that's what I call an ugly interface. I considered for a while, and then I decided not to use the above-stated interfaces. Instead, I'll create just one proc entry to access to one core dump flag: /proc//coredump_omit_anonymous_shared I think it is simple enough. Would you think it is still ugly? > Can we simply add ulimit with boolean value, that says dump > anon_shared... or not? It will be simpler and faster, because you'll > not need locking. Yes, using ulimit will be simpler and faster, but less flexible. The core dump flags can be changed only before running the program. If the user modifies the program, the user will be able to change the flags anytime. But the user can't always modify the program. I need the ability to change the core dump flags anytime. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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 0/4] coredump: core dump masking support v2
Hi, I'm sorry that I couldn't reply you sooner. Pavel Machek wrote: Okay, I'll adopt your idea in the next version. I'm going to provide the proc entry as follows: (1) /proc/pid/core_flags/flags (2) /proc/pid/core_flags/omit_anon_shared (1) is the same as current core_flags. It is for expert users. (2) corresponds to one bit in (1). If (2) is set to 1, anonymous shared memory of the process is never dumped. Now, that's what I call an ugly interface. I considered for a while, and then I decided not to use the above-stated interfaces. Instead, I'll create just one proc entry to access to one core dump flag: /proc/pid/coredump_omit_anonymous_shared I think it is simple enough. Would you think it is still ugly? Can we simply add ulimit with boolean value, that says dump anon_shared... or not? It will be simpler and faster, because you'll not need locking. Yes, using ulimit will be simpler and faster, but less flexible. The core dump flags can be changed only before running the program. If the user modifies the program, the user will be able to change the flags anytime. But the user can't always modify the program. I need the ability to change the core dump flags anytime. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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 0/4] coredump: core dump masking support v2
Hi! Can we simply add ulimit with boolean value, that says dump anon_shared... or not? It will be simpler and faster, because you'll not need locking. Yes, using ulimit will be simpler and faster, but less flexible. It is prefered in this case. The core dump flags can be changed only before running the program. If the user modifies the program, the user will be able to change the flags anytime. But the user can't always modify the program. You can do ulimit then exec from wrapper. I need the ability to change the core dump flags anytime. Then maybe right solution is to extend _ulimit_ to change anything anytime. But that's definitely separate patch. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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 0/4] coredump: core dump masking support v2
Hi! > >>>Can you make this a little more transparent? Having a magic bitmask does > >>>not seem like the best way to do stuff. Could you maybe make a core_flags > >>>directory with a seperate file for each flag. It could still map to a > >>>single field in the mm, but be broken out for the proc filesystem. > >> > >>It seems to be one of the good enhancement idea, thanks.:-) > >>But currently, there is only one flag. So we had better keep this simple > >>implementation until someone requests to add a new flag. > > > > If that is the case, can we rename the file from core_flags to something > > more descriptive like dump_core_skip_anonymous_mappings. The name > > is a wild suggestion, the renaming does seem fairly important to me. > > Remember once you get this in, changing the name will be fairly difficult > > as admin tools and documentation will adopt the name. These are usually > > cases where it is better to do it right the first time. > > Okay, I'll adopt your idea in the next version. > I'm going to provide the proc entry as follows: > > (1) /proc//core_flags/flags > (2) /proc//core_flags/omit_anon_shared > > (1) is the same as current core_flags. It is for expert users. > (2) corresponds to one bit in (1). > If (2) is set to 1, anonymous shared memory of the process is never > dumped. Now, that's what I call an ugly interface. Can we simply add ulimit with boolean value, that says dump anon_shared... or not? It will be simpler and faster, because you'll not need locking. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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 0/4] coredump: core dump masking support v2
Hi! Can you make this a little more transparent? Having a magic bitmask does not seem like the best way to do stuff. Could you maybe make a core_flags directory with a seperate file for each flag. It could still map to a single field in the mm, but be broken out for the proc filesystem. It seems to be one of the good enhancement idea, thanks.:-) But currently, there is only one flag. So we had better keep this simple implementation until someone requests to add a new flag. If that is the case, can we rename the file from core_flags to something more descriptive like dump_core_skip_anonymous_mappings. The name is a wild suggestion, the renaming does seem fairly important to me. Remember once you get this in, changing the name will be fairly difficult as admin tools and documentation will adopt the name. These are usually cases where it is better to do it right the first time. Okay, I'll adopt your idea in the next version. I'm going to provide the proc entry as follows: (1) /proc/pid/core_flags/flags (2) /proc/pid/core_flags/omit_anon_shared (1) is the same as current core_flags. It is for expert users. (2) corresponds to one bit in (1). If (2) is set to 1, anonymous shared memory of the process is never dumped. Now, that's what I call an ugly interface. Can we simply add ulimit with boolean value, that says dump anon_shared... or not? It will be simpler and faster, because you'll not need locking. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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 0/4] coredump: core dump masking support v2
Hi, Robin Holt wrote: >>>Can you make this a little more transparent? Having a magic bitmask does >>>not seem like the best way to do stuff. Could you maybe make a core_flags >>>directory with a seperate file for each flag. It could still map to a >>>single field in the mm, but be broken out for the proc filesystem. >> >>It seems to be one of the good enhancement idea, thanks.:-) >>But currently, there is only one flag. So we had better keep this simple >>implementation until someone requests to add a new flag. > > If that is the case, can we rename the file from core_flags to something > more descriptive like dump_core_skip_anonymous_mappings. The name > is a wild suggestion, the renaming does seem fairly important to me. > Remember once you get this in, changing the name will be fairly difficult > as admin tools and documentation will adopt the name. These are usually > cases where it is better to do it right the first time. Okay, I'll adopt your idea in the next version. I'm going to provide the proc entry as follows: (1) /proc//core_flags/flags (2) /proc//core_flags/omit_anon_shared (1) is the same as current core_flags. It is for expert users. (2) corresponds to one bit in (1). If (2) is set to 1, anonymous shared memory of the process is never dumped. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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 0/4] coredump: core dump masking support v2
Hi, Robin Holt wrote: Can you make this a little more transparent? Having a magic bitmask does not seem like the best way to do stuff. Could you maybe make a core_flags directory with a seperate file for each flag. It could still map to a single field in the mm, but be broken out for the proc filesystem. It seems to be one of the good enhancement idea, thanks.:-) But currently, there is only one flag. So we had better keep this simple implementation until someone requests to add a new flag. If that is the case, can we rename the file from core_flags to something more descriptive like dump_core_skip_anonymous_mappings. The name is a wild suggestion, the renaming does seem fairly important to me. Remember once you get this in, changing the name will be fairly difficult as admin tools and documentation will adopt the name. These are usually cases where it is better to do it right the first time. Okay, I'll adopt your idea in the next version. I'm going to provide the proc entry as follows: (1) /proc/pid/core_flags/flags (2) /proc/pid/core_flags/omit_anon_shared (1) is the same as current core_flags. It is for expert users. (2) corresponds to one bit in (1). If (2) is set to 1, anonymous shared memory of the process is never dumped. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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 0/4] coredump: core dump masking support v2
On Tue, Jan 30, 2007 at 04:36:34PM +0900, Kawai, Hidehiro wrote: > Hi Robin, > > Robin Holt wrote: > > Can you make this a little more transparent? Having a magic bitmask does > > not seem like the best way to do stuff. Could you maybe make a core_flags > > directory with a seperate file for each flag. It could still map to a > > single field in the mm, but be broken out for the proc filesystem. > > It seems to be one of the good enhancement idea, thanks.:-) > But currently, there is only one flag. So we had better keep this simple > implementation until someone requests to add a new flag. If that is the case, can we rename the file from core_flags to something more descriptive like dump_core_skip_anonymous_mappings. The name is a wild suggestion, the renaming does seem fairly important to me. Remember once you get this in, changing the name will be fairly difficult as admin tools and documentation will adopt the name. These are usually cases where it is better to do it right the first time. Thanks, Robin - 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 0/4] coredump: core dump masking support v2
On Tue, Jan 30, 2007 at 04:36:34PM +0900, Kawai, Hidehiro wrote: Hi Robin, Robin Holt wrote: Can you make this a little more transparent? Having a magic bitmask does not seem like the best way to do stuff. Could you maybe make a core_flags directory with a seperate file for each flag. It could still map to a single field in the mm, but be broken out for the proc filesystem. It seems to be one of the good enhancement idea, thanks.:-) But currently, there is only one flag. So we had better keep this simple implementation until someone requests to add a new flag. If that is the case, can we rename the file from core_flags to something more descriptive like dump_core_skip_anonymous_mappings. The name is a wild suggestion, the renaming does seem fairly important to me. Remember once you get this in, changing the name will be fairly difficult as admin tools and documentation will adopt the name. These are usually cases where it is better to do it right the first time. Thanks, Robin - 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 0/4] coredump: core dump masking support v2
Hi Robin, Robin Holt wrote: > Can you make this a little more transparent? Having a magic bitmask does > not seem like the best way to do stuff. Could you maybe make a core_flags > directory with a seperate file for each flag. It could still map to a > single field in the mm, but be broken out for the proc filesystem. It seems to be one of the good enhancement idea, thanks.:-) But currently, there is only one flag. So we had better keep this simple implementation until someone requests to add a new flag. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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 0/4] coredump: core dump masking support v2
Hi Robin, Robin Holt wrote: Can you make this a little more transparent? Having a magic bitmask does not seem like the best way to do stuff. Could you maybe make a core_flags directory with a seperate file for each flag. It could still map to a single field in the mm, but be broken out for the proc filesystem. It seems to be one of the good enhancement idea, thanks.:-) But currently, there is only one flag. So we had better keep this simple implementation until someone requests to add a new flag. Thanks, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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 0/4] coredump: core dump masking support v2
On Fri, Jan 26, 2007 at 11:05:07PM +0900, Kawai, Hidehiro wrote: > You can specify memory segment types you don't want to dump via > /proc//core_flags file, which is provided per process. > This file represents a set of flags, but currently, only bit 0 is > available. If bit 0 is set, the kernel core dump routine doesn't > dump anonymous shared memory segments, which includes IPC shared > memory and some of mmap(2)'ed memory. Can you make this a little more transparent? Having a magic bitmask does not seem like the best way to do stuff. Could you maybe make a core_flags directory with a seperate file for each flag. It could still map to a single field in the mm, but be broken out for the proc filesystem. I can certainly see the value of this for our customers. We have some customers that run jobs in the 1-2TB range. Most of those customers have always had coredumps disabled and just rely upon being able to rerun the application and have MPI drop them into a debugger. Thanks, Robin - 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/
[PATCH 0/4] coredump: core dump masking support v2
Hi, This patch series is version 2 of the core dump masking feature, which enables you to specify the memory segment types you don't want to dump into a core file. In this version, the setting for which memory segment types are dumped is stored as a bit field and placed next to `dumpable' bit field in mm_struct. Writing to these two bit fields can cause race condition, so I use a global spin lock to protect them from write-write race. In consideration of security, I adds a sysctl parameter to enable/disable this feature. This patch series can be applied against 2.6.20-rc4-mm1. The supported core file formats are ELF and ELF-FDPIC. ELF has been tested, but ELF-FDPIC has not been build and tested because I don't have the test environment. Description: You can specify memory segment types you don't want to dump via /proc//core_flags file, which is provided per process. This file represents a set of flags, but currently, only bit 0 is available. If bit 0 is set, the kernel core dump routine doesn't dump anonymous shared memory segments, which includes IPC shared memory and some of mmap(2)'ed memory. System administrator can enable/disable these flags one by one via /proc/sys/kernel/core_flags_enable file. The default value is 1. This means that bit 0 in core_flags is effective. Background: Some software programs share huge memory among hundreds of processes. If a failure occurs on one of these processes, they can be signaled by a monitoring process to generate core files and restart the service. However, it can develop into a system-wide failure such as system slow down for a long time and disk space shortage because the total size of the core files is very huge! To avoid the above situation we can limit the core file size by setrlimit(2) or ulimit(1). But this method can lose important data such as stack because core dumping is terminated halfway. So I suggest keeping shared memory segments from being dumped for particular processes. Because the shared memory attached to processes is common in them, we don't need to dump the shared memory every time. Usage: If you don't want to dump all shared memory segments attached to pid 1234, set the bit 0 of the process's core_flags to 1: $ echo 1 > /proc/1234/core_flags Additionally, you can check its hexadecimal value by reading the file: $ cat /proc/1234/core_flags 0001 When a new process is created, the process inherits the core_flags setting from its parent. It is useful to set the core_flags before the program runs. For example: $ echo 1 > /proc/self/core_flags $ ./some_program ChangeLog: v2: - rename `coremask' to `core_flags' - change `core_flags' member in mm_struct to a bit field next to `dumpable' - introduce a global spin lock to protect adjacent two bit fields (core_flags and dumpable) from race condition - fix a bug that the generated core file can be corrupted when core dumping and updating core_flags occur concurrently - add kernel.core_flags_enable sysctl parameter to enable/disable flags in /proc//core_flags - support ELF-FDPIC binary format, but not tested v1: http://lkml.org/lkml/2006/12/13/17 -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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/
[PATCH 0/4] coredump: core dump masking support v2
Hi, This patch series is version 2 of the core dump masking feature, which enables you to specify the memory segment types you don't want to dump into a core file. In this version, the setting for which memory segment types are dumped is stored as a bit field and placed next to `dumpable' bit field in mm_struct. Writing to these two bit fields can cause race condition, so I use a global spin lock to protect them from write-write race. In consideration of security, I adds a sysctl parameter to enable/disable this feature. This patch series can be applied against 2.6.20-rc4-mm1. The supported core file formats are ELF and ELF-FDPIC. ELF has been tested, but ELF-FDPIC has not been build and tested because I don't have the test environment. Description: You can specify memory segment types you don't want to dump via /proc/pid/core_flags file, which is provided per process. This file represents a set of flags, but currently, only bit 0 is available. If bit 0 is set, the kernel core dump routine doesn't dump anonymous shared memory segments, which includes IPC shared memory and some of mmap(2)'ed memory. System administrator can enable/disable these flags one by one via /proc/sys/kernel/core_flags_enable file. The default value is 1. This means that bit 0 in core_flags is effective. Background: Some software programs share huge memory among hundreds of processes. If a failure occurs on one of these processes, they can be signaled by a monitoring process to generate core files and restart the service. However, it can develop into a system-wide failure such as system slow down for a long time and disk space shortage because the total size of the core files is very huge! To avoid the above situation we can limit the core file size by setrlimit(2) or ulimit(1). But this method can lose important data such as stack because core dumping is terminated halfway. So I suggest keeping shared memory segments from being dumped for particular processes. Because the shared memory attached to processes is common in them, we don't need to dump the shared memory every time. Usage: If you don't want to dump all shared memory segments attached to pid 1234, set the bit 0 of the process's core_flags to 1: $ echo 1 /proc/1234/core_flags Additionally, you can check its hexadecimal value by reading the file: $ cat /proc/1234/core_flags 0001 When a new process is created, the process inherits the core_flags setting from its parent. It is useful to set the core_flags before the program runs. For example: $ echo 1 /proc/self/core_flags $ ./some_program ChangeLog: v2: - rename `coremask' to `core_flags' - change `core_flags' member in mm_struct to a bit field next to `dumpable' - introduce a global spin lock to protect adjacent two bit fields (core_flags and dumpable) from race condition - fix a bug that the generated core file can be corrupted when core dumping and updating core_flags occur concurrently - add kernel.core_flags_enable sysctl parameter to enable/disable flags in /proc/pid/core_flags - support ELF-FDPIC binary format, but not tested v1: http://lkml.org/lkml/2006/12/13/17 -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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 0/4] coredump: core dump masking support v2
On Fri, Jan 26, 2007 at 11:05:07PM +0900, Kawai, Hidehiro wrote: You can specify memory segment types you don't want to dump via /proc/pid/core_flags file, which is provided per process. This file represents a set of flags, but currently, only bit 0 is available. If bit 0 is set, the kernel core dump routine doesn't dump anonymous shared memory segments, which includes IPC shared memory and some of mmap(2)'ed memory. Can you make this a little more transparent? Having a magic bitmask does not seem like the best way to do stuff. Could you maybe make a core_flags directory with a seperate file for each flag. It could still map to a single field in the mm, but be broken out for the proc filesystem. I can certainly see the value of this for our customers. We have some customers that run jobs in the 1-2TB range. Most of those customers have always had coredumps disabled and just rely upon being able to rerun the application and have MPI drop them into a debugger. Thanks, Robin - 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/
