Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31EF4C64ED6 for ; Fri, 24 Feb 2023 03:30:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229933AbjBXDaa (ORCPT ); Thu, 23 Feb 2023 22:30:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229915AbjBXDa2 (ORCPT ); Thu, 23 Feb 2023 22:30:28 -0500 Received: from smtpbgbr2.qq.com (smtpbgbr2.qq.com [54.207.22.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE3AD4FAB0 for ; Thu, 23 Feb 2023 19:30:22 -0800 (PST) X-QQ-mid: bizesmtp75t1677209379t52359rj Received: from [10.4.23.76] ( [58.240.82.166]) by bizesmtp.qq.com (ESMTP) with id ; Fri, 24 Feb 2023 11:29:38 +0800 (CST) X-QQ-SSF: 01400000000000I0Z000000A0000000 X-QQ-FEAT: HPkwb3INVpDW35QzUyXHm5GCtuksjtfPvVGoC8YsFJk3IM6h0WzQQeHhFRwP0 JFZDYZce03hVWkDKYqwCgXo7iksu3ZBfSgEfD1jwR5autpuiNHtuitvTrm4humQTt9rBh+f GX6FMBgdImF8m375SY58G9/+0c2TB80ibtmr2CyJhGiRbqOVB8uJfW6NXN9C/evW224OcNe ueXeDdRafWeJZOMZr2qhz8XJGrfd60YXoltEfq2fzeaxRmuXG5htAQq1EM8ha9kXQCZNEo7 QRIRE+Dy3tjxebCgz+Xw88qfAsqoUSviz8tLjls37H0z4hVDnOixvtJKLl4811AIccUdcy6 NellOjajW2Fay2rUwmQzl37/CyAVZa0Oczed2Mmsu2H81X8c8AEWGTQ4pVlLUJb0LSvzOrz X-QQ-GoodBg: 1 Message-ID: Date: Fri, 24 Feb 2023 11:29:36 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v2] drm/vmwgfx: Work around VMW_ALLOC_DMABUF To: Zack Rusin , "daniel@ffwll.ch" , "dri-devel@lists.freedesktop.org" , Linux-graphics-maintainer , "airlied@gmail.com" , "linux-kernel@vger.kernel.org" References: <20230223070405.20228-1-tangmeng@uniontech.com> <113C6E516C95FA38+f2633fe9-fb5a-616e-0e35-7559750544c9@uniontech.com> <2bc1750b4c3ebebf84c106b903178e5236dc396e.camel@vmware.com> From: Meng Tang In-Reply-To: <2bc1750b4c3ebebf84c106b903178e5236dc396e.camel@vmware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:uniontech.com:qybglogicsvr:qybglogicsvr7 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/2/24 11:13, Zack Rusin wrote: > > That's correct. That's the way this works. The ioctl is allocating a buffer, there's > no infinite space for buffers on a system and, given that your app just allocates > and never frees buffers, at some point the space will run out and the ioctl will > return a failure. > Do you mean that users without certain privileges can access allocate a buffer because it is designed like this? so we don't need to block users without certain privileges to VMW_ALLOC_DMABUF success? > As to the stack trace, I'm not sure what kernel you were testing it on so I don't > have access to the full log but I can't reproduce it and there was a change fixing > exactly this (i.e. buffer failed allocation but we were still accessing it) that was > fixed in in 6.2 in commit 1a6897921f52 ("drm/vmwgfx: Stop accessing buffer objects > which failed init") the change was backported as well, so you should be able to > verify on any kernel with it. > > z > Thank you, the kernel version of my environment is lower than 6.2, I will verify on my kernel with commit 1a6897921f52 ("drm/vmwgfx: Stop accessing buffer objects which failed init").