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: <000301da10b4$d4e90690$7ebb13b0$@kylinos.cn>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ