linux-kernel - Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume

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 for Android: free password hash cracker in your pocket

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

Message-ID: <e2336ca0c80cf43f018fcb797de3441d.squirrel@webmail.greenhost.nl>
Date:	Wed, 9 Feb 2011 11:20:46 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	"Chris Wilson" <chris@...is-wilson.co.uk>
Cc:	"Jeff Chua" <jeff.chua.linux@...il.com>,
	"Takashi Iwai" <tiwai@...e.de>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, "Len Brown" <lenb@...nel.org>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_

On Wed, February 9, 2011 10:32, Chris Wilson wrote:
> On Wed, 9 Feb 2011 03:56:36 +0100 (CET), "Indan Zupancic" <indan@....nu> wrote:
>> All in all it seems quite wrong, no matter if it happens to work, because
>> it depends on the calling order done by the drm layer. If *_crtc_enable()
>> is called instead it won't do anything because of that active = true thing.
>> This seems to be happening in your case.
>
> The order is very well defined.
>
> modesetting (upon resume we set the previous mode):
>   for each enabled crtc:
>     crtc_helper->prepare -> intel_crtc_disable()
>     crtc->mode_set -> intel_crtc_mode_set()
>     crtc_helper->commit -> intel_crtc_enable()
>   for each !enabled crtc:
>     crtc->disable -> intel_crtc_disable()

Prepare for what? That could mean anything. Is it only used to
prepare changing a mode, or suspend, or what? Same for commit.
Should it have been named modes_set_prepare and mode_set_commit?

It's clear if you've worked a lot on the code, but if you're just
debugging it's had to tell when anything will be called, the
function pointer chasing isn't fun. And that doesn't guarantee
a driver function won't be called in a different way in the
future anyway.

I'd go as far as saying that if that's always the order, then
just get rid of prepare and commit and do what's needed in the
mode_set function. If prepare and commit don't have any other
purpose or reason for existence.

And back to the original thing, where does that reset() callback
fit in? It's absent from the very well defined order. And judging
by its name, it should be okay to call at any moment, but it seems
that isn't the case.

But the real wrong thing is fiddling with "active" outside of those
state changing functions to force a certain behaviour later on if a
specific function is called just after this (fingers crossed).

My advise is to just remove that active = true line and fix any
breakage that results in some other way. It acts as an out-of-band
message to *crtc_disable() to re-disable already disabled crtcs,
which doesn't always work (either now or in the future). If the state
wasn't already messed up, it is after doing the active = true thing.

Greetings,

Indan

--
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/