From patchwork Tue Aug 25 13:45:14 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 7071271 Return-Path: X-Original-To: patchwork-linux-fbdev@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id EB738C05AD for ; Tue, 25 Aug 2015 13:45:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0A6D320875 for ; Tue, 25 Aug 2015 13:45:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1F13F20864 for ; Tue, 25 Aug 2015 13:45:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755145AbbHYNp0 (ORCPT ); Tue, 25 Aug 2015 09:45:26 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:37830 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754813AbbHYNpZ (ORCPT ); Tue, 25 Aug 2015 09:45:25 -0400 Received: by widdq5 with SMTP id dq5so15607721wid.0 for ; Tue, 25 Aug 2015 06:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=es9Z3+dB/NBiWazPBqAJXj3wTig+7LhvigbsiCmZ4qQ=; b=IPlHyGkXYebK1IW1IWY3hyq/b2qULViJmOWaItX/MjR6+QoweBW0OygL/haX4EBzZR 3yz9qsdoGmUoubR292599Guz8ChKqy9XDzkslDfPkJIjP+wiMU0ortIsFcoa74NnRzpT 76IwbT8l3BToxwFiGEMR2ONd1qN9DMhlzsuTA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=es9Z3+dB/NBiWazPBqAJXj3wTig+7LhvigbsiCmZ4qQ=; b=StRUUHshyFi2eFGT+puRJc1IxNJxzSO6F3zbXKRfvhKE/c9/4kGRMfgNLcInV78Z+2 TsC5wKBhieFAuJyYfDL/Vt7LGz1+MHzdBpE16w2w3IQk+F4otLtK+edusLqT7yPm4YUt 0MOg+sTIZyggw2ZzN2+1MOE3Vod9v+lhW8qN4Ev9du8TyTEFJHxBnDAH4JyhcbcX5tH4 OnFTAJBFFJ6rQkoEBZEn3ENkktZhh0P+yDK0rSRemeBr3IfhdRrI2OGpbdxbhWtU8WBr W+oHVqo9HjPd0vNBWpsS5kal70VBnLM5k1RyzzlIm0qjbn1+VNuE9viQhqRHUF4CJGvw GIuA== X-Gm-Message-State: ALoCoQnsYfxo7cZlkxYTf5W3Vw4PvKFyTqROA77rPEfFwR1eRmdCW+7XVA3Wv4R4QXmWRWMGcX/T X-Received: by 10.194.82.167 with SMTP id j7mr50575955wjy.123.1440510324687; Tue, 25 Aug 2015 06:45:24 -0700 (PDT) Received: from biers.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by smtp.gmail.com with ESMTPSA id bi6sm28221946wjc.25.2015.08.25.06.45.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2015 06:45:24 -0700 (PDT) From: Daniel Vetter To: DRI Development Cc: Intel Graphics Development , Daniel Vetter , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , linux-fbdev@vger.kernel.org Subject: [PATCH 4/4] fbdev: Debug knob to register without holding console_lock Date: Tue, 25 Aug 2015 15:45:14 +0200 Message-Id: <1440510314-8633-4-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1440510314-8633-1-git-send-email-daniel.vetter@ffwll.ch> References: <1440510314-8633-1-git-send-email-daniel.vetter@ffwll.ch> Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When the usual fbcon legacy options are enabled we have ->register_framebuffer ->fb notifier chain calls into fbcon ->fbcon sets up console on new fbi ->fbi->set_par ->drm_fb_helper_set_par exercises full kms api And because of locking inversion hilarity all of register_framebuffer is done with the console lock held. Which means that the first time on driver load we exercise _all_ the kms code (all probe paths and modeset paths for everything connected) is under the console lock. That means if anything goes belly-up in that big pile of code nothing ever reaches logfiles (and the machine is dead). Usual tactic to debug that is to temporarily remove those console_lock calls to be able to capture backtraces. I'm fed up writing this patch and recompiling kernels. Hence this patch here to add an unsafe, kernel-taining option to do this at runtime. Cc: Jean-Christophe Plagniol-Villard Cc: Tomi Valkeinen Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/video/fbdev/core/fbmem.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 0705d8883ede..4e73b6f6b1c0 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1608,6 +1608,11 @@ static int do_remove_conflicting_framebuffers(struct apertures_struct *a, return 0; } +static bool lockless_register_fb; +module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400); +MODULE_PARM_DESC(lockless_register_fb, + "Lockless framebuffer registration for debugging [default=off]"); + static int do_register_framebuffer(struct fb_info *fb_info) { int i, ret; @@ -1675,15 +1680,18 @@ static int do_register_framebuffer(struct fb_info *fb_info) registered_fb[i] = fb_info; event.info = fb_info; - console_lock(); + if (!lockless_register_fb) + console_lock(); if (!lock_fb_info(fb_info)) { - console_unlock(); + if (!lockless_register_fb) + console_unlock(); return -ENODEV; } fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event); unlock_fb_info(fb_info); - console_unlock(); + if (!lockless_register_fb) + console_unlock(); return 0; }