linux-kernel - Re: [2.6.27.24] Kernel coredump to a pipe is failing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1243404173.7369.158.camel@homebase.localnet>
Date:	Wed, 27 May 2009 02:02:53 -0400
From:	Paul Smith <paul@...-scientist.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: [2.6.27.24] Kernel coredump to a pipe is failing

On Tue, 2009-05-26 at 17:29 -0700, Andrew Morton wrote:
> On Wed, 27 May 2009 02:11:04 +0200 Andi Kleen <andi@...stfloor.org> wrote:
> 
> > > I dunno.  Is this true of all linux filesystems in all cases?  Maybe.
> > 
> > Assuming one of them is not would you rather want to fix that file system
> > or 10 zillion user programs (including the kernel core dumper) that 
> > get it wrong? @)
> 
> I think that removing one bug is better than adding one.
> 
> Many filesystems will return a short write if they hit a memory
> allocation failure, for example.  pipe_write() sure will.  Retrying
> is appropriate in such a case.

As a mainly userspace guy maybe I'm missing some details for kernel
behavior, but I know I would never write a program that used write(2)
and assumed it would never return a short write.  The documentation for
write(2) is very clear that short writes are possible and any reasonably
robust program will handle this.  Consider things like NFS filesystems,
etc. where who knows what behavior is found.

I'm more concerned with the loss of the signal mask settings in the core
dump in Andi's patch.  This seems to be losing important information.
Andi, why did you prefer that to clearing the pending signal and
retrying the write?  I'm definitely not familiar enough with signal
management in the kernel to know what side-effects there might be from
just clearing the pending flag without doing anything else: I did it
that way because fs/exec.c:do_coredump() does this before it runs the
->core_dump function.

I wonder whether dump_write() shouldn't be rewritten along the lines of
a normal, robust userspace writer, where we handle EAGAIN and EINTR (can
we ever get these at this level, or do we ever just get ERESTARTSYS?),
short writes, etc.


PS. I have a thought about why this happens for me; I doubt I'm getting
SIGPIPE.  In our system it's almost certain that these worker processes
will get a signal (SIGUSR1 or something: I forget exactly which one) if
they are still alive after a few seconds.  I suspect that the core dump
takes long enough that this signal is received in the middle of the core
dump.  It may be that this problem hasn't been noticed before because
it's unlikely you'll receive a signal in the middle of dumping core, and
if you do get one every now and then, and get a short core, it's not
easily reproducible.  I left my debugging in the kernel and I get
exactly one instance of signal_pending() per process, so having the
signal be SIGPIPE seems unlikely.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/