Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp793862yba; Thu, 9 May 2019 06:07:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqyVrurHTJMAQHQw0raXEN8nc30JtWF+D0e12sR6PIA9KpHcaSsuAH9tN7tGebW1hNS8UL8A X-Received: by 2002:a63:87c6:: with SMTP id i189mr5140377pge.367.1557407270998; Thu, 09 May 2019 06:07:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557407270; cv=none; d=google.com; s=arc-20160816; b=E+pbaxYmt/mhqe5jtb/kQ3gM604ruIwClI4v9IcZETgw4CK/BV/Hekg2+8h06C4cgJ KPVjqEaE9Jv+pNUps9gftl7rS3Ov43t6hjP4nLPBDRD6RrSiBkB/JQ1pcB4SNSuOlGLG fXYjdq4wFYoqseoLZwBHk/VDK6HCDHh05qKJQTomC7jhyzClw4ZZzHsHD5FsywEUXtw0 fq9wW6wKB0hfaglPBZZpmuy00X1nlEtF14USHTEFQ+B550ehi90doc/h4ENBR8TndSTN apA9OYrttRQlSPbd707XlChFAlOfOkZhxTob2sY2KecqwVUCkT1uRg5nWrP4u18hFpkm 10CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=0BxG/P6nTaRHuqfrtLoIVS1BNNS5MjTMtFgzd0GUMd4=; b=hFLFYjGHyepGniPHtkzgvGqWkhvkRuoC82n9JVgSQTvZnXH9jZ4mOVCnQQEnTTbn7t y9iF2msmirsozm+9uHmssGVaZcKpF+/Bt2rrHsedJeuMHL5tesb6UvBDBpog16DXfcNC ZtSG3Igcn4nu18QVon9uFIxuBjMfzcu41FXf/cMvsWzSSEvWXKr0Q0LJkZsaDPE03BMn 7g+6OyzucMxb3U9Y21jCY0D/8SHE8kVat2kjp7mHneMqDCI9Iqn5WfRh8upxc2YLARzZ FJ8C/lQR7Nd5mH5ne8d20i5UClL8jCDiL9WPxNuu4mOeYtby3+PZ4TdvQfdk9c+NP1XT dyng== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=BxSg29KQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i35si2823157plb.115.2019.05.09.06.07.28; Thu, 09 May 2019 06:07:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=BxSg29KQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726720AbfEINFo (ORCPT + 99 others); Thu, 9 May 2019 09:05:44 -0400 Received: from merlin.infradead.org ([205.233.59.134]:58264 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726558AbfEINFo (ORCPT ); Thu, 9 May 2019 09:05:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0BxG/P6nTaRHuqfrtLoIVS1BNNS5MjTMtFgzd0GUMd4=; b=BxSg29KQW/uKNfhjMWs5rtImU 8kmU1YHUsnPgLAdVsq7IajVexZeJhCQmXXFr4xSyw93bYdvLNKDtXaNRluD5dvJw6cLW8Bwcp0dgT LxU2aHHRDS349X+b3z724lYmmmDfu8MQnJYG2Icn3+8YzFITQhpgbF+zVebP/wHIajnu6kaqY4qwG 5QChwJRn2PqG4xZlcjH1gpU8QXTCWBHwubaGzgMLDX4EiIV5TSe6sUrhdNCDBi/n/nDD+g0T2cfSC Sij+nfh51Y9j9s/s4oS3COZ4ee/dxE2UNxG/Ixygrc7c8HkWIjOfomFA3j+X5IGFped/HqPYyET2X EwxMimN9A==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hOijS-0003Ib-KB; Thu, 09 May 2019 13:05:06 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 28E9222158202; Thu, 9 May 2019 15:05:04 +0200 (CEST) Date: Thu, 9 May 2019 15:05:04 +0200 From: Peter Zijlstra To: Chris Wilson Cc: Daniel Vetter , Intel Graphics Development , Petr Mladek , John Ogness , Will Deacon , linux-kernel@vger.kernel.org, Steven Rostedt , Sergey Senozhatsky , Ingo Molnar , Daniel Vetter Subject: Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2 Message-ID: <20190509130504.GW2623@hirez.programming.kicks-ass.net> References: <20190502141643.21080-1-daniel.vetter@ffwll.ch> <20190506074553.21464-1-daniel.vetter@ffwll.ch> <155739797736.28545.2942646931608459049@skylake-alporthouse-com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155739797736.28545.2942646931608459049@skylake-alporthouse-com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 09, 2019 at 11:32:57AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2019-05-06 08:45:53) > > +/** > > + * printk_safe_up - release the semaphore in console_unlock > > + * @sem: the semaphore to release > > + * > > + * Release the semaphore. Unlike mutexes, up() may be called from any > > + * context and even by tasks which have never called down(). > > + * > > + * NOTE: This is a special version of up() for console_unlock only. It is only > > + * safe if there are no killable, interruptible or timing out down() calls. > > + */ > > +void printk_safe_up(struct semaphore *sem) > > +{ > > + unsigned long flags; > > + struct semaphore_waiter *waiter = NULL; > > + > > + raw_spin_lock_irqsave(&sem->lock, flags); > > + if (likely(list_empty(&sem->wait_list))) { > > + sem->count++; > > + } else { > > + waiter = list_first_entry(&sem->wait_list, > > + struct semaphore_waiter, list); > > + list_del(&waiter->list); > > + waiter->up = true; > > + } > > + raw_spin_unlock_irqrestore(&sem->lock, flags); > > + > > + if (waiter) > > + wake_up_process(waiter->task); > > From comparing against __down_common() there's a risk here that as soon > as waiter->up == true, the waiter may complete and make the onstack > struct semaphore_waiter invalid. If you store waiter->task locally under > the spinlock that problem is resolved. > > Then there is the issue of an unprotected dereference of the task in > wake_up_process() -- I think you can wrap this function with > rcu_read_lock() to keep that safe, and wake_up_process() should be a > no-op if it races against process termination. task_struct is not RCU protected, see task_rcu_dereference() for magic.