Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp4361507rwe; Tue, 30 Aug 2022 08:48:41 -0700 (PDT) X-Google-Smtp-Source: AA6agR5OzCBN6QdP68zEH5N3zxg9RFLLeVJzIL5zqILLHMOzS7KXEk/CHc6VUNnD749LIU7RJgdm X-Received: by 2002:a17:902:a40f:b0:172:d0c7:ede1 with SMTP id p15-20020a170902a40f00b00172d0c7ede1mr22043618plq.88.1661874521581; Tue, 30 Aug 2022 08:48:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661874521; cv=none; d=google.com; s=arc-20160816; b=UqGprpRvS58P04wTQP1A8cBuM0MoffA9Bn0D3kLlLB9o2LOdYrcjPiU1ZRB/zi9/+B d/+ko0A1D5B5JHFPWkTefd+wBcRb3ktFx3w3+2qygviNdGDbggd7j31ySS46PHJemE2d mF1G5KAqtayF2AulYuTMclkrzNnjaq1LouioRyH1G7ETaIa8V6vAUNhSXzcUVPuklYEg xOYY5kaFQFdwTVQnY+BW4H6uDAn/+Fs2GtAPAF6ft7DxrkRu+1e4oAZHQ4eTebxAhbyr +QI10JsV4hLL0LYFzA+G8oF+X/Gcons0Pi2AVZyu/U8rTZsNzgTJ4zF+GqiOdR5uMLfa ZlwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=kZOaD1B8emphOfywTXzw4uigM54srkRRmu9c5V6NK1A=; b=pDau8a5owUqbbZE+in4wBZHaToeMs4N6LVHLm/xXV3gi1PaQsiSv+r5bcwBdzWrDIs HlJ9FQIRTvVqJHVYrdfYPfSl0PL8LVS0qrv03ppkZbJ9Kwhpp1Dt3A+UhQEiQCYrHjr+ fmvE9SXS54fEY6xksWdd9JgcBbvEGE6xEy8GBH63D3K9eEy3MOiZNzI69K5yhuzD8gUs yHad+0VDbzazpfxnOgdaAD6R3z/gRhZy4dbSNOonyKht5Nua4RjTpJfSGoFszYDuGWeK Obfe8QJjDdvQzCgRWeNN2UN3Dmwv+Ybk29PLm4167P6vgmzG9Cz+wUjQ5W3ja1bYsFke hCgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=TYS4YvSN; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l8-20020a170903244800b0016ee7f02a0fsi10066022pls.397.2022.08.30.08.48.28; Tue, 30 Aug 2022 08:48:41 -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=@ffwll.ch header.s=google header.b=TYS4YvSN; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229481AbiH3Otz (ORCPT + 99 others); Tue, 30 Aug 2022 10:49:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229709AbiH3Otw (ORCPT ); Tue, 30 Aug 2022 10:49:52 -0400 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DDFC2613 for ; Tue, 30 Aug 2022 07:49:51 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id b16so6928673wru.7 for ; Tue, 30 Aug 2022 07:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=kZOaD1B8emphOfywTXzw4uigM54srkRRmu9c5V6NK1A=; b=TYS4YvSN1AwESNxvEaaENxBSTEIASwZ0luttSQjo1X3Lce5ydRuQLu3JwlKvSpKDYs sd0pjW75BkM1hAar8lrW/TM+TVp5OuMrI10WEFguN+TskyaUZcGI1+8MdEPQsnv1sGPt dk283ZnDDTzZjOJq1v0fp6N0Vk60Vx6K3z/Zk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=kZOaD1B8emphOfywTXzw4uigM54srkRRmu9c5V6NK1A=; b=m8LbZ/ZJjcTG31Q91Zax17LMl+274HckrMt6num4Zv+bav6xQN6nZqEf+udPv0+lsa CMTbsdOW+0y/i9velC3Wj+jNaJ8lnWjjqSmhaMDob4NYeHWEMfb2wqAzLgYSI2kbOpmj 9vH+/5+OjCxxjb2wD/ffsoJYqClvGIGbmJIOltQHlN3ArkWYbF+T6Y7lZylIliSpgBy6 4EOacnMsJG29cTlhtU6GaV8k+/IOtkyPl7lYExuujZmaxkpo4woBbAMRI8e/cxw9pYXC ofYu/rEWdxenomuaQqQbIf2lo5dibd/YcXK6afEgBesc+2Diffs6o2gpAszK0RK4wsVg Gw7A== X-Gm-Message-State: ACgBeo2dBC7Wh2SylrnepFNDeQS8KN7WFkWYBe3E5afT7sPahQb35PA0 fqc5BTzUBTZ4UypNA9QVgNrjSH9UWQxC0jB1 X-Received: by 2002:a05:6000:81d:b0:226:dbad:1699 with SMTP id bt29-20020a056000081d00b00226dbad1699mr5622520wrb.212.1661870990105; Tue, 30 Aug 2022 07:49:50 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id n8-20020a5d4848000000b00226d01a4635sm9805359wrs.35.2022.08.30.07.49.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Aug 2022 07:49:49 -0700 (PDT) From: Daniel Vetter To: LKML Cc: DRI Development , Daniel Vetter , Daniel Vetter , Greg Kroah-Hartman , Jiri Slaby , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Xuezhi Zhang , Yangxi Xiang , Tetsuo Handa , nick black , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , John Ogness , Sam Ravnborg Subject: [PATCH] tty/vt: Add console_lock check to vt_console_print() Date: Tue, 30 Aug 2022 16:49:45 +0200 Message-Id: <20220830144945.430528-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220830132803.403744-1-daniel.vetter@ffwll.ch> References: <20220830132803.403744-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,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 I'm scratching my head why we have this printing_lock. Digging through historical git trees shows that: - Added in 1.1.73, and I found absolutely no reason why. - Converted to atomic bitops in 2.1.125pre2, I guess as part of SMP enabling/bugfixes. - Converted to a proper spinlock in b0940003f25d ("vt: bitlock fix") because the hand-rolled atomic version lacked necessary memory barriers. Digging around in lore for that time period did also not shed further light. The only reason I think this might still be relevant today is that (to my understanding at least, ymmv) during an oops we might be printing without console_lock held. See console_flush_on_panic() and the comments in there - we flush out the console buffers irrespective of whether we managed to acquire the right locks. The strange thing is that this reason is fairly recent, because the console flushing was historically done without oops_in_progress set. This only changed in c7c3f05e341a ("panic: avoid deadlocks in re-entrant console drivers"), which removed the call to bust_spinlocks(0) (which decrements oops_in_progress again) before flushing out the console (which back then was open coded as a console_trylock/unlock pair). Note that this entire mess should be properly fixed in the printk/console layer, and not inflicted on each implementation. For now just document what's going on and check that in all other cases callers obey the locking rules. v2: WARN_CONSOLE_UNLOCKED already checks for oops_in_progress (something else that should be fixed I guess), hence remove the open-coded check I've had. Signed-off-by: Daniel Vetter Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: "Ilpo Järvinen" Cc: Daniel Vetter Cc: Xuezhi Zhang Cc: Yangxi Xiang Cc: Tetsuo Handa Cc: nick black Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: John Ogness Cc: Sam Ravnborg -- Note that this applies on top of my earlier vt patch: https://lore.kernel.org/lkml/20220826202419.198535-1-daniel.vetter@ffwll.ch/ Expect more, I'm digging around in here a bit ... -Daniel --- drivers/tty/vt/vt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 4d29e4a17db7..a6be32798fad 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -3083,7 +3083,9 @@ static void vt_console_print(struct console *co, const char *b, unsigned count) ushort start_x, cnt; int kmsg_console; - /* console busy or not yet initialized */ + WARN_CONSOLE_UNLOCKED(); + + /* this protects against concurrent oops only */ if (!spin_trylock(&printing_lock)) return; -- 2.37.2