Re: [PATCH 0/4] coredump: core dump masking support v4
On Wed, 28 Mar 2007 21:37:07 +0900 "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote: > > Because other people might (reasonably) wish to omit anonymous memory, > > or private mappings, or file-backed VMAs, or whatever. > > > > So maybe /proc/pid/coredump_omit_anon_shared should become > > /proc/pid/core_dumpfilter, which is a carefully documented bitmask. > > There are people who wish to dump VMAs which are not dumped by default. > Taking this into account, some bits of core_dumpfilter will be set by > default. This means users have to be aware of the default bitmask > when they change the bitmask. Perhaps changing the bitmask requires > 3 steps: > > 1. read the default bitmask > 2. change bits of the mask > 3. write it to the proc entry > > So I think it is better if we provide /proc/pid/core_flags (default: > all bits are 0) instead of core_dumpfilter. With this interface, > users who use only one bit of the bitmask (this will be a common case) > just have to write 2^n to the proc entry. It takes only one step: > > 1. write a value to the proc entry > > If we can implement at the same cost, core_flags will be better > because it is useful for users. What would you think about that? > It sounds unnecessarily complex, and unnecessarily different from our normal expectations of /proc files. And the value we read differs from the value we wrote... I think having a non-zero default will be fine. > > By the way, Robin Holt wrote as follows: > > > 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. > > Do you think Robin's suggestion is acceptable? Marginal, I think. This is not likely to be a field which a lot of people modify a lot of times. Those few people who need to work with this can afford to look the values up in the documentation while writing their script. And it requires a distressingly large amount of code to implement a /proc file. Perhaps in this situation the code can be shared. otoh, why is it a /proc thing at all? unsigned long sys_set_corefile_filter(unsigned long enable_mask); unsigned long sys_clear_corefile_filter(unsigned long enable_mask); would be better? - 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 v4
Hi, Thank you for your kind comments. I'm sorry for my late reply. Andrew Morton wrote: > On Fri, 02 Mar 2007 13:41:30 +0900 > "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote: > >>This patch series is version 4 of the core dump masking feature, >>which provides a per-process flag not to dump anonymous shared >>memory segments. > > First up, please convince us that this problem cannot be solved in > userspace. > Note that we now support dumping core over a pipe to a > userspace application which can perform filtering such as this (see > Documentation/sysctl/kernel.txt:core_pattern). I understand. Thank you for your suggestion. I'll reply about it in another mail, but it may take a few days. > Assuming that your argument is successful... > > - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is > there, I believe, to handle the case where a coredump is presently in > progress. We don't want to change the filtering rule while the dump is > happening. > > What I suggest you do instead is to take a copy of > mm->coredump_omit_anon_shared into a local variable with one single read > per coredump. Pass that local down into all the callees which need to > see it. That way, no locking is needed. Previous v3 patchset does what you suggest, and here are links to the patches: [PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory http://lkml.org/lkml/2007/2/16/156 [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory http://lkml.org/lkml/2007/2/16/157 However, there was an opposite opinion. To pass the flag status, I added omit_anon_shared argument to elf_fdpic_dump_segments(). Then, David pointed that the argument was unncecessary, because the function also receives mm_struct *mm which includes coredump_omit_anon_shared. But mm->coredump_omit_anon_shared can be changed while core dumping, and it may causes the core file to be corrupted. So in v4 patchset I used r/w semaphore to prevent mm->coredump_omit_anon_shared from being changed. If I add an addtional argument to elf_fdpic_dump_segments() again, I have to explain it to David. I'll tell him that removing mm argument from the function will be a solution since it refers current->mm directly and the mm argument is never used. > - These games we're playing with the atomicity of the bitfields in the > mm_struct need to go away. > > First up, please prepare a standalone patch which removes > mm_struct.dumpable and adds `unsigned long mm_struct.flags'. Include a > comment telling people that they must use atomic bitops (set_bit, > clear_bit) on > mm_struct.flags. OK. I'll do it in the next version. > - Finally, the code as you have it here is very specific to your specific > requirement: don't dump shared memory segments. > > But if we're going to implement in-kernel core-dump filtering of this > nature, we should design it extensibly, even if we don't actually > implement those extensions at this time. I understood. Since I had done so initially, I'll revert it to. > Because other people might (reasonably) wish to omit anonymous memory, > or private mappings, or file-backed VMAs, or whatever. > > So maybe /proc/pid/coredump_omit_anon_shared should become > /proc/pid/core_dumpfilter, which is a carefully documented bitmask. There are people who wish to dump VMAs which are not dumped by default. Taking this into account, some bits of core_dumpfilter will be set by default. This means users have to be aware of the default bitmask when they change the bitmask. Perhaps changing the bitmask requires 3 steps: 1. read the default bitmask 2. change bits of the mask 3. write it to the proc entry So I think it is better if we provide /proc/pid/core_flags (default: all bits are 0) instead of core_dumpfilter. With this interface, users who use only one bit of the bitmask (this will be a common case) just have to write 2^n to the proc entry. It takes only one step: 1. write a value to the proc entry If we can implement at the same cost, core_flags will be better because it is useful for users. What would you think about that? By the way, Robin Holt wrote as follows: > 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. Do you think Robin's suggestion is acceptable? Best regards, -- 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 v4
Hi, Thank you for your kind comments. I'm sorry for my late reply. Andrew Morton wrote: On Fri, 02 Mar 2007 13:41:30 +0900 Kawai, Hidehiro [EMAIL PROTECTED] wrote: This patch series is version 4 of the core dump masking feature, which provides a per-process flag not to dump anonymous shared memory segments. First up, please convince us that this problem cannot be solved in userspace. Note that we now support dumping core over a pipe to a userspace application which can perform filtering such as this (see Documentation/sysctl/kernel.txt:core_pattern). I understand. Thank you for your suggestion. I'll reply about it in another mail, but it may take a few days. Assuming that your argument is successful... - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is there, I believe, to handle the case where a coredump is presently in progress. We don't want to change the filtering rule while the dump is happening. What I suggest you do instead is to take a copy of mm-coredump_omit_anon_shared into a local variable with one single read per coredump. Pass that local down into all the callees which need to see it. That way, no locking is needed. Previous v3 patchset does what you suggest, and here are links to the patches: [PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory http://lkml.org/lkml/2007/2/16/156 [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory http://lkml.org/lkml/2007/2/16/157 However, there was an opposite opinion. To pass the flag status, I added omit_anon_shared argument to elf_fdpic_dump_segments(). Then, David pointed that the argument was unncecessary, because the function also receives mm_struct *mm which includes coredump_omit_anon_shared. But mm-coredump_omit_anon_shared can be changed while core dumping, and it may causes the core file to be corrupted. So in v4 patchset I used r/w semaphore to prevent mm-coredump_omit_anon_shared from being changed. If I add an addtional argument to elf_fdpic_dump_segments() again, I have to explain it to David. I'll tell him that removing mm argument from the function will be a solution since it refers current-mm directly and the mm argument is never used. - These games we're playing with the atomicity of the bitfields in the mm_struct need to go away. First up, please prepare a standalone patch which removes mm_struct.dumpable and adds `unsigned long mm_struct.flags'. Include a comment telling people that they must use atomic bitops (set_bit, clear_bit) on mm_struct.flags. OK. I'll do it in the next version. - Finally, the code as you have it here is very specific to your specific requirement: don't dump shared memory segments. But if we're going to implement in-kernel core-dump filtering of this nature, we should design it extensibly, even if we don't actually implement those extensions at this time. I understood. Since I had done so initially, I'll revert it to. Because other people might (reasonably) wish to omit anonymous memory, or private mappings, or file-backed VMAs, or whatever. So maybe /proc/pid/coredump_omit_anon_shared should become /proc/pid/core_dumpfilter, which is a carefully documented bitmask. There are people who wish to dump VMAs which are not dumped by default. Taking this into account, some bits of core_dumpfilter will be set by default. This means users have to be aware of the default bitmask when they change the bitmask. Perhaps changing the bitmask requires 3 steps: 1. read the default bitmask 2. change bits of the mask 3. write it to the proc entry So I think it is better if we provide /proc/pid/core_flags (default: all bits are 0) instead of core_dumpfilter. With this interface, users who use only one bit of the bitmask (this will be a common case) just have to write 2^n to the proc entry. It takes only one step: 1. write a value to the proc entry If we can implement at the same cost, core_flags will be better because it is useful for users. What would you think about that? By the way, Robin Holt wrote as follows: 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. Do you think Robin's suggestion is acceptable? Best regards, -- 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 v4
On Wed, 28 Mar 2007 21:37:07 +0900 Kawai, Hidehiro [EMAIL PROTECTED] wrote: Because other people might (reasonably) wish to omit anonymous memory, or private mappings, or file-backed VMAs, or whatever. So maybe /proc/pid/coredump_omit_anon_shared should become /proc/pid/core_dumpfilter, which is a carefully documented bitmask. There are people who wish to dump VMAs which are not dumped by default. Taking this into account, some bits of core_dumpfilter will be set by default. This means users have to be aware of the default bitmask when they change the bitmask. Perhaps changing the bitmask requires 3 steps: 1. read the default bitmask 2. change bits of the mask 3. write it to the proc entry So I think it is better if we provide /proc/pid/core_flags (default: all bits are 0) instead of core_dumpfilter. With this interface, users who use only one bit of the bitmask (this will be a common case) just have to write 2^n to the proc entry. It takes only one step: 1. write a value to the proc entry If we can implement at the same cost, core_flags will be better because it is useful for users. What would you think about that? It sounds unnecessarily complex, and unnecessarily different from our normal expectations of /proc files. And the value we read differs from the value we wrote... I think having a non-zero default will be fine. By the way, Robin Holt wrote as follows: 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. Do you think Robin's suggestion is acceptable? Marginal, I think. This is not likely to be a field which a lot of people modify a lot of times. Those few people who need to work with this can afford to look the values up in the documentation while writing their script. And it requires a distressingly large amount of code to implement a /proc file. Perhaps in this situation the code can be shared. otoh, why is it a /proc thing at all? unsigned long sys_set_corefile_filter(unsigned long enable_mask); unsigned long sys_clear_corefile_filter(unsigned long enable_mask); would be better? - 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 v4
Hi, Thank you for your kind comments. I'm still discussing the answer with my senior colleagues, so please wait a few days. I think I can reply at the beginning of next week. Best regards, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory Andrew Morton wrote: > On Fri, 02 Mar 2007 13:41:30 +0900 > "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote: > > >>This patch series is version 4 of the core dump masking feature, >>which provides a per-process flag not to dump anonymous shared >>memory segments. > > > First up, please convince us that this problem cannot be solved in > userspace. Note that we now support dumping core over a pipe to a > userspace application which can perform filtering such as this (see > Documentation/sysctl/kernel.txt:core_pattern). > > > Assuming that your argument is successful... > > - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is > there, I believe, to handle the case where a coredump is presently in > progress. We don't want to change the filtering rule while the dump is > happening. > > What I suggest you do instead is to take a copy of > mm->coredump_omit_anon_shared into a local variable with one single read > per coredump. Pass that local down into all the callees which need to > see it. That way, no locking is needed. > > - These games we're playing with the atomicity of the bitfields in the > mm_struct need to go away. > > First up, please prepare a standalone patch which removes > mm_struct.dumpable and adds `unsigned long mm_struct.flags'. Include a > comment telling people that they must use atomic bitops (set_bit, > clear_bit) on > mm_struct.flags. > > Reimplement the current three-value dumpable silliness using two or > three separate flags in mm_struct.flags. Of course, this design means > that there will be tiny timing windows where the value of these two or > three flags have intermediate, invalid states. Please take care of those > little windows and document how you did so. I expect a suitable approach > would be to set and clear the flags in a suitable order, so that if a > race _does_ happen, the results are benign. > > - Once that is done, you're ready to think about your new functionality. > Start out with > > #define MM_FLAG_COREDUMP_OMIT_ANON_SHARED (1 << 3) > > or whatever, and it all becomes easy. > > - Finally, the code as you have it here is very specific to your specific > requirement: don't dump shared memory segments. > > But if we're going to implement in-kernel core-dump filtering of this > nature, we should design it extensibly, even if we don't actually > implement those extensions at this time. > > Because other people might (reasonably) wish to omit anonymous memory, > or private mappings, or file-backed VMAs, or whatever. > > So maybe /proc/pid/coredump_omit_anon_shared should become > /proc/pid/core_dumpfilter, which is a carefully documented bitmask. > > - 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 v4
Hi, Thank you for your kind comments. I'm still discussing the answer with my senior colleagues, so please wait a few days. I think I can reply at the beginning of next week. Best regards, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory Andrew Morton wrote: On Fri, 02 Mar 2007 13:41:30 +0900 Kawai, Hidehiro [EMAIL PROTECTED] wrote: This patch series is version 4 of the core dump masking feature, which provides a per-process flag not to dump anonymous shared memory segments. First up, please convince us that this problem cannot be solved in userspace. Note that we now support dumping core over a pipe to a userspace application which can perform filtering such as this (see Documentation/sysctl/kernel.txt:core_pattern). Assuming that your argument is successful... - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is there, I believe, to handle the case where a coredump is presently in progress. We don't want to change the filtering rule while the dump is happening. What I suggest you do instead is to take a copy of mm-coredump_omit_anon_shared into a local variable with one single read per coredump. Pass that local down into all the callees which need to see it. That way, no locking is needed. - These games we're playing with the atomicity of the bitfields in the mm_struct need to go away. First up, please prepare a standalone patch which removes mm_struct.dumpable and adds `unsigned long mm_struct.flags'. Include a comment telling people that they must use atomic bitops (set_bit, clear_bit) on mm_struct.flags. Reimplement the current three-value dumpable silliness using two or three separate flags in mm_struct.flags. Of course, this design means that there will be tiny timing windows where the value of these two or three flags have intermediate, invalid states. Please take care of those little windows and document how you did so. I expect a suitable approach would be to set and clear the flags in a suitable order, so that if a race _does_ happen, the results are benign. - Once that is done, you're ready to think about your new functionality. Start out with #define MM_FLAG_COREDUMP_OMIT_ANON_SHARED (1 3) or whatever, and it all becomes easy. - Finally, the code as you have it here is very specific to your specific requirement: don't dump shared memory segments. But if we're going to implement in-kernel core-dump filtering of this nature, we should design it extensibly, even if we don't actually implement those extensions at this time. Because other people might (reasonably) wish to omit anonymous memory, or private mappings, or file-backed VMAs, or whatever. So maybe /proc/pid/coredump_omit_anon_shared should become /proc/pid/core_dumpfilter, which is a carefully documented bitmask. - 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 v4
On Fri, 02 Mar 2007 13:41:30 +0900 "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote: > This patch series is version 4 of the core dump masking feature, > which provides a per-process flag not to dump anonymous shared > memory segments. First up, please convince us that this problem cannot be solved in userspace. Note that we now support dumping core over a pipe to a userspace application which can perform filtering such as this (see Documentation/sysctl/kernel.txt:core_pattern). Assuming that your argument is successful... - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is there, I believe, to handle the case where a coredump is presently in progress. We don't want to change the filtering rule while the dump is happening. What I suggest you do instead is to take a copy of mm->coredump_omit_anon_shared into a local variable with one single read per coredump. Pass that local down into all the callees which need to see it. That way, no locking is needed. - These games we're playing with the atomicity of the bitfields in the mm_struct need to go away. First up, please prepare a standalone patch which removes mm_struct.dumpable and adds `unsigned long mm_struct.flags'. Include a comment telling people that they must use atomic bitops (set_bit, clear_bit) on mm_struct.flags. Reimplement the current three-value dumpable silliness using two or three separate flags in mm_struct.flags. Of course, this design means that there will be tiny timing windows where the value of these two or three flags have intermediate, invalid states. Please take care of those little windows and document how you did so. I expect a suitable approach would be to set and clear the flags in a suitable order, so that if a race _does_ happen, the results are benign. - Once that is done, you're ready to think about your new functionality. Start out with #define MM_FLAG_COREDUMP_OMIT_ANON_SHARED (1 << 3) or whatever, and it all becomes easy. - Finally, the code as you have it here is very specific to your specific requirement: don't dump shared memory segments. But if we're going to implement in-kernel core-dump filtering of this nature, we should design it extensibly, even if we don't actually implement those extensions at this time. Because other people might (reasonably) wish to omit anonymous memory, or private mappings, or file-backed VMAs, or whatever. So maybe /proc/pid/coredump_omit_anon_shared should become /proc/pid/core_dumpfilter, which is a carefully documented bitmask. - 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 v4
On Fri, 02 Mar 2007 13:41:30 +0900 Kawai, Hidehiro [EMAIL PROTECTED] wrote: This patch series is version 4 of the core dump masking feature, which provides a per-process flag not to dump anonymous shared memory segments. First up, please convince us that this problem cannot be solved in userspace. Note that we now support dumping core over a pipe to a userspace application which can perform filtering such as this (see Documentation/sysctl/kernel.txt:core_pattern). Assuming that your argument is successful... - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is there, I believe, to handle the case where a coredump is presently in progress. We don't want to change the filtering rule while the dump is happening. What I suggest you do instead is to take a copy of mm-coredump_omit_anon_shared into a local variable with one single read per coredump. Pass that local down into all the callees which need to see it. That way, no locking is needed. - These games we're playing with the atomicity of the bitfields in the mm_struct need to go away. First up, please prepare a standalone patch which removes mm_struct.dumpable and adds `unsigned long mm_struct.flags'. Include a comment telling people that they must use atomic bitops (set_bit, clear_bit) on mm_struct.flags. Reimplement the current three-value dumpable silliness using two or three separate flags in mm_struct.flags. Of course, this design means that there will be tiny timing windows where the value of these two or three flags have intermediate, invalid states. Please take care of those little windows and document how you did so. I expect a suitable approach would be to set and clear the flags in a suitable order, so that if a race _does_ happen, the results are benign. - Once that is done, you're ready to think about your new functionality. Start out with #define MM_FLAG_COREDUMP_OMIT_ANON_SHARED (1 3) or whatever, and it all becomes easy. - Finally, the code as you have it here is very specific to your specific requirement: don't dump shared memory segments. But if we're going to implement in-kernel core-dump filtering of this nature, we should design it extensibly, even if we don't actually implement those extensions at this time. Because other people might (reasonably) wish to omit anonymous memory, or private mappings, or file-backed VMAs, or whatever. So maybe /proc/pid/coredump_omit_anon_shared should become /proc/pid/core_dumpfilter, which is a carefully documented bitmask. - 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 v4
Hi, This patch series is version 4 of the core dump masking feature, which provides a per-process flag not to dump anonymous shared memory segments. In the previous version, the flag value was passed around the core dump functions as an argument to use the same setting while dumping. In this version, instead of doing that, a r/w semaphore prevents the setting from being changed while dumping. This patch series can be applied against 2.6.20-mm2. The supported core file formats are ELF and ELF-FDPIC. ELF has been tested, but ELF-FDPIC has not been built and tested because I don't have the test environment. 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: Get all shared memory segments of pid 1234 not to dump: $ echo 1 > /proc/1234/coredump_omit_anonymous_shared When a new process is created, the process inherits the flag status from its parent. It is useful to set the core dump flags before the program runs. For example: $ echo 1 > /proc/self/coredump_omit_anonymous_shared $ ./some_program ChangeLog: v4: - in maydump(), retrieve the core dump setting from mm_struct directly, instead of its additional argument - writing to /proc//coredump_omit_anonymous_shared returns EBUSY while core dumping. v3: http://groups.google.com/group/linux.kernel/browse_frm/thread/706d2ae41c1cb2de/ - remove `/proc//core_flags' proc entry - add `/proc//coredump_anonymous_shared' as a named flag - remove kernel.core_flags_enable sysctl parameter v2: http://groups.google.com/group/linux.kernel/browse_frm/thread/cb254465971d4a42/ http://groups.google.com/group/linux.kernel/browse_frm/thread/da78f2702e06fa11/ - 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://groups.google.com/group/linux.kernel/browse_frm/thread/1381fc54d716e3e6/ -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory E-mail: [EMAIL PROTECTED] - 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 v4
Hi, This patch series is version 4 of the core dump masking feature, which provides a per-process flag not to dump anonymous shared memory segments. In the previous version, the flag value was passed around the core dump functions as an argument to use the same setting while dumping. In this version, instead of doing that, a r/w semaphore prevents the setting from being changed while dumping. This patch series can be applied against 2.6.20-mm2. The supported core file formats are ELF and ELF-FDPIC. ELF has been tested, but ELF-FDPIC has not been built and tested because I don't have the test environment. 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: Get all shared memory segments of pid 1234 not to dump: $ echo 1 /proc/1234/coredump_omit_anonymous_shared When a new process is created, the process inherits the flag status from its parent. It is useful to set the core dump flags before the program runs. For example: $ echo 1 /proc/self/coredump_omit_anonymous_shared $ ./some_program ChangeLog: v4: - in maydump(), retrieve the core dump setting from mm_struct directly, instead of its additional argument - writing to /proc/pid/coredump_omit_anonymous_shared returns EBUSY while core dumping. v3: http://groups.google.com/group/linux.kernel/browse_frm/thread/706d2ae41c1cb2de/ - remove `/proc/pid/core_flags' proc entry - add `/proc/pid/coredump_anonymous_shared' as a named flag - remove kernel.core_flags_enable sysctl parameter v2: http://groups.google.com/group/linux.kernel/browse_frm/thread/cb254465971d4a42/ http://groups.google.com/group/linux.kernel/browse_frm/thread/da78f2702e06fa11/ - 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://groups.google.com/group/linux.kernel/browse_frm/thread/1381fc54d716e3e6/ -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory E-mail: [EMAIL PROTECTED] - 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/
