linux-kernel - Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55146509.4020809@virtuousgeek.org>
Date:	Thu, 26 Mar 2015 12:59:05 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Daniel Vetter <daniel.vetter@...ll.ch>,
	Peter Hurley <peter@...leysoftware.com>
CC:	Imre Deak <imre.deak@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock
 order

On 12/16/2014 09:42 AM, Daniel Vetter wrote:
> On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley <peter@...leysoftware.com> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/