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] [thread-next>] [day] [month] [year] [list]
Message-ID: <YVjd7hLKtYG2bkY7@zacax395.localdomain>
Date:   Sun, 3 Oct 2021 00:32:14 +0200
From:   Fernando Ramos <greenfoo@....eu>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc:     Sean Paul <sean@...rly.run>, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
        linux-arm-msm@...r.kernel.org, freedreno@...ts.freedesktop.org,
        nouveau@...ts.freedesktop.org, linux-renesas-soc@...r.kernel.org,
        linux-tegra@...r.kernel.org
Subject: Re: [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use
 DRM_MODESET_LOCK_ALL_* helpers where possible

On 21/10/02 09:13AM, Fernando Ramos wrote:
> 
> Sean, could you revert the whole patch series? I'll have a deeper look into the
> patch set and come up with a v3 where all these issues will be addressed.
> 

Hi Sean,

I now understand the nature of the issue that caused the problem with i915 and
have proceed to remove the global context structure (which revealed a similar
issue in the amdgpu driver).

I have prepared a V3 version of the patch set where these issues should
hopefully be fixed for both the i915 and amdgpu drivers.

In order to prevent causing more disruption, could you tell me what the proper
way to proceed would be? In particular:

  1. Is there any place where I can push my changes so that they are tested
     on a i915 machine? (Some type of automated pool)

  2. I can test the amdgpu driver on my machine but, what about all the other
     architectures? What is the standard procedure? Should I simply publish V3
     and wait for feedback from the different vendors? (I would hate to cause a
     simular situation again)

  3. Should I post V3 on top of drm-next or drm-misc-next?

Thanks for your patience :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ