linux-kernel - 回复: [PATCH] drm/atomic-helper: Call stall_checks() before allocate drm_crtc

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]

Date:   Mon, 6 Nov 2023 21:26:15 +0800
From:   <oushixiong@...inos.cn>
To:     "'Maxime Ripard'" <mripard@...nel.org>
Cc:     "'Maarten Lankhorst'" <maarten.lankhorst@...ux.intel.com>,
        "'Thomas Zimmermann'" <tzimmermann@...e.de>,
        "'David Airlie'" <airlied@...il.com>,
        "'Daniel Vetter'" <daniel@...ll.ch>,
        <dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>
Subject: 回复: [PATCH] drm/atomic-helper: Call stall_checks() before allocate drm_crtc_commit

Hi,  
I think it will cause memory leaks if too many nonblock commit works return
-EBUSY.
You can try to send large number of nonblock commits by
drmModeAtomicCommit().

-----邮件原件-----
发件人: Maxime Ripard <mripard@...nel.org> 
发送时间: 2023年11月6日 18:33
收件人: oushixiong <oushixiong@...inos.cn>
抄送: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>; Thomas
Zimmermann <tzimmermann@...e.de>; David Airlie <airlied@...il.com>; Daniel
Vetter <daniel@...ll.ch>; dri-devel@...ts.freedesktop.org;
linux-kernel@...r.kernel.org
主题: Re: [PATCH] drm/atomic-helper: Call stall_checks() before allocate
drm_crtc_commit

Hi,

On Mon, Nov 06, 2023 at 03:37:42PM +0800, oushixiong wrote:
> From: Shixiong Ou <oushixiong@...inos.cn>
> 
> Calling stall_checks() before allocating drm_crtc_commit not after that.
> 
> Signed-off-by: Shixiong Ou <oushixiong@...inos.cn>

Generally speaking, we need much more context than that.

What bug did you encounter that makes you say that it should be moved?
How can we reproduce it? How long has that issue been in the code? What
makes you say that this is the right solution?

Maxime