Re: [PATCH] Thread core dumps for 2.4.4
Szaka- I would considier what you're suggesting to be a refinement on this patch. The first problem is to generate valid core dumps for all threads. Adding in policy decisions about which threads actually generate core files can be done later. Adam ? (I'm sorry, I've lost the mail with his full name) actually posted a patch a while back that only dumped core for the first faulting thread. The problem with this patch is that it didn't deal with the potential races between threads modifying the memory maps while the core dump was being generated. Also, this patch used a single system wide variable to make its policy decisions, this really needs to be a per-process decision. What I'd really like to see is some sort of rondezous capability where, when a fatal exception occurs, all the threads are halted, appropriate core dumps are generated, and then all the threads are resumed (to terminate or continue as appropriate). This is a bigger project that will require a little thought. On Sun, May 06, 2001 at 06:47:28PM +0200, Szabolcs Szakacsits wrote: > > On Thu, 3 May 2001, Don Dugger wrote: > > > The attached patch allows core dumps from thread processes in the 2.4.4 > > kernel. This patch is the same as the last one I sent out except it fixes > > the same bug that `kernel/fork.c' had with duplicate info in the `mm' > > structure, plus this patch has had more extensive testing. > > AFAIK Linux can't dump the threads to the same file as others but doing > it to different files looks a bit scary. How the system behaves when you > dump a heavy threaded app with a decent VM [i.e just think about a > bloatware instead of malicious code]? How will the developer know which > thread caused the fault? I've found dumping just the faulting thread is > enough about 100% of the cases especially because [on SMP] others can > run on and the dump is much more close to "garbage" then usuful info > from a debug point of view. > > Szaka -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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] Thread core dumps for 2.4.4
Szaka- I would considier what you're suggesting to be a refinement on this patch. The first problem is to generate valid core dumps for all threads. Adding in policy decisions about which threads actually generate core files can be done later. Adam ? (I'm sorry, I've lost the mail with his full name) actually posted a patch a while back that only dumped core for the first faulting thread. The problem with this patch is that it didn't deal with the potential races between threads modifying the memory maps while the core dump was being generated. Also, this patch used a single system wide variable to make its policy decisions, this really needs to be a per-process decision. What I'd really like to see is some sort of rondezous capability where, when a fatal exception occurs, all the threads are halted, appropriate core dumps are generated, and then all the threads are resumed (to terminate or continue as appropriate). This is a bigger project that will require a little thought. On Sun, May 06, 2001 at 06:47:28PM +0200, Szabolcs Szakacsits wrote: On Thu, 3 May 2001, Don Dugger wrote: The attached patch allows core dumps from thread processes in the 2.4.4 kernel. This patch is the same as the last one I sent out except it fixes the same bug that `kernel/fork.c' had with duplicate info in the `mm' structure, plus this patch has had more extensive testing. AFAIK Linux can't dump the threads to the same file as others but doing it to different files looks a bit scary. How the system behaves when you dump a heavy threaded app with a decent VM [i.e just think about a bloatware instead of malicious code]? How will the developer know which thread caused the fault? I've found dumping just the faulting thread is enough about 100% of the cases especially because [on SMP] others can run on and the dump is much more close to garbage then usuful info from a debug point of view. Szaka -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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] Thread core dumps for 2.4.4
The attached patch allows core dumps from thread processes in the 2.4.4
kernel. This patch is the same as the last one I sent out except it fixes
the same bug that `kernel/fork.c' had with duplicate info in the `mm'
structure, plus this patch has had more extensive testing.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
diff -aur linux-2.4.4-ref/fs/binfmt_aout.c linux/fs/binfmt_aout.c
--- linux-2.4.4-ref/fs/binfmt_aout.cMon Mar 19 13:34:56 2001
+++ linux/fs/binfmt_aout.c Wed May 2 15:50:42 2001
@@ -31,7 +31,8 @@
static int load_aout_binary(struct linux_binprm *, struct pt_regs * regs);
static int load_aout_library(struct file*);
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file);
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file *file, struct mm_struct * mm);
extern void dump_thread(struct pt_regs *, struct user *);
@@ -78,7 +79,8 @@
* dumping of the process results in another error..
*/
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file)
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
mm_segment_t fs;
int has_dumped = 0;
diff -aur linux-2.4.4-ref/fs/binfmt_elf.c linux/fs/binfmt_elf.c
--- linux-2.4.4-ref/fs/binfmt_elf.c Thu Apr 5 18:13:23 2001
+++ linux/fs/binfmt_elf.c Wed May 2 15:50:42 2001
@@ -56,7 +56,8 @@
* don't even try.
*/
#ifdef USE_ELF_CORE_DUMP
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file);
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm);
#else
#define elf_core_dump NULL
#endif
@@ -976,7 +977,8 @@
* and then they are actually written out. If we run out of core limit
* we just truncate.
*/
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file)
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
int has_dumped = 0;
mm_segment_t fs;
@@ -993,7 +995,7 @@
elf_fpregset_t fpu; /* NT_PRFPREG */
struct elf_prpsinfo psinfo; /* NT_PRPSINFO */
- segs = current->mm->map_count;
+ segs = mm->map_count;
#ifdef DEBUG
printk("elf_core_dump: %d segs %lu limit\n", segs, limit);
@@ -1153,7 +1155,7 @@
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
/* Write program headers for segments dump */
- for(vma = current->mm->mmap; vma != NULL; vma = vma->vm_next) {
+ for(vma = mm->mmap; vma != NULL; vma = vma->vm_next) {
struct elf_phdr phdr;
size_t sz;
@@ -1182,7 +1184,7 @@
DUMP_SEEK(dataoff);
- for(vma = current->mm->mmap; vma != NULL; vma = vma->vm_next) {
+ for(vma = mm->mmap; vma != NULL; vma = vma->vm_next) {
unsigned long addr;
if (!maydump(vma))
diff -aur linux-2.4.4-ref/fs/exec.c linux/fs/exec.c
--- linux-2.4.4-ref/fs/exec.c Thu Apr 26 15:11:29 2001
+++ linux/fs/exec.c Thu May 3 08:18:54 2001
@@ -923,16 +923,18 @@
int do_coredump(long signr, struct pt_regs * regs)
{
+ struct mm_struct *mm;
struct linux_binfmt * binfmt;
- char corename[6+sizeof(current->comm)];
+ char corename[6+sizeof(current->comm)+10];
struct file * file;
struct inode * inode;
+ int r;
lock_kernel();
binfmt = current->binfmt;
if (!binfmt || !binfmt->core_dump)
goto fail;
- if (!current->dumpable || atomic_read(>mm->mm_users) != 1)
+ if (!current->dumpable)
goto fail;
current->dumpable = 0;
if (current->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump)
@@ -944,6 +946,8 @@
#else
corename[4] = '\0';
#endif
+ if (atomic_read(>mm->mm_users) != 1)
+ sprintf([4], ".%d", current->pid);
file = filp_open(corename, O_CREAT | 2 | O_NOFOLLOW, 0600);
if (IS_ERR(file))
goto fail;
@@ -961,11 +965,42 @@
goto close_fail;
if (do_truncate(file->f_dentry, 0) != 0)
goto close_fail;
- if (!binfmt->core_dump(signr, regs, file))
+ /*
+* Copy the mm structure to avoid potential races with
+*other threads
+*/
+ if ((mm = kmem_cache_alloc(mm_cachep, SLAB_KERNEL)) == NULL)
goto close_fail;
+ memcpy(mm, current->mm, sizeof(*mm));
+
+ /* Clear new context for now */
+ memset(>context, 0, sizeof(mm->context));
+
+ if (!mm_init(mm)) {
+ kmem_cache_free(mm_cachep, mm);
+ goto close_fail;
+ }
+ down_write(>mm-
[PATCH] Thread core dumps for 2.4.4
The attached patch allows core dumps from thread processes in the 2.4.4
kernel. This patch is the same as the last one I sent out except it fixes
the same bug that `kernel/fork.c' had with duplicate info in the `mm'
structure, plus this patch has had more extensive testing.
--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
diff -aur linux-2.4.4-ref/fs/binfmt_aout.c linux/fs/binfmt_aout.c
--- linux-2.4.4-ref/fs/binfmt_aout.cMon Mar 19 13:34:56 2001
+++ linux/fs/binfmt_aout.c Wed May 2 15:50:42 2001
@@ -31,7 +31,8 @@
static int load_aout_binary(struct linux_binprm *, struct pt_regs * regs);
static int load_aout_library(struct file*);
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file);
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file *file, struct mm_struct * mm);
extern void dump_thread(struct pt_regs *, struct user *);
@@ -78,7 +79,8 @@
* dumping of the process results in another error..
*/
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file)
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
mm_segment_t fs;
int has_dumped = 0;
diff -aur linux-2.4.4-ref/fs/binfmt_elf.c linux/fs/binfmt_elf.c
--- linux-2.4.4-ref/fs/binfmt_elf.c Thu Apr 5 18:13:23 2001
+++ linux/fs/binfmt_elf.c Wed May 2 15:50:42 2001
@@ -56,7 +56,8 @@
* don't even try.
*/
#ifdef USE_ELF_CORE_DUMP
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file);
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm);
#else
#define elf_core_dump NULL
#endif
@@ -976,7 +977,8 @@
* and then they are actually written out. If we run out of core limit
* we just truncate.
*/
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file)
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
int has_dumped = 0;
mm_segment_t fs;
@@ -993,7 +995,7 @@
elf_fpregset_t fpu; /* NT_PRFPREG */
struct elf_prpsinfo psinfo; /* NT_PRPSINFO */
- segs = current-mm-map_count;
+ segs = mm-map_count;
#ifdef DEBUG
printk(elf_core_dump: %d segs %lu limit\n, segs, limit);
@@ -1153,7 +1155,7 @@
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
/* Write program headers for segments dump */
- for(vma = current-mm-mmap; vma != NULL; vma = vma-vm_next) {
+ for(vma = mm-mmap; vma != NULL; vma = vma-vm_next) {
struct elf_phdr phdr;
size_t sz;
@@ -1182,7 +1184,7 @@
DUMP_SEEK(dataoff);
- for(vma = current-mm-mmap; vma != NULL; vma = vma-vm_next) {
+ for(vma = mm-mmap; vma != NULL; vma = vma-vm_next) {
unsigned long addr;
if (!maydump(vma))
diff -aur linux-2.4.4-ref/fs/exec.c linux/fs/exec.c
--- linux-2.4.4-ref/fs/exec.c Thu Apr 26 15:11:29 2001
+++ linux/fs/exec.c Thu May 3 08:18:54 2001
@@ -923,16 +923,18 @@
int do_coredump(long signr, struct pt_regs * regs)
{
+ struct mm_struct *mm;
struct linux_binfmt * binfmt;
- char corename[6+sizeof(current-comm)];
+ char corename[6+sizeof(current-comm)+10];
struct file * file;
struct inode * inode;
+ int r;
lock_kernel();
binfmt = current-binfmt;
if (!binfmt || !binfmt-core_dump)
goto fail;
- if (!current-dumpable || atomic_read(current-mm-mm_users) != 1)
+ if (!current-dumpable)
goto fail;
current-dumpable = 0;
if (current-rlim[RLIMIT_CORE].rlim_cur binfmt-min_coredump)
@@ -944,6 +946,8 @@
#else
corename[4] = '\0';
#endif
+ if (atomic_read(current-mm-mm_users) != 1)
+ sprintf(corename[4], .%d, current-pid);
file = filp_open(corename, O_CREAT | 2 | O_NOFOLLOW, 0600);
if (IS_ERR(file))
goto fail;
@@ -961,11 +965,42 @@
goto close_fail;
if (do_truncate(file-f_dentry, 0) != 0)
goto close_fail;
- if (!binfmt-core_dump(signr, regs, file))
+ /*
+* Copy the mm structure to avoid potential races with
+*other threads
+*/
+ if ((mm = kmem_cache_alloc(mm_cachep, SLAB_KERNEL)) == NULL)
goto close_fail;
+ memcpy(mm, current-mm, sizeof(*mm));
+
+ /* Clear new context for now */
+ memset(mm-context, 0, sizeof(mm-context));
+
+ if (!mm_init(mm)) {
+ kmem_cache_free(mm_cachep, mm);
+ goto close_fail;
+ }
+ down_write(current-mm-mmap_sem);
+ r = dup_mmap(mm);
+ up_write(current-mm-mmap_sem);
+
+ /*
+* Add it to the mmlist after the parent
[PATCH] Bug in kernel/fork.c in 2.4.4 kernel
In working on thread core dumps I've stumbled across a minor bug in the generic `fork' code. The problem code is in routine `copy_mm' in `kernel/fork.c': /* Copy the current MM stuff.. */ memcpy(mm, oldmm, sizeof(*mm)); . . . if (retval) goto free_pt; /* * child gets a private LDT (if there was an LDT in the parent) */ copy_segments(tsk, mm); . . . free_pt: mmput(mm); The new `mm' doesn't get it's own private version of it's `context' field until after the call to `copy_segments'. At the `goto' the pointer `mm' points to a copy of the old `mm_struct', including a copy of the `context' field. `mmput' will call `release_segments' which will free the memory pointed to by the `context' field. Later, when `oldmm' is freed, the kernel will try to free the same memory twice - very bad. Admittedly, this will only occur on an obscure error condition but it should be fixed. The attached patch fixes the problem by zeroing out the `context' field immediately after the `mm' structure is copied. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 --- linux-2.4.4-ref/kernel/fork.c Thu Apr 26 07:11:17 2001 +++ linux/kernel/fork.c Wed May 2 14:39:38 2001 @@ -311,6 +311,10 @@ /* Copy the current MM stuff.. */ memcpy(mm, oldmm, sizeof(*mm)); + + /* Clear new context for now */ + memset(>context, 0, sizeof(mm->context)); + if (!mm_init(mm)) goto fail_nomem; - 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: Kernel doesn't create core for threads
Zdenek-
Yes, this is a known problem. I sent out a patch last month that
fixed this problem. Unfortunately, the patch caused some kernel
hangs that I just fixed today. I'm testing the fix now so expect
a new patch either this afternoon or tomorrow that will fix this.
On Wed, May 02, 2001 at 08:53:00PM +, Zdenek Kabelac wrote:
> Hello
>
> Looks to me like the latest 2.4.5-pre1 is not creating
> coredump for multithreaded aplications:
>
>
> $ ulimit -a
> core file size (blocks) unlimited
> data seg size (kbytes) unlimited
> file size (blocks) unlimited
> max locked memory (kbytes) unlimited
> max memory size (kbytes)unlimited
> open files 1024
> pipe size (512 bytes) 8
> stack size (kbytes) 8192
> cpu time (seconds) unlimited
> max user processes 6144
> virtual memory (kbytes) unlimited
>
> $ ./testcore
> Segmentation fault
>
>
> --- test program --
>
> #include
> #include
>
> #define TASKS 10
>
> void* thread(void* arg)
> {
> printf("yuk %s\n", 0x);
> return 0;
> }
>
> int main(int argc, char *argv[])
> {
> pthread_t task[TASKS];
> void* ret;
> int i = 0;
> for(i = 0; i < TASKS; i++)
> pthread_create([i], NULL, thread, 0);
> for(i = 0; i < TASKS; i++)
> pthread_join(task[i], );
>
> return 0;
> }
> ---
>
>
> for single threadad apps there is no problem:
> (just put printf after int i declaration)
> $ ./testcore
> Segmentation fault (core dumped)
>
> ---
>
> Am I doing something wrong ???
>
> Also for quite a long time Alan's AC patches were efictively locking
> my machine when threaded application was crashing - resolvin
> almost original behaviour solved this problem - but I like
> per-thread coredump - is there any special reason why this is still
> not present in the current 2.4.4 kernel as I can see this as quite
> usefull.
>
>
> bye
>
>
> [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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
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: Kernel doesn't create core for threads
Zdenek-
Yes, this is a known problem. I sent out a patch last month that
fixed this problem. Unfortunately, the patch caused some kernel
hangs that I just fixed today. I'm testing the fix now so expect
a new patch either this afternoon or tomorrow that will fix this.
On Wed, May 02, 2001 at 08:53:00PM +, Zdenek Kabelac wrote:
Hello
Looks to me like the latest 2.4.5-pre1 is not creating
coredump for multithreaded aplications:
$ ulimit -a
core file size (blocks) unlimited
data seg size (kbytes) unlimited
file size (blocks) unlimited
max locked memory (kbytes) unlimited
max memory size (kbytes)unlimited
open files 1024
pipe size (512 bytes) 8
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 6144
virtual memory (kbytes) unlimited
$ ./testcore
Segmentation fault
--- test program --
#include stdio.h
#include pthread.h
#define TASKS 10
void* thread(void* arg)
{
printf(yuk %s\n, 0x);
return 0;
}
int main(int argc, char *argv[])
{
pthread_t task[TASKS];
void* ret;
int i = 0;
for(i = 0; i TASKS; i++)
pthread_create(task[i], NULL, thread, 0);
for(i = 0; i TASKS; i++)
pthread_join(task[i], ret);
return 0;
}
---
for single threadad apps there is no problem:
(just put printf after int i declaration)
$ ./testcore
Segmentation fault (core dumped)
---
Am I doing something wrong ???
Also for quite a long time Alan's AC patches were efictively locking
my machine when threaded application was crashing - resolvin
almost original behaviour solved this problem - but I like
per-thread coredump - is there any special reason why this is still
not present in the current 2.4.4 kernel as I can see this as quite
usefull.
bye
[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/
--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
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] Bug in kernel/fork.c in 2.4.4 kernel
In working on thread core dumps I've stumbled across a minor bug in the generic `fork' code. The problem code is in routine `copy_mm' in `kernel/fork.c': /* Copy the current MM stuff.. */ memcpy(mm, oldmm, sizeof(*mm)); . . . if (retval) goto free_pt; /* * child gets a private LDT (if there was an LDT in the parent) */ copy_segments(tsk, mm); . . . free_pt: mmput(mm); The new `mm' doesn't get it's own private version of it's `context' field until after the call to `copy_segments'. At the `goto' the pointer `mm' points to a copy of the old `mm_struct', including a copy of the `context' field. `mmput' will call `release_segments' which will free the memory pointed to by the `context' field. Later, when `oldmm' is freed, the kernel will try to free the same memory twice - very bad. Admittedly, this will only occur on an obscure error condition but it should be fixed. The attached patch fixes the problem by zeroing out the `context' field immediately after the `mm' structure is copied. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 --- linux-2.4.4-ref/kernel/fork.c Thu Apr 26 07:11:17 2001 +++ linux/kernel/fork.c Wed May 2 14:39:38 2001 @@ -311,6 +311,10 @@ /* Copy the current MM stuff.. */ memcpy(mm, oldmm, sizeof(*mm)); + + /* Clear new context for now */ + memset(mm-context, 0, sizeof(mm-context)); + if (!mm_init(mm)) goto fail_nomem; - 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: Kernel hang on multi-threaded X process crash
Alan- I certainly care to fix it (since I wrote the patch). Since `aviplay' seems to be the easy way to trigger it I'll look into it. On Mon, Apr 23, 2001 at 04:40:12PM +0100, Alan Cox wrote: > > Both mozilla and aviplay (which are both multithreaded) trigger this - I > > haven't tried with xmms. Simpler programs like xclock or cat don't trigger > > it. > > Thanks. I'll revert the core dump stuff for 2.4.4-ac unless anyone cares to > fix the fix > - > 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/ -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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: Kernel hang on multi-threaded X process crash
Alan- I certainly care to fix it (since I wrote the patch). Since `aviplay' seems to be the easy way to trigger it I'll look into it. On Mon, Apr 23, 2001 at 04:40:12PM +0100, Alan Cox wrote: Both mozilla and aviplay (which are both multithreaded) trigger this - I haven't tried with xmms. Simpler programs like xclock or cat don't trigger it. Thanks. I'll revert the core dump stuff for 2.4.4-ac unless anyone cares to fix the fix - 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/ -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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: what is pci=biosirq
yptoapi: Registered aes-cbc (65536)
> cryptoapi: Registered blowfish-ecb (0)
> cryptoapi: Registered blowfish-cbc (65536)
> cryptoapi: Registered des-ecb (0)
> cryptoapi: Registered des-cbc (65536)
> cryptoapi: Registered des_ede3-ecb (0)
> cryptoapi: Registered des_ede3-cbc (65536)
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 176k freed
> Adding Swap: 128516k swap-space (priority -1)
> PCI: Found IRQ 3 for device 00:09.0
> 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others.
> http://www.scyld.com/network/vortex.html
> See Documentation/networking/vortex.txt
> eth0: 3Com PCI 3c900 Boomerang 10baseT at 0xb800, 00:60:97:c7:a6:82, IRQ
> 3
> product code 4843 rev 00.0 date 09-07-00
> 8K word-wide RAM 3:5 Rx:Tx split, autoselect/10baseT interface.
> Enabling bus-master transmits and whole-frame receives.
> eth0: scatter/gather enabled. h/w checksums disabled
> Real Time Clock Driver v1.10d
> inserting floppy driver for 2.4.3
> Floppy drive(s): fd0 is 1.44M
> FDC 0 is a post-1991 82077
> loop: loaded (max 8 devices)
> hdc: set_drive_speed_status: status=0x40 { DriveReady }
> hdc: ATAPI 20X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
> Uniform CD-ROM driver Revision: 3.12
> usb.c: registered new driver hub
> PCI: Found IRQ 7 for device 00:02.0
> PCI: Setting latency timer of device 00:02.0 to 64
> usb-ohci.c: USB OHCI at membase 0xd084f000, IRQ 7
> usb-ohci.c: usb-00:02.0, Acer Laboratories Inc. [ALi] M5237 USB
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> hub.c: 2 ports detected
> es1370: version v0.34 time 17:48:44 Mar 31 2001
> PCI: Found IRQ 10 for device 00:0a.0
> es1370: found adapter at io 0xb400 irq 10
> es1370: features: joystick on, line in, mic impedance 0
> gameport0: NS558 ISA at 0x200 size 8 speed 1125 kHz
> js0: Joystick device for input0
> event0: Event device for input0
> input0: Gravis Xterminator Digital on gameport0.0
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 203M
> agpgart: Detected Ali M1541 chipset
> agpgart: AGP aperture is 64M @ 0xe000
> [drm] AGP 0.99 on ALi M1541 @ 0xe000 64MB
> [drm] Initialized tdfx 1.0.0 2928 on minor 63
> eth0: first available media type: 10baseT
>
> 00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04)
> 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04)
> 00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03)
> 00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
> 00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge
> [Aladdin IV] (rev c3)
> 00:09.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang]
> 00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
> 00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1)
> 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev
> 01)
>
>
> -
> 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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
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: what is pci=biosirq
8516k swap-space (priority -1)
PCI: Found IRQ 3 for device 00:09.0
3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others.
http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
eth0: 3Com PCI 3c900 Boomerang 10baseT at 0xb800, 00:60:97:c7:a6:82, IRQ
3
product code 4843 rev 00.0 date 09-07-00
8K word-wide RAM 3:5 Rx:Tx split, autoselect/10baseT interface.
Enabling bus-master transmits and whole-frame receives.
eth0: scatter/gather enabled. h/w checksums disabled
Real Time Clock Driver v1.10d
inserting floppy driver for 2.4.3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
hdc: set_drive_speed_status: status=0x40 { DriveReady }
hdc: ATAPI 20X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
usb.c: registered new driver hub
PCI: Found IRQ 7 for device 00:02.0
PCI: Setting latency timer of device 00:02.0 to 64
usb-ohci.c: USB OHCI at membase 0xd084f000, IRQ 7
usb-ohci.c: usb-00:02.0, Acer Laboratories Inc. [ALi] M5237 USB
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
es1370: version v0.34 time 17:48:44 Mar 31 2001
PCI: Found IRQ 10 for device 00:0a.0
es1370: found adapter at io 0xb400 irq 10
es1370: features: joystick on, line in, mic impedance 0
gameport0: NS558 ISA at 0x200 size 8 speed 1125 kHz
js0: Joystick device for input0
event0: Event device for input0
input0: Gravis Xterminator Digital on gameport0.0
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected Ali M1541 chipset
agpgart: AGP aperture is 64M @ 0xe000
[drm] AGP 0.99 on ALi M1541 @ 0xe000 64MB
[drm] Initialized tdfx 1.0.0 2928 on minor 63
eth0: first available media type: 10baseT
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04)
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04)
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03)
00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge
[Aladdin IV] (rev c3)
00:09.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang]
00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev
01)
-
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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
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: your mail
Ying- I'm a little confused here. It's very hard to compare a UP application vs. the same app. converted to use threads. Unless the app. is structured such that multiple threads can run at the same time then no, you won't see any improvement by going to SMP, in fact a true single threaded app. will frequently slow down when run on an SMP kernel. Have you watched a CPU meter while your benchmark runs? Even something basic like `top' should give you a feel for whether or not your using all of the CPU's. On Tue, Mar 06, 2001 at 03:55:55PM -0800, Ying Chen wrote: > Hi, > > I have two questions on Linux pthread related issues. Would anyone be able > to help? > > ... > > 2. We ran multi-threaded application using Linux pthread library on 2-way > SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see > significant increase in context switching when moving from UP to SMP, and > high CPU usage with no performance gain in turns of actual work being done > when moving to SMP, despite the fact the benchmark we are running is > CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks > went to scheduling and signaling overheads. Has anyone seen something like > this before with pthread applications running on SMP platforms? Any > suggestions or pointers on this subject? > > Thanks a lot! > > Ying > > > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > - > 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/ -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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: binfmt_script and ^M (historical note)
Paul-
Minor historical note. The `#!' processing was never done by the
shell, this was always done in the kernel. Think about about it,
the `#' character denotes a comment line, the shell ignores that
line. `#!' was used to create a way for the kernel to execute
a shell script directly. Since the kernel recognized the type of
executable based on a 16-bit magic number `#!' became a new magic
number that meant "break the remainder of the line into `program'
and `args' and then execute `program' with `args'".
A nice side effect of this is that it became a way to create shell
scripts that worked no matter what shell a user was running. For
efficiency, most shells just read and execute a shell script so
releasing a Bourne shell script to a group of CSH users created
problems. At the expense of a `fork' and `exec' the `#!' magic
number solved this problem.
On Tue, Mar 06, 2001 at 12:33:49PM +, Paul Flinders wrote:
> Andreas Schwab wrote:
>
> > Paul Flinders <[EMAIL PROTECTED]> writes:
> >
> > |> Andreas Schwab wrote:
> > |>
> > |> > This [isspace('\r') == 1] has no significance here. The right thing to
> > |>
> > |> > look at is $IFS, which does not contain \r by default. The shell only splits
> > |>
> > |> > words by "IFS whitespace", and the kernel should be consistent with it:
> > |> >
> > |> > $ echo -e 'ls foo\r' | sh
> > |> > ls: foo: No such file or directory
> > |>
> > |> The problem with that argument is that #! can be applied
> > |> to more than just shells which understand $IFS, so which environment
> > |> variable does the kernel pick?
> >
> > The kernel should use the same default value of IFS as the Bourne shell,
> > ie. the same value you'll get with /bin/sh -c 'echo "$IFS"'. This is
> > independent of any settings in the environment.
> >
> > |> It's a difficult one - logically white space should terminate the interpreter
> >
> > No, IFS-whitespace delimits arguments in the Bourne shell.
>
> Way back whenever processing #! was moved from the
> shell to the kernel** this argument would have made sense -
> today I'm not so sure.
>
> But I'm quite happy for the kernel to use just space and
> tab if it wishes, or anything else for that matter but it _is_
> confusing that the error code doesn't distinguish problems
> with the script from problems with the interpreter.
>
> **Did linux ever rely on the shell for this?
>
> -
> 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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
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: binfmt_script and ^M (historical note)
Paul-
Minor historical note. The `#!' processing was never done by the
shell, this was always done in the kernel. Think about about it,
the `#' character denotes a comment line, the shell ignores that
line. `#!' was used to create a way for the kernel to execute
a shell script directly. Since the kernel recognized the type of
executable based on a 16-bit magic number `#!' became a new magic
number that meant "break the remainder of the line into `program'
and `args' and then execute `program' with `args'".
A nice side effect of this is that it became a way to create shell
scripts that worked no matter what shell a user was running. For
efficiency, most shells just read and execute a shell script so
releasing a Bourne shell script to a group of CSH users created
problems. At the expense of a `fork' and `exec' the `#!' magic
number solved this problem.
On Tue, Mar 06, 2001 at 12:33:49PM +, Paul Flinders wrote:
Andreas Schwab wrote:
Paul Flinders [EMAIL PROTECTED] writes:
| Andreas Schwab wrote:
|
| This [isspace('\r') == 1] has no significance here. The right thing to
|
| look at is $IFS, which does not contain \r by default. The shell only splits
|
| words by "IFS whitespace", and the kernel should be consistent with it:
|
| $ echo -e 'ls foo\r' | sh
| ls: foo: No such file or directory
|
| The problem with that argument is that #!interpreter can be applied
| to more than just shells which understand $IFS, so which environment
| variable does the kernel pick?
The kernel should use the same default value of IFS as the Bourne shell,
ie. the same value you'll get with /bin/sh -c 'echo "$IFS"'. This is
independent of any settings in the environment.
| It's a difficult one - logically white space should terminate the interpreter
No, IFS-whitespace delimits arguments in the Bourne shell.
Way back whenever processing #! was moved from the
shell to the kernel** this argument would have made sense -
today I'm not so sure.
But I'm quite happy for the kernel to use just space and
tab if it wishes, or anything else for that matter but it _is_
confusing that the error code doesn't distinguish problems
with the script from problems with the interpreter.
**Did linux ever rely on the shell for this?
-
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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
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: your mail
Ying- I'm a little confused here. It's very hard to compare a UP application vs. the same app. converted to use threads. Unless the app. is structured such that multiple threads can run at the same time then no, you won't see any improvement by going to SMP, in fact a true single threaded app. will frequently slow down when run on an SMP kernel. Have you watched a CPU meter while your benchmark runs? Even something basic like `top' should give you a feel for whether or not your using all of the CPU's. On Tue, Mar 06, 2001 at 03:55:55PM -0800, Ying Chen wrote: Hi, I have two questions on Linux pthread related issues. Would anyone be able to help? ... 2. We ran multi-threaded application using Linux pthread library on 2-way SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see significant increase in context switching when moving from UP to SMP, and high CPU usage with no performance gain in turns of actual work being done when moving to SMP, despite the fact the benchmark we are running is CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks went to scheduling and signaling overheads. Has anyone seen something like this before with pthread applications running on SMP platforms? Any suggestions or pointers on this subject? Thanks a lot! Ying _ Get your FREE download of MSN Explorer at http://explorer.msn.com - 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/ -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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: binfmt_script and ^M
Isn't `perl' overkill? Why not just: tr -d '\r' On Tue, Feb 27, 2001 at 08:20:59PM +0100, Jamie Lokier wrote: > Ivo Timmermans wrote: > > > _should_ it work with the \r in it? > > > > IMHO, yes. This set of files were created on Windows, then zipped and > > uploaded to a Linux server, unpacked. This does not change the \r. > > Use `fromdos' to convert the files. Or this little Perl gem, which > takes a list of files or standard input as argument: > > #!/usr/bin/perl -pi > s/\r\n$/\n/ > > -- Jamie > - > 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/ -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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] Core dumps for threads
OK, I followed Alan's suggestion and here is a patch, relative to
the 2.4.1 kernel, that copies the mm and dumps the corefile from
that copy. Also, whenever there are multiple users of the original
mm it creates the core dump in the file `core.n' where `n' is the
PID of the offending process.
I would contend that this fixes a bug and should be put into the
2.4 but if the concensus is that it's a new 2.5 feature that's fine.
On Sat, Feb 24, 2001 at 09:57:44PM +, Alan Cox wrote:
> > Can anyone explain why this test is in routine `do_coredump'
> > in file `fs/exec.c' in the 2.4.0 kernel?
> >
> > if (!current->dumpable || atomic_read(>mm->mm_users) != 1)
> > goto fail;
> >
> > The only thing the test on `mm_users' seems to be doing is stopping
> > a thread process from dumping core. What's the rationale for this?
>
> The I/O to dump the core would race other changes on the mm. The right fix
> is probably to copy the mm (as fork does) then dump the copy.
>
> -
> 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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
Index: linux-2.4/fs/binfmt_aout.c
===
RCS file: /trillian/src/cvs_root/linux-2.4/fs/binfmt_aout.c,v
retrieving revision 1.1
diff -u -r1.1 binfmt_aout.c
--- linux-2.4/fs/binfmt_aout.c 2001/02/06 23:40:30 1.1
+++ linux-2.4/fs/binfmt_aout.c 2001/02/27 16:50:43
@@ -31,7 +31,8 @@
static int load_aout_binary(struct linux_binprm *, struct pt_regs * regs);
static int load_aout_library(struct file*);
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file);
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file *file, struct mm_struct * mm);
extern void dump_thread(struct pt_regs *, struct user *);
@@ -78,7 +79,8 @@
* dumping of the process results in another error..
*/
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file)
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
mm_segment_t fs;
int has_dumped = 0;
Index: linux-2.4/fs/binfmt_elf.c
===
RCS file: /trillian/src/cvs_root/linux-2.4/fs/binfmt_elf.c,v
retrieving revision 1.1
diff -u -r1.1 binfmt_elf.c
--- linux-2.4/fs/binfmt_elf.c 2001/02/06 23:40:30 1.1
+++ linux-2.4/fs/binfmt_elf.c 2001/02/27 16:50:43
@@ -56,7 +56,8 @@
* don't even try.
*/
#ifdef USE_ELF_CORE_DUMP
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file);
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm);
#else
#define elf_core_dump NULL
#endif
@@ -981,7 +982,8 @@
* and then they are actually written out. If we run out of core limit
* we just truncate.
*/
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file)
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
int has_dumped = 0;
mm_segment_t fs;
@@ -998,7 +1000,7 @@
elf_fpregset_t fpu; /* NT_PRFPREG */
struct elf_prpsinfo psinfo; /* NT_PRPSINFO */
- segs = current->mm->map_count;
+ segs = mm->map_count;
#ifdef DEBUG
printk("elf_core_dump: %d segs %lu limit\n", segs, limit);
@@ -1158,7 +1160,7 @@
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
/* Write program headers for segments dump */
- for(vma = current->mm->mmap; vma != NULL; vma = vma->vm_next) {
+ for(vma = mm->mmap; vma != NULL; vma = vma->vm_next) {
struct elf_phdr phdr;
size_t sz;
@@ -1187,7 +1189,7 @@
DUMP_SEEK(dataoff);
- for(vma = current->mm->mmap; vma != NULL; vma = vma->vm_next) {
+ for(vma = mm->mmap; vma != NULL; vma = vma->vm_next) {
unsigned long addr;
if (!maydump(vma))
Index: linux-2.4/fs/exec.c
===
RCS file: /trillian/src/cvs_root/linux-2.4/fs/exec.c,v
retrieving revision 1.2
diff -u -r1.2 exec.c
--- linux-2.4/fs/exec.c 2001/02/07 01:17:26 1.2
+++ linux-2.4/fs/exec.c 2001/02/27 16:50:43
@@ -916,16 +916,18 @@
int do_coredump(long signr, struct pt_regs * regs)
{
+ struct mm_struct *mm;
struct linux_binfmt * binfmt;
- char corename[6+sizeof(current->comm)];
+ char corename[6+sizeof(current->comm)+10];
[PATCH] Core dumps for threads
OK, I followed Alan's suggestion and here is a patch, relative to
the 2.4.1 kernel, that copies the mm and dumps the corefile from
that copy. Also, whenever there are multiple users of the original
mm it creates the core dump in the file `core.n' where `n' is the
PID of the offending process.
I would contend that this fixes a bug and should be put into the
2.4 but if the concensus is that it's a new 2.5 feature that's fine.
On Sat, Feb 24, 2001 at 09:57:44PM +, Alan Cox wrote:
Can anyone explain why this test is in routine `do_coredump'
in file `fs/exec.c' in the 2.4.0 kernel?
if (!current-dumpable || atomic_read(current-mm-mm_users) != 1)
goto fail;
The only thing the test on `mm_users' seems to be doing is stopping
a thread process from dumping core. What's the rationale for this?
The I/O to dump the core would race other changes on the mm. The right fix
is probably to copy the mm (as fork does) then dump the copy.
-
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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
Index: linux-2.4/fs/binfmt_aout.c
===
RCS file: /trillian/src/cvs_root/linux-2.4/fs/binfmt_aout.c,v
retrieving revision 1.1
diff -u -r1.1 binfmt_aout.c
--- linux-2.4/fs/binfmt_aout.c 2001/02/06 23:40:30 1.1
+++ linux-2.4/fs/binfmt_aout.c 2001/02/27 16:50:43
@@ -31,7 +31,8 @@
static int load_aout_binary(struct linux_binprm *, struct pt_regs * regs);
static int load_aout_library(struct file*);
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file);
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file *file, struct mm_struct * mm);
extern void dump_thread(struct pt_regs *, struct user *);
@@ -78,7 +79,8 @@
* dumping of the process results in another error..
*/
-static int aout_core_dump(long signr, struct pt_regs * regs, struct file *file)
+static int aout_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
mm_segment_t fs;
int has_dumped = 0;
Index: linux-2.4/fs/binfmt_elf.c
===
RCS file: /trillian/src/cvs_root/linux-2.4/fs/binfmt_elf.c,v
retrieving revision 1.1
diff -u -r1.1 binfmt_elf.c
--- linux-2.4/fs/binfmt_elf.c 2001/02/06 23:40:30 1.1
+++ linux-2.4/fs/binfmt_elf.c 2001/02/27 16:50:43
@@ -56,7 +56,8 @@
* don't even try.
*/
#ifdef USE_ELF_CORE_DUMP
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file);
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm);
#else
#define elf_core_dump NULL
#endif
@@ -981,7 +982,8 @@
* and then they are actually written out. If we run out of core limit
* we just truncate.
*/
-static int elf_core_dump(long signr, struct pt_regs * regs, struct file * file)
+static int elf_core_dump(long signr, struct pt_regs * regs,
+ struct file * file, struct mm_struct * mm)
{
int has_dumped = 0;
mm_segment_t fs;
@@ -998,7 +1000,7 @@
elf_fpregset_t fpu; /* NT_PRFPREG */
struct elf_prpsinfo psinfo; /* NT_PRPSINFO */
- segs = current-mm-map_count;
+ segs = mm-map_count;
#ifdef DEBUG
printk("elf_core_dump: %d segs %lu limit\n", segs, limit);
@@ -1158,7 +1160,7 @@
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
/* Write program headers for segments dump */
- for(vma = current-mm-mmap; vma != NULL; vma = vma-vm_next) {
+ for(vma = mm-mmap; vma != NULL; vma = vma-vm_next) {
struct elf_phdr phdr;
size_t sz;
@@ -1187,7 +1189,7 @@
DUMP_SEEK(dataoff);
- for(vma = current-mm-mmap; vma != NULL; vma = vma-vm_next) {
+ for(vma = mm-mmap; vma != NULL; vma = vma-vm_next) {
unsigned long addr;
if (!maydump(vma))
Index: linux-2.4/fs/exec.c
===
RCS file: /trillian/src/cvs_root/linux-2.4/fs/exec.c,v
retrieving revision 1.2
diff -u -r1.2 exec.c
--- linux-2.4/fs/exec.c 2001/02/07 01:17:26 1.2
+++ linux-2.4/fs/exec.c 2001/02/27 16:50:43
@@ -916,16 +916,18 @@
int do_coredump(long signr, struct pt_regs * regs)
{
+ struct mm_struct *mm;
struct linux_binfmt * binfmt;
- char corename[6+sizeof(current-comm)];
+ char corename[6+sizeof(current-comm)+10];
struct file * file;
struct inode * inode;
+ int r;
lock_kernel();
binfmt = current-binfmt;
if (!binfmt || !binfmt-core_d
Re: binfmt_script and ^M
Isn't `perl' overkill? Why not just: tr -d '\r' On Tue, Feb 27, 2001 at 08:20:59PM +0100, Jamie Lokier wrote: Ivo Timmermans wrote: _should_ it work with the \r in it? IMHO, yes. This set of files were created on Windows, then zipped and uploaded to a Linux server, unpacked. This does not change the \r. Use `fromdos' to convert the files. Or this little Perl gem, which takes a list of files or standard input as argument: #!/usr/bin/perl -pi s/\r\n$/\n/ -- Jamie - 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/ -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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/
Core dumps for threads
Can anyone explain why this test is in routine `do_coredump' in file `fs/exec.c' in the 2.4.0 kernel? if (!current->dumpable || atomic_read(>mm->mm_users) != 1) goto fail; The only thing the test on `mm_users' seems to be doing is stopping a thread process from dumping core. What's the rationale for this? -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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/
Core dumps for threads
Can anyone explain why this test is in routine `do_coredump' in file `fs/exec.c' in the 2.4.0 kernel? if (!current-dumpable || atomic_read(current-mm-mm_users) != 1) goto fail; The only thing the test on `mm_users' seems to be doing is stopping a thread process from dumping core. What's the rationale for this? -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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/
