Messages in this thread | | | Subject | Re: [2.6.27.24] Kernel coredump to a pipe is failing | From | Paul Smith <> | Date | Tue, 26 May 2009 17:09:16 -0400 |
| |
On Tue, 2009-05-26 at 22:31 +0200, Andi Kleen wrote: > Paul Smith <paul@mad-scientist.net> writes: > > Well, -512 is ERESTARTSYS. That, to me, seems like a reasonable error > > code to get when we're trying to dump core to a pipe. Yes? No? > > Which signal is it? SIGPIPE?
I'm not sure; I'll have to dig in a little further. I'm not sure offhand how to determine which signal it was from inside the kernel but it shouldn't be hard to find.
> > > > Shouldn't we be doing some kind of error handling here, at least for > > basic things like signals? Should a process that's dumping core be set > > to ignore signals? Should dump_write() try again on ERESTARTSYS? > > I think it should block signals. Here's a untested patch. > > It has the disadvantage that it reports the incorrect blocked mask > in the ELF corefile, but that's probably better than truncated > coredumps.
As a quick test I changed dump_write() to retry on ERESTARTSYS after disabling the pending signal, like:
static int dump_write(struct file *file, const void *addr, int nr) { while (1) { int r = file->f_op->write(file, addr, nr, &file->f_pos); if (r != -ERESTARTSYS) return r == nr; /* We don't handle signals while dumping core. */ clear_thread_flag(TIF_SIGPENDING); } }
I don't know if this is right, but in some quick tests I ran it did work: my cores were full size. I haven't finished testing (and I have to go to soccer practice right now).
This obviously doesn't reset the signal mask in the dumping process, but it makes the dump_write() more complex and it may cause other issues so I can't say whether this is the way to go.
> - > Block signals during core dump
Cool, I'll test this one as well.
| |