Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp885572imm; Wed, 11 Jul 2018 12:44:18 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdRQNPCoBkFaVdjPG8F+A6pT2gpKnv54c9PRja0leH5xT7fsGQ+QcCOkASx93V/A8I2JCBv X-Received: by 2002:a17:902:bd42:: with SMTP id b2-v6mr29875594plx.23.1531338257968; Wed, 11 Jul 2018 12:44:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531338257; cv=none; d=google.com; s=arc-20160816; b=VhOLwItXfQ2HHTJs1/m0IFAOFTYNG8m8K08PomdZeSPPxZRrBRwv/kzTZxQAlVVuYX AnuVKoT5zbUCX0+qIy4TBWJIBP2c+AkSt4ufqh8hw3walRkR0nymJcVHDJ2K0j+1dXMs cp6C4uZbXUqPidzLxYxcgTQWWBUUj9zdy3MevEyICnhH4F40Z2K6eqCvM8XAH5ebwpzJ Nue7kgSfBqaHeaSpMtEkOT3Um1+/FP20at5QwxN/iCpSCuB+rE++As11n2dWrC4JDToy 4yaURx0Bdy3B38Ia44/n2jprWOz0caJ0TvfL409cFBThE5aaUrj9adg10W9itZjWMY5V ULRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=0Mc9T0cK3SomEsBSAYC1T7bWSwBgZZ+GVQJfeRumY+E=; b=XVxV7jw2KfXVMSBOBTVFUBsq/1I7P4XcXkP8vseEBK0Rh6bx/qOS8pC7+LBW44rw9a 7FpVyJ7X8dh+XAUxES6Cc6AIVDh6RvMKqLeyqghiJYKCvgRwn/6h3xocOVxKk3EzwqZS 7qm/YH/75ujSuhJPiLVd4C14JB3TS3QBsCqry8aFMpHyrI9O3if2p8peMpXilCaGLwmm yGOi83M4v3qCO14y+7/GeV8NICI8LRQ1rtIoXOjAIc7LIen11WFSsk5AwbCci2AyTR61 XMLAWy0k/dna3BQ3MgXp+f2V9tWqrN+qc3rfisZmzg/Xglt6XfyfMKB01ypRv57Nim+8 K/uA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g75-v6si18071280pfb.37.2018.07.11.12.44.01; Wed, 11 Jul 2018 12:44:17 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732866AbeGKRk1 (ORCPT + 99 others); Wed, 11 Jul 2018 13:40:27 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:40214 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732519AbeGKRk1 (ORCPT ); Wed, 11 Jul 2018 13:40:27 -0400 Received: by mail-wm0-f68.google.com with SMTP id z13-v6so3394957wma.5 for ; Wed, 11 Jul 2018 10:35:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0Mc9T0cK3SomEsBSAYC1T7bWSwBgZZ+GVQJfeRumY+E=; b=jrgratXoIgIkHYDs6xVOxLgxHbUHcE1TxxzZ3GbFXMTJXPObThd3GvUbJSwCg1AZWA f5UkB01m5tBHUJC+dsJGyGjeRYZ+f2qjeGGjGGDO3vdf91pmHOqtG+C6L8N/o2tD2dqJ fAmIxYhmr3do5Pe7K+6sfMAFEDAuY6Azt1hrHKdRFflrzPW6YI3YzNVZwIkj5C0C8/yA h2MdLYZYVBfW9QCOSY772mJJsFvTbmJCCz/a9EBoWbkwGwScZtZy0tXnYWceHq6hTE15 o0niAfx5LkEiUoaJwLpdITc0m/CMn7RAVxV833VRi/FdxM2GY6wtRBTuRRSUZZkgeLJv Vzfw== X-Gm-Message-State: APt69E0dShh4BRvAGxSJpEHtkB1JPBcJYSK0Zt0Oaz1zBjCE/RWtOP/s WuNfdbrejmZjJ6XPWoyM6jY1ug== X-Received: by 2002:a1c:2094:: with SMTP id g142-v6mr16719173wmg.144.1531330504131; Wed, 11 Jul 2018 10:35:04 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id b16-v6sm1782210wrq.62.2018.07.11.10.35.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 10:35:03 -0700 (PDT) Subject: Re: [PATCH v5 2/3] fbcon: Call WARN_CONSOLE_UNLOCKED() where applicable To: Daniel Vetter Cc: Thomas Zimmermann , Steven Rostedt , Petr Mladek , Linux Fbdev development list , Bartlomiej Zolnierkiewicz , Linux Kernel Mailing List , dri-devel , Sergey Senozhatsky References: <20180628090351.15581-1-hdegoede@redhat.com> <20180628090351.15581-3-hdegoede@redhat.com> <717e6337-e7a6-7a92-1c1b-8929a25696b5@suse.de> <20180711105255.32803a3c@gandalf.local.home> <7ec11c96-7dd5-ec12-548e-7c1fa9b883e8@suse.de> <892782ad-4b97-8eda-f5b0-3a893b3a5f84@redhat.com> From: Hans de Goede Message-ID: <2f37f47c-e28e-77fa-2383-96c7d3e77433@redhat.com> Date: Wed, 11 Jul 2018 19:35:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 11-07-18 17:42, Daniel Vetter wrote: > On Wed, Jul 11, 2018 at 5:35 PM, Hans de Goede wrote: >> Hi, >> >> On 11-07-18 17:28, Daniel Vetter wrote: >>> >>> On Wed, Jul 11, 2018 at 5:14 PM, Hans de Goede >>> wrote: >>>> >>>> Hi, >>>> >>>> On 11-07-18 17:07, Thomas Zimmermann wrote: >>>>> >>>>> >>>>> Hi >>>>> >>>>> Am 11.07.2018 um 16:52 schrieb Steven Rostedt: >>>>>> >>>>>> >>>>>> >>>>>> What if you make lockless_register_fb visible to fbcon, and then we can >>>>>> have a macro: >>>>> >>>>> >>>>> >>>>> There are more of these macro invocations under drivers/tty/vt, which >>>>> also mess up the log during debugging. >>>> >>>> >>>> >>>> Hmm, so this option is already broken (in a way) then, my first reaction >>>> to your mail was that we should just remove that option. But that seemed >>>> a bit harsh to me so I've been working on a fix for the last 10 minutes >>>> or so. >>>> >>>> But if it is already broken I'm tempted to just remove the option and >>>> be done with it. We really need less cruft in the fbdev/fbcon code not >>>> more. >>> >>> >>> Please don't remove it, it makes debugging kms driver issues on >>> initial modeset (which is usually run from framebuffer_register, while >>> hodling the console_lock) impossible. >> >> >> OK, so if we don't remove it, we should probably make it so that it >> can be used without triggering any WARN_ONs, which would require changing >> the existing WARN_CONSOLE_UNLOCKED() so that the calls from >> drivers/tty/vt/vt.c >> also do not trigger it ? >> >> I guess one can just ignore the oopses when debugging, but debugging surely >> would be easier if there are just no oopses ? > > I'd say let's only bother with the ones in fbcon.c. Avoids the trouble > with having to expose the fb module option to vt.c somehow. The plan was actually do the things the other way around, add a flag to vt.c which when set disables the WARN_ON calls and then have fbdev[.ko] set that when the fb.lockless_fb_register option is set. > The ones > in vt.c are as old as the git history (from a quick check at least), > and in my debugging they never have been annoying (or I somehow didn't > ever hit them, not idea). There is a #if 1 #define #else #define empty around the WARN_CONSOLE_UNLOCKED() call in include/linux/console.h I've the feeling that is there as a hack to be able to quickly disable the WARN_ONs when debugging. Have you seen Steven's suggestion which he send about the same time as your mail I'm replying to here ? I personally think that doing something like that makes sense (for as long as we have the need for the lockless_fb_register debug hack). Note I've 2 patches ready to go to only fix this in fbcon.c, but I think a more thorough fix makes sense. Regards, Hans