From patchwork Tue Nov 5 15:27:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oleg Nesterov X-Patchwork-Id: 1189745 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-106652-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="J+rQ0EBE"; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="dCgHDm4I"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 476tpD5fhmz9sNx for ; Wed, 6 Nov 2019 02:27:48 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=nT9EkZ+JExmZfu14 DAHj397Iai4XuQlzbu0o/7+xW6TFlecubSLHb0f9gtuLPrnQcswbaO2+UCukEZ/p FPGHghLsk6+6WC79exBakqdfhwnHNhG6c6UCFMwUNcQZOejDtmgdMEGUJUg3zM0b tG8/SPhI6LkE2uJR1gu+038gjI4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=rA/TAD5Y3yKIm4FEPZREak 3Yis8=; b=J+rQ0EBEqdFZ+XNUjfN8cMvYCytteNCawnTkimvvsL3LGaOyHAP2JB XssxfwibnU4Fo0GuLle21BjIQAIZHNhDbbx0X33Bwv+rHhUWb38Segc0SsXBqwu0 HVGlNroUG/iYzyvsIJXLipI0EK+GgKtLbgFrYb9ZwwGOFZvTKFuLI= Received: (qmail 73100 invoked by alias); 5 Nov 2019 15:27:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 73087 invoked by uid 89); 5 Nov 2019 15:27:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=retry X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572967660; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gvUBd68QYOf4zjMI6uQSjQ5CMU0M3270wf5ewDe4CGw=; b=dCgHDm4IOxe7/9fsweCZ52menWoXSlKP02PxcXvwAdEo84VTm/CJG3hMuUZS9RWmpe2nRH sgrce0oQdm5QBa5CKepfRNpexUR3GITvw6khgLCVuM9Euxtdfz64RnjMg2IrOdH71X3BTz G7wYMKJnfm0hYWKcQQsJw8XnDXAwVVA= Date: Tue, 5 Nov 2019 16:27:28 +0100 From: Oleg Nesterov To: Thomas Gleixner Cc: Florian Weimer , Shawn Landden , libc-alpha@sourceware.org, linux-api@vger.kernel.org, LKML , Arnd Bergmann , Deepa Dinamani , Andrew Morton , Catalin Marinas , Keith Packard , Peter Zijlstra Subject: handle_exit_race && PF_EXITING Message-ID: <20191105152728.GA5666@redhat.com> References: <20191104002909.25783-1-shawn@git.icu> <87woceslfs.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Mimecast-Spam-Score: 0 Content-Disposition: inline On 11/05, Thomas Gleixner wrote: > > Out of curiosity, what's the race issue vs. robust list which you are > trying to solve? Off-topic, but this reminds me... #include #include #include #include #define FUTEX_LOCK_PI 6 int main(void) { struct sched_param sp = {}; sp.sched_priority = 2; assert(sched_setscheduler(0, SCHED_FIFO, &sp) == 0); int lock = vfork(); if (!lock) { sp.sched_priority = 1; assert(sched_setscheduler(0, SCHED_FIFO, &sp) == 0); _exit(0); } syscall(__NR_futex, &lock, FUTEX_LOCK_PI, 0,0,0); return 0; } this creates the unkillable RT process spinning in futex_lock_pi() on a single CPU machine (or you can use taskset). Probably the patch below makes sense anyway, but of course it doesn't solve the real problem: futex_lock_pi() should not spin in this case. It seems to me I even sent the fix a long ago, but I can't recall what exactly it did. Probably the PF_EXITING check in attach_to_pi_owner() must simply die, I'll try to recall... Oleg. Signed-off-by: Oleg Nesterov --- x/kernel/futex.c +++ x/kernel/futex.c @@ -2842,10 +2842,12 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, * exit to complete. * - The user space value changed. */ - queue_unlock(hb); - put_futex_key(&q.key); - cond_resched(); - goto retry; + if (!fatal_signal_pending(current)) { + queue_unlock(hb); + put_futex_key(&q.key); + cond_resched(); + goto retry; + } default: goto out_unlock_put_key; }