linux-kernel - Re: [Intel-gfx] [PATCH v2] drm/i915: dell wyse 3040 shutdown fix

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]

Date:   Wed, 28 Dec 2022 10:50:15 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Alexey Lukyachuk <skif@...f-web.ru>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>
Cc:     tvrtko.ursulin@...ux.intel.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: dell wyse 3040 shutdown fix

On Tue, 27 Dec 2022, Alexey Lukyachuk <skif@...f-web.ru> wrote:
> On Tue, 27 Dec 2022 11:39:25 -0500
> Rodrigo Vivi <rodrigo.vivi@...el.com> wrote:
>
>> On Sun, Dec 25, 2022 at 09:55:08PM +0300, Alexey Lukyanchuk wrote:
>> > dell wyse 3040 doesn't peform poweroff properly, but instead remains in 
>> > turned power on state.
>> 
>> okay, the motivation is explained in the commit msg..
>> 
>> > Additional mutex_lock and 
>> > intel_crtc_wait_for_next_vblank 
>> > feature 6.2 kernel resolve this trouble.
>> 
>> but this why is not very clear... seems that by magic it was found,
>> without explaining what race we are really protecting here.
>> 
>> but even worse is:
>> what about those many random vblank waits in the code? what's the
>> reasoning?
>> 
> I would like to say, that this solution was found in drm-tip repository:
> link: git://anongit.freedesktop.org/drm-tip
> I will quotate original commit message from Ville Syrjälä 
> <ville.syrjala@...ux.intel.com>: "The spec tells us to do a bunch of 
> vblank waits in the audio enable/disable sequences. Make it so."
> So it's just a backport of accepted patch.
> Which i wanna to propagate to stable versions

This is not how stable kernel backports work. Please read [1].

Does v6.2-rc1 work for you? It has all the relevant commits. Which
stable kernel are you trying to backport them to?

Though I must say I find it surprising that these changes would fix a
poweroff issue, and it certainly was not the goal. I'm wondering if it's
just a coincidence due to timing and/or locking changes.

Have you reported an issue at fdo gitlab [2]?


BR,
Jani.



[1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
[2] https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs


-- 
Jani Nikula, Intel Open Source Graphics Center