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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26A7DC433F5 for ; Wed, 10 Nov 2021 11:20:42 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BE886610D2 for ; Wed, 10 Nov 2021 11:20:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BE886610D2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 439B16EE00; Wed, 10 Nov 2021 11:20:41 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4494A6EE00 for ; Wed, 10 Nov 2021 11:20:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=CKdGRMTGsWn9HCBQ5Oi6SxJ1ad0n9MyScVi4CuS0mWM=; b=qxVhBfi88ggtGutV0mk23qAID+ DqTtqFaZuebEIRAbDCmFVl2EDZn7kj7b83mbuV3XY+7417TPHZNnhHO7vmj26qpz3uFBeKKn/WRx2 j2isy8Cd+1jyuOELDU0W00EG2u+7KjZZr/TGjNqZqG5lqXhg3SUmNTSPiGej1Oqawr5jwbRsZ8zhE Lt91QO8lAr/lE0UcgWMYZv9u2TiR1azxNRgcetmUql5yBH3qefh3JGRRr1tjgFZC+C7WMzsL0OiSp GSb7pySq+6oaDqIBnfFfHF8+LDnPA3mrHsd/AdszMJomO0hW+UZmBkFRH3jhz4iHYk4O3v8Q1ERAE 6yq/xbIQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkleB-001ohi-VO; Wed, 10 Nov 2021 11:20:08 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id AC4963000A3; Wed, 10 Nov 2021 12:20:05 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 8E7E8214EB9C2; Wed, 10 Nov 2021 12:20:05 +0100 (CET) Date: Wed, 10 Nov 2021 12:20:05 +0100 From: Peter Zijlstra To: Petr Mladek Subject: Re: printk deadlock due to double lock attempt on current CPU's runqueue Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , David Airlie , dri-devel@lists.freedesktop.org, Ben Segall , Sultan Alsawaf , Vincent Guittot , Anton Vorontsov , Ingo Molnar , Mel Gorman , Kees Cook , John Ogness , Steven Rostedt , Dietmar Eggemann , Tony Luck , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Thomas Zimmermann , Colin Cross , Daniel Bristot de Oliveira Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Nov 10, 2021 at 11:50:38AM +0100, Petr Mladek wrote: > On Tue 2021-11-09 12:06:48, Sultan Alsawaf wrote: > > Hi, > > > > I encountered a printk deadlock on 5.13 which appears to still affect the latest > > kernel. The deadlock occurs due to printk being used while having the current > > CPU's runqueue locked, and the underlying framebuffer console attempting to lock > > the same runqueue when printk tries to flush the log buffer. > > > > I'm not sure what the *correct* solution is here (don't use printk while having > > a runqueue locked? don't use schedule_work() from the fbcon path? tell printk > > to use one of its lock-less backends?), so I've cc'd all the relevant folks. > > At the moment, printk_deferred() could be used here. It defers the > console handling via irq_work(). I think I've rejected that patch at least twice now :-) John's printk stuff will really land real soon now, right.