Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp2025180rwe; Fri, 2 Sep 2022 07:30:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR5erZ6i+YxBNfiPaW2V/Eb+rDYmccZZXr4y6ygJTnSoXp5j3vmsWJVbm9tzlpUzZdILqGCz X-Received: by 2002:a17:906:730d:b0:73d:c8a1:a6ae with SMTP id di13-20020a170906730d00b0073dc8a1a6aemr28198281ejc.540.1662129050937; Fri, 02 Sep 2022 07:30:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662129050; cv=none; d=google.com; s=arc-20160816; b=tvPc4t5KpdxoUuJ44Ov58T9caA8PWNA+tYzrEx5ksB6hVUKcSuQiDDGcH/7aFTaitp GRzhOF6uKHLTxUbGh7AK6IOp96ZYKxGHmDdPkEiqtkfjQWjSt2SJnC3Lu5ahPu4RAKed pvv5ORWiUXOdOXgx885zENTYozED4u+0/IkF1ff1AsciIFKREdrfuvmdqWv5e1gLmNp7 M97kzRzHjDghCyX7gAXJt+TiWAv9Lt+hwAP+bTXJELzL95+ljFcIcYP6g/a/rT1EBZa4 msHs07nFN7l2fSfTOF8itYTchor5yi5eLtEVUW7rhAin3DYo6LDNdoQH9V55Ex/TgHAV C8cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=bI28rj0yqAT0LZLHURtExRdMq/cRkb0kP8VkLs9wjco=; b=KgMNQOst1ovds+d95pk3BaJyS96JjJyzFIoCdr29zMeDGgkFHVWIoRPCid59egDZGn 4RbXpxUPTHl1xtsF+rnT6csJkCibi8oS9zdLN/qFXmpjLty94Mupmu4HZ3A+Kjkgyycs dhwCvUne6oBCLzVGCAIOk2RqVKrWHGwjAsw5xEkI7pDtmighb2GaBXqidolAKhKAX6wF Er1SdEZZ1VshGIrRsD3V972ogCL9cqENU0lGMCCTMvCEB7gy0lDyYags+YuEKGf7fQo7 8eXyv9tGSK4xrBBpIgBXQseZNAXTR4CqABmbFGK60L9UvPqqPFU/gHPItVH8wm+H1x21 RQdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NGmcRuTX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x2-20020a05640225c200b00447fd35d76csi1879591edb.615.2022.09.02.07.30.21; Fri, 02 Sep 2022 07:30:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NGmcRuTX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236762AbiIBNzl (ORCPT + 99 others); Fri, 2 Sep 2022 09:55:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238108AbiIBNzE (ORCPT ); Fri, 2 Sep 2022 09:55:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40EFA26121 for ; Fri, 2 Sep 2022 06:29:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 282C4B82B6D for ; Fri, 2 Sep 2022 13:29:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 388ADC433D6; Fri, 2 Sep 2022 13:29:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662125351; bh=Y4J5I0C+hO5AiefuTKxvuCBGeemyxUhAnG6wAehE8dM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NGmcRuTX+8BTaBoTls7R4tK32GXjw+sNLdzp/6ELO0oN6wERQJkAavVBT5TOV8zru jFIyR0g3IFTCtmEgGk3we4gRgN2IDsdkhazt+72+dOFWBntZkx/bIVy7G57sbyuqlp ox2Zh+Bp5VAcCcVZihM5VcK4NyF5UazFol5FyTZo= Date: Fri, 2 Sep 2022 15:29:08 +0200 From: Greg Kroah-Hartman To: Daniel Vetter Cc: Petr Mladek , LKML , DRI Development , Daniel Vetter , Jiri Slaby , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Tetsuo Handa , Xuezhi Zhang , Yangxi Xiang , nick black , Andrew Morton , Luis Chamberlain , "Guilherme G. Piccoli" , Marco Elver , John Ogness , Sebastian Andrzej Siewior , David Gow , tangmeng , Tiezhu Yang , Chris Wilson Subject: Re: [PATCH] kernel/panic: Drop unblank_screen call Message-ID: References: <20220830145004.430545-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 01, 2022 at 09:26:27PM +0200, Daniel Vetter wrote: > On Thu, 1 Sept 2022 at 13:35, Petr Mladek wrote: > > > > On Tue 2022-08-30 16:50:04, Daniel Vetter wrote: > > > console_unblank() does this too (called in both places right after), > > > and with a lot more confidence inspiring approach to locking. > > > > > > Reconstructing this story is very strange: > > > > > > In b61312d353da ("oops handling: ensure that any oops is flushed to > > > the mtdoops console") it is claimed that a printk(" "); flushed out > > > the console buffer, which was removed in e3e8a75d2acf ("[PATCH] > > > Extract and use wake_up_klogd()"). In todays kernels this is done way > > > earlier in console_flush_on_panic with some really nasty tricks. I > > > didn't bother to fully reconstruct this all, least because the call to > > > bust_spinlock(0); gets moved every few years, depending upon how the > > > wind blows (or well, who screamed loudest about the various issue each > > > call site caused). > > > > > > Before that commit the only calls to console_unblank() where in s390 > > > arch code. > > > > > > The other side here is the console->unblank callback, which was > > > introduced in 2.1.31 for the vt driver. Which predates the > > > console_unblank() function by a lot, which was added (without users) > > > in 2.4.14.3. So pretty much impossible to guess at any motivation > > > here. Also afaict the vt driver is the only (and always was the only) > > > console driver implementing the unblank callback, so no idea why a > > > call to console_unblank() was added for the mtdooops driver - the > > > action actually flushing out the console buffers is done from > > > console_unlock() only. > > > > My understanding is that mtdoops is not a real console. The commit > > 4b23aff083649eafa141 ("[MTD] oops and panic message logging to MTD > > device") suggests that it was just (mis)using the console > > infrastructure. > > > > The commit 2e386e4bac90554887e73d ("mtd: mtdoops: refactor as a > > kmsg_dumper") converted it to use the new kmsg_dumper API that > > was created for this use case. > > > > So, I would consider all the mtdoops-related changes as a misuse > > of the console API. > > Ah, that's a good piece of information that I didn't figure out. > > Greg, if you haven't baked in the patch yet, can you perhaps add the > above information from Petr to the commit message? It's already baked, sorry :(