From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleg Nesterov Subject: Re: [PATCH] exec: log when wait_for_dump_helpers aborts due to a signal Date: Sat, 29 Oct 2011 16:43:15 +0200 Message-ID: <20111029144315.GB7036@redhat.com> References: <1319591228-20397-1-git-send-email-msb@chromium.org> <20111028162631.294c1f8a.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mandeep Singh Baines , linux-kernel@vger.kernel.org, Alexander Viro , Neil Horman , Earl Chew , Andi Kleen , Alan Cox , linux-fsdevel@vger.kernel.org To: Andrew Morton Return-path: Content-Disposition: inline In-Reply-To: <20111028162631.294c1f8a.akpm@linux-foundation.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 10/28, Andrew Morton wrote: > > Well. Neil's changelog for 61be228a06dc6e8662 is quite nice and tells > us everything we could possibly want to know, except for why it tests > sgnal_pending() :( In short, signal_pending() should not be here. It only reflects the fact that do_coredump() needs the fixes (and can't resist, I sent the patch several years ago, but it was ignored ;) There are 2 reasons. if signal_pending() == T then: - pipe_wait() is pointless, it won't block. We do not want a busywait loop. - And probably even wait_for_dump_helpers() is pointless, it is quite possible that pipe_write() already failed before and the reader doesn't know this. What I think we should do: - Fix this code, it should not react to signals. - But! at the same time the explicit SIGKILL should stop the coredump. It can take a lot of time/resources. This also makes it oom-killable, and this is important. - If we dump to the pipe, then perhaps it makes sense to send a signal to the pipe reader in the latter case, but this is a bit offtopic. I'll try to redo my old patches for 3.2 once I have the time. There are some nasty problems which I forgot, _iirc_ this is not that trivial. Oleg.