Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935087AbdIYLKd (ORCPT ); Mon, 25 Sep 2017 07:10:33 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:54429 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933664AbdIYLK3 (ORCPT ); Mon, 25 Sep 2017 07:10:29 -0400 X-Google-Smtp-Source: AOwi7QC4VDSsODOukqO9JR0R9SEWfmb9dgCox1xL+PNpnvAurwFiUaMkmmtoM4QQuy4zQwpCxvov8Q== Message-ID: <1506337817.31845.1.camel@gmail.com> Subject: Aborting a core dump on a fatal signal From: Raymond Jennings To: linux-kernel@vger.kernel.org Date: Mon, 25 Sep 2017 04:10:17 -0700 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 515 Lines: 13 Would there be any benefit to allowing an in-progress core dump to be aborted if the dumping process receives a fatal signal? Example: Process segfaults, starts dumping core, but it has a lot of virtual memory allocated so it promptly leads to a queue-clogging deluge of I/O that takes in some cases several minutes to finish. In between the time where it snags the crash signal and the time when it finishes dumping and terminates, I'd like to be able to send it a SIGKILL or something to abort the core dump.