From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CEF02C282C4 for ; Tue, 5 Feb 2019 03:01:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A112B20830 for ; Tue, 5 Feb 2019 03:01:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727248AbfBEDBI (ORCPT ); Mon, 4 Feb 2019 22:01:08 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:51211 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726606AbfBEDBI (ORCPT ); Mon, 4 Feb 2019 22:01:08 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gqqyt-0004h6-KF; Mon, 04 Feb 2019 20:01:03 -0700 Received: from ip68-227-174-240.om.om.cox.net ([68.227.174.240] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gqqys-0003X3-U3; Mon, 04 Feb 2019 20:01:03 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Thomas Gleixner Cc: Dmitry Vyukov , Ingo Molnar , Peter Zijlstra , LKML , Arnaldo Carvalho de Melo , Alexander Shishkin , jolsa@redhat.com, Namhyung Kim , luca abeni , syzkaller , Oleg Nesterov References: Date: Mon, 04 Feb 2019 21:00:56 -0600 In-Reply-To: (Thomas Gleixner's message of "Mon, 4 Feb 2019 17:38:48 +0000 (GMT)") Message-ID: <8736p37xcn.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1gqqys-0003X3-U3;;;mid=<8736p37xcn.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=68.227.174.240;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/tfKYZMJ77EKz8eqpZ/7tMdvM/LrvlsMM= X-SA-Exim-Connect-IP: 68.227.174.240 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: perf_event_open+clone = unkillable process X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > On Mon, 4 Feb 2019, Dmitry Vyukov wrote: > >> On Mon, Feb 4, 2019 at 10:27 AM Thomas Gleixner wrote: >> > >> > On Fri, 1 Feb 2019, Dmitry Vyukov wrote: >> > >> > > On Fri, Feb 1, 2019 at 5:48 PM Dmitry Vyukov wrote: >> > > > >> > > > Hello, >> > > > >> > > > The following program creates an unkillable process that eats CPU. >> > > > /proc/pid/stack is empty, I am not sure what other info I can provide. >> > > > >> > > > Tested is on upstream commit 4aa9fc2a435abe95a1e8d7f8c7b3d6356514b37a. >> > > > Config is attached. >> > > >> > > Looking through other reproducers that create unkillable processes, I >> > > think I found a much simpler reproducer (below). It's single threaded >> > > and just setups SIGBUS handler and does timer_create+timer_settime to >> > > send repeated SIGBUS. The resulting process can't be killed with >> > > SIGKILL. >> > > +Thomas for timers. >> > >> > +Oleg, Eric >> > >> > That's odd. With some tracing I can see that SIGKILL is generated and >> > queued, but its not delivered by some weird reason. I'm traveling in the >> > next days, so I won't be able to do much about it. Will look later this >> > week. >> >> Just a random though looking at the repro: can constant SIGBUS >> delivery starve delivery of all other signals (incl SIGKILL)? > > Indeed. SIGBUS is 7, SIGKILL is 9 and next_signal() delivers the lowest > number first.... We do have the special case in complete_signal that causes most of the signal delivery work of SIGKILL to happen when SIGKILL is queued. I need to look at your reproducer. It would require being a per-thread signal to cause problems in next_signal. It is definitely worth fixing if there is any way for userspace to block SIGKILL. Eric