From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752423AbbCZT5Z (ORCPT ); Thu, 26 Mar 2015 15:57:25 -0400 Received: from mail-pd0-f174.google.com ([209.85.192.174]:34335 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbbCZT5X (ORCPT ); Thu, 26 Mar 2015 15:57:23 -0400 Message-ID: <55146509.4020809@virtuousgeek.org> Date: Thu, 26 Mar 2015 12:59:05 -0700 From: Jesse Barnes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Vetter , Peter Hurley CC: Imre Deak , Greg Kroah-Hartman , Jiri Slaby , Linux Kernel Mailing List Subject: Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order References: <1418681761-3709-1-git-send-email-imre.deak@intel.com> <1418681761-3709-3-git-send-email-imre.deak@intel.com> <20141216075300.GI2711@phenom.ffwll.local> <1418725405.3185.31.camel@ideak-mobl> <54902AA1.7080301@hurleysoftware.com> <1418740692.7338.33.camel@intelbox> <5490491E.70102@hurleysoftware.com> <1418746939.7338.56.camel@intelbox> <549068A4.3020702@hurleysoftware.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/16/2014 09:42 AM, Daniel Vetter wrote: > On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley wrote: >> On 12/16/2014 11:22 AM, Imre Deak wrote: >>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote: >>>> Fine. Just another expedient fix piled on top of other expedient fixes >>>> that go back past 3.9 with no end in sight. >>> >>> I'm also happy to look into narrowing down the scope of console_lock in >>> fbdev/fbcon as was suggested. But doing that as a follow-up to this >>> change still makes sense to me since it will take more time and have the >>> risk of regressions that are not related to what this change fixes. >> >> I apologize for my tone. I'm not blaming you for the current situation, >> nor is it your responsibility to go fix vt/fbcon/fbdev driver stack >> inversion. I'm just trying to bring some awareness of the larger scope, >> so that collectively we take action and resolve the underlying problems. > > Yeah I guess I should tune down my NACK to a Grumpy-if-merged-by too. > We have a lot of nonoptimal solutions at hand here :( So where does that leave us with this fix? Should we wait for someone to come along and do all the rework? Imre said he'd be willing to do it, but still feels this fix makes sense. Or we could just abandon the fb layer altogether (my preference). In that case fixing this is fine, since we'll be able to ignore it for configs that switch over to using !fbdev and kmscon. Thanks, Jesse