* [PATCH] drm/virtio: fix memory leak of vbuf
@ 2024-04-02 9:39 Weishi Li
2024-04-29 3:05 ` [PATCH] [PATCH RESEND] " Weishi Li
2024-04-29 6:24 ` [PATCH] " Markus Elfring
0 siblings, 2 replies; 10+ messages in thread
From: Weishi Li @ 2024-04-02 9:39 UTC (permalink / raw)
To: airlied, kraxel, gurchetansingh, olvaffe, maarten.lankhorst,
mripard, tzimmermann, daniel
Cc: dri-devel, virtualization, linux-kernel, liweishi
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when virtqueue_add_sgs returns -EIO or -ENOMEM,
it means vbuf upload failed, and vbuf will not be able to be
free by virtio_gpu_dequeue_*_func, resulting in a continuous increase
in memory allocated to vgdev ->vbufs.
Therefore, when upload fails，vbuf needs to be free directly.
Signed-off-by: Weishi Li <liweishi@kylinos.cn>
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index b1a00c0c25a7..26f2e45635c1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
WARN_ON(ret);
+ if (ret < 0 && ret != -ENOSPC) {
+ free_vbuf(vgdev, vbuf);
+ } else {
+ vbuf->seqno = ++vgdev->ctrlq.seqno;
+ trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
- vbuf->seqno = ++vgdev->ctrlq.seqno;
- trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
-
- atomic_inc(&vgdev->pending_commands);
-
+ atomic_inc(&vgdev->pending_commands);
+ }
spin_unlock(&vgdev->ctrlq.qlock);
drm_dev_exit(idx);
@@ -469,6 +471,8 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
spin_lock(&vgdev->cursorq.qlock);
goto retry;
+ else if (ret < 0) {
+ free_vbuf(vgdev, vbuf);
} else {
vbuf->seqno = ++vgdev->cursorq.seqno;
trace_virtio_gpu_cmd_queue(vq,
--
2.25.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
2024-04-02 9:39 [PATCH] drm/virtio: fix memory leak of vbuf Weishi Li
@ 2024-04-29 3:05 ` Weishi Li
2024-04-30 21:34 ` kernel test robot
2024-04-30 22:50 ` kernel test robot
2024-04-29 6:24 ` [PATCH] " Markus Elfring
1 sibling, 2 replies; 10+ messages in thread
From: Weishi Li @ 2024-04-29 3:05 UTC (permalink / raw)
To: liweishi
Cc: airlied, daniel, dri-devel, gurchetansingh, kraxel, linux-kernel,
maarten.lankhorst, mripard, olvaffe, tzimmermann, virtualization
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when virtqueue_add_sgs returns -EIO or -ENOMEM,
it means vbuf upload failed, and vbuf will not be able to be
free by virtio_gpu_dequeue_*_func, resulting in a continuous increase
in memory allocated to vgdev ->vbufs.
Therefore, when upload fails，vbuf needs to be free directly.
Signed-off-by: Weishi Li <liweishi@kylinos.cn>
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index b1a00c0c25a7..26f2e45635c1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
WARN_ON(ret);
+ if (ret < 0 && ret != -ENOSPC) {
+ free_vbuf(vgdev, vbuf);
+ } else {
+ vbuf->seqno = ++vgdev->ctrlq.seqno;
+ trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
- vbuf->seqno = ++vgdev->ctrlq.seqno;
- trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
-
- atomic_inc(&vgdev->pending_commands);
-
+ atomic_inc(&vgdev->pending_commands);
+ }
spin_unlock(&vgdev->ctrlq.qlock);
drm_dev_exit(idx);
@@ -469,6 +471,8 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
spin_lock(&vgdev->cursorq.qlock);
goto retry;
+ else if (ret < 0) {
+ free_vbuf(vgdev, vbuf);
} else {
vbuf->seqno = ++vgdev->cursorq.seqno;
trace_virtio_gpu_cmd_queue(vq,
--
2.25.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
2024-04-29 3:05 ` [PATCH] [PATCH RESEND] " Weishi Li
@ 2024-04-30 21:34 ` kernel test robot
2024-04-30 22:50 ` kernel test robot
1 sibling, 0 replies; 10+ messages in thread
From: kernel test robot @ 2024-04-30 21:34 UTC (permalink / raw)
To: Weishi Li
Cc: oe-kbuild-all, airlied, daniel, dri-devel, gurchetansingh, kraxel,
linux-kernel, maarten.lankhorst, mripard, olvaffe, tzimmermann,
virtualization
Hi Weishi,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.9-rc6 next-20240430]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Weishi-Li/drm-virtio-fix-memory-leak-of-vbuf/20240430-132447
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20240429030541.56702-1-liweishi%40kylinos.cn
patch subject: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20240501/202405010502.1BWe3b2S-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240501/202405010502.1BWe3b2S-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405010502.1BWe3b2S-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/virtio/virtgpu_vq.c: In function 'virtio_gpu_queue_cursor':
>> drivers/gpu/drm/virtio/virtgpu_vq.c:474:9: error: expected '}' before 'else'
474 | else if (ret < 0) {
| ^~~~
vim +474 drivers/gpu/drm/virtio/virtgpu_vq.c
448
449 static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
450 struct virtio_gpu_vbuffer *vbuf)
451 {
452 struct virtqueue *vq = vgdev->cursorq.vq;
453 struct scatterlist *sgs[1], ccmd;
454 int idx, ret, outcnt;
455 bool notify;
456
457 if (!drm_dev_enter(vgdev->ddev, &idx)) {
458 free_vbuf(vgdev, vbuf);
459 return;
460 }
461
462 sg_init_one(&ccmd, vbuf->buf, vbuf->size);
463 sgs[0] = &ccmd;
464 outcnt = 1;
465
466 spin_lock(&vgdev->cursorq.qlock);
467 retry:
468 ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
469 if (ret == -ENOSPC) {
470 spin_unlock(&vgdev->cursorq.qlock);
471 wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
472 spin_lock(&vgdev->cursorq.qlock);
473 goto retry;
> 474 else if (ret < 0) {
475 free_vbuf(vgdev, vbuf);
476 } else {
477 vbuf->seqno = ++vgdev->cursorq.seqno;
478 trace_virtio_gpu_cmd_queue(vq,
479 virtio_gpu_vbuf_ctrl_hdr(vbuf),
480 vbuf->seqno);
481
482 notify = virtqueue_kick_prepare(vq);
483 }
484
485 spin_unlock(&vgdev->cursorq.qlock);
486
487 if (notify)
488 virtqueue_notify(vq);
489
490 drm_dev_exit(idx);
491 }
492
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
2024-04-29 3:05 ` [PATCH] [PATCH RESEND] " Weishi Li
2024-04-30 21:34 ` kernel test robot
@ 2024-04-30 22:50 ` kernel test robot
1 sibling, 0 replies; 10+ messages in thread
From: kernel test robot @ 2024-04-30 22:50 UTC (permalink / raw)
To: Weishi Li
Cc: llvm, oe-kbuild-all, airlied, daniel, dri-devel, gurchetansingh,
kraxel, linux-kernel, maarten.lankhorst, mripard, olvaffe,
tzimmermann, virtualization
Hi Weishi,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.9-rc6 next-20240430]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Weishi-Li/drm-virtio-fix-memory-leak-of-vbuf/20240430-132447
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20240429030541.56702-1-liweishi%40kylinos.cn
patch subject: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
config: hexagon-randconfig-001-20240501 (https://download.01.org/0day-ci/archive/20240501/202405010653.utlwekew-lkp@intel.com/config)
compiler: clang version 15.0.7 (https://github.com/llvm/llvm-project.git 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240501/202405010653.utlwekew-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405010653.utlwekew-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/virtio/virtgpu_vq.c:29:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __raw_readb(PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
^
In file included from drivers/gpu/drm/virtio/virtgpu_vq.c:29:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
^
In file included from drivers/gpu/drm/virtio/virtgpu_vq.c:29:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writeb(value, PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
drivers/gpu/drm/virtio/virtgpu_vq.c:474:2: error: expected expression
else if (ret < 0) {
^
>> drivers/gpu/drm/virtio/virtgpu_vq.c:503:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:523:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:534:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:556:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:580:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:604:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:635:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:654:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:683:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:704:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:729:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:741:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:767:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:790:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:815:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:889:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:919:1: error: function definition is not allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:936:1: error: function definition is not allowed here
{
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
6 warnings and 20 errors generated.
vim +503 drivers/gpu/drm/virtio/virtgpu_vq.c
dc5698e80cf724 Dave Airlie 2013-09-09 492
dc5698e80cf724 Dave Airlie 2013-09-09 493 /* just create gem objects for userspace and long lived objects,
5d883850dc23a5 Rodrigo Siqueira 2018-02-22 494 * just use dma_alloced pages for the queue objects?
5d883850dc23a5 Rodrigo Siqueira 2018-02-22 495 */
dc5698e80cf724 Dave Airlie 2013-09-09 496
dc5698e80cf724 Dave Airlie 2013-09-09 497 /* create a basic resource */
dc5698e80cf724 Dave Airlie 2013-09-09 498 void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
23c897d72ca806 Gerd Hoffmann 2018-10-19 499 struct virtio_gpu_object *bo,
530b28426a94b8 Gerd Hoffmann 2019-03-18 500 struct virtio_gpu_object_params *params,
e2324300f427ff Gerd Hoffmann 2019-08-29 501 struct virtio_gpu_object_array *objs,
530b28426a94b8 Gerd Hoffmann 2019-03-18 502 struct virtio_gpu_fence *fence)
dc5698e80cf724 Dave Airlie 2013-09-09 @503 {
dc5698e80cf724 Dave Airlie 2013-09-09 504 struct virtio_gpu_resource_create_2d *cmd_p;
dc5698e80cf724 Dave Airlie 2013-09-09 505 struct virtio_gpu_vbuffer *vbuf;
dc5698e80cf724 Dave Airlie 2013-09-09 506
dc5698e80cf724 Dave Airlie 2013-09-09 507 cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
dc5698e80cf724 Dave Airlie 2013-09-09 508 memset(cmd_p, 0, sizeof(*cmd_p));
e2324300f427ff Gerd Hoffmann 2019-08-29 509 vbuf->objs = objs;
dc5698e80cf724 Dave Airlie 2013-09-09 510
dc5698e80cf724 Dave Airlie 2013-09-09 511 cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_CREATE_2D);
724cfdfd667a28 Gerd Hoffmann 2018-10-19 512 cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle);
f9659329f222a6 Gerd Hoffmann 2019-03-18 513 cmd_p->format = cpu_to_le32(params->format);
f9659329f222a6 Gerd Hoffmann 2019-03-18 514 cmd_p->width = cpu_to_le32(params->width);
f9659329f222a6 Gerd Hoffmann 2019-03-18 515 cmd_p->height = cpu_to_le32(params->height);
dc5698e80cf724 Dave Airlie 2013-09-09 516
e19d341174b679 Chia-I Wu 2020-02-05 517 virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, fence);
23c897d72ca806 Gerd Hoffmann 2018-10-19 518 bo->created = true;
dc5698e80cf724 Dave Airlie 2013-09-09 519 }
dc5698e80cf724 Dave Airlie 2013-09-09 520
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/virtio: fix memory leak of vbuf
2024-04-02 9:39 [PATCH] drm/virtio: fix memory leak of vbuf Weishi Li
2024-04-29 3:05 ` [PATCH] [PATCH RESEND] " Weishi Li
@ 2024-04-29 6:24 ` Markus Elfring
1 sibling, 0 replies; 10+ messages in thread
From: Markus Elfring @ 2024-04-29 6:24 UTC (permalink / raw)
To: Weishi Li, dri-devel, virtualization, kernel-janitors, Chia-I Wu,
Daniel Vetter, Dave Airlie, Gerd Hoffmann, Gurchetan Singh,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Cc: LKML
…
> Therefore, when upload fails，vbuf needs to be free directly.
Please choose a corresponding imperative wording for an improved change description.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9-rc5#n94
Regards,
Markus
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
@ 2024-05-07 3:38 Weishi Li
2024-05-08 23:55 ` kernel test robot
0 siblings, 1 reply; 10+ messages in thread
From: Weishi Li @ 2024-05-07 3:38 UTC (permalink / raw)
To: airlied, kraxel, gurchetansingh, olvaffe, maarten.lankhorst,
mripard, tzimmermann, daniel
Cc: dri-devel, virtualization, linux-kernel, liweishi
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when the vbuf fails to upload and virtqueue_add_sgs
returns -EIO or -ENOMEM, the vbuf will not be able to be free by
virtio_gpu_dequeue_*_func, resulting in a continuous increase
in memory allocated to vgdev ->vbufs.
Therefore, make virtio_gpu_queue_ctrl_sgs and virtio_gpu_queue_cursor
free vbuf directly after virtqueue_add_sgs returns -EIO or -ENOMEM.
Signed-off-by: Weishi Li <liweishi@kylinos.cn>
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index b1a00c0c25a7..e90751cc97f2 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
WARN_ON(ret);
+ if (ret < 0 && ret != -ENOSPC) {
+ free_vbuf(vgdev, vbuf);
+ } else {
+ vbuf->seqno = ++vgdev->ctrlq.seqno;
+ trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
- vbuf->seqno = ++vgdev->ctrlq.seqno;
- trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
-
- atomic_inc(&vgdev->pending_commands);
-
+ atomic_inc(&vgdev->pending_commands);
+ }
spin_unlock(&vgdev->ctrlq.qlock);
drm_dev_exit(idx);
@@ -469,6 +471,8 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
spin_lock(&vgdev->cursorq.qlock);
goto retry;
+ } else if (ret < 0) {
+ free_vbuf(vgdev, vbuf);
} else {
vbuf->seqno = ++vgdev->cursorq.seqno;
trace_virtio_gpu_cmd_queue(vq,
--
2.25.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
2024-05-07 3:38 [PATCH] [PATCH RESEND] " Weishi Li
@ 2024-05-08 23:55 ` kernel test robot
0 siblings, 0 replies; 10+ messages in thread
From: kernel test robot @ 2024-05-08 23:55 UTC (permalink / raw)
To: Weishi Li, airlied, kraxel, gurchetansingh, olvaffe,
maarten.lankhorst, mripard, tzimmermann, daniel
Cc: llvm, oe-kbuild-all, dri-devel, virtualization, linux-kernel,
liweishi
Hi Weishi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next linus/master v6.9-rc7 next-20240508]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Weishi-Li/drm-virtio-fix-memory-leak-of-vbuf/20240507-114452
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20240507033814.57906-1-liweishi%40kylinos.cn
patch subject: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
config: i386-buildonly-randconfig-001-20240508 (https://download.01.org/0day-ci/archive/20240509/202405090747.y8ofUE7r-lkp@intel.com/config)
compiler: clang version 18.1.4 (https://github.com/llvm/llvm-project e6c3289804a67ea0bb6a86fadbe454dd93b8d855)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240509/202405090747.y8ofUE7r-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405090747.y8ofUE7r-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/virtio/virtgpu_vq.c:474:13: warning: variable 'notify' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
474 | } else if (ret < 0) {
| ^~~~~~~
drivers/gpu/drm/virtio/virtgpu_vq.c:487:6: note: uninitialized use occurs here
487 | if (notify)
| ^~~~~~
drivers/gpu/drm/virtio/virtgpu_vq.c:474:9: note: remove the 'if' if its condition is always false
474 | } else if (ret < 0) {
| ^~~~~~~~~~~~~~
475 | free_vbuf(vgdev, vbuf);
| ~~~~~~~~~~~~~~~~~~~~~~~
476 | } else {
| ~~~~~~
drivers/gpu/drm/virtio/virtgpu_vq.c:455:13: note: initialize the variable 'notify' to silence this warning
455 | bool notify;
| ^
| = 0
1 warning generated.
vim +474 drivers/gpu/drm/virtio/virtgpu_vq.c
448
449 static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
450 struct virtio_gpu_vbuffer *vbuf)
451 {
452 struct virtqueue *vq = vgdev->cursorq.vq;
453 struct scatterlist *sgs[1], ccmd;
454 int idx, ret, outcnt;
455 bool notify;
456
457 if (!drm_dev_enter(vgdev->ddev, &idx)) {
458 free_vbuf(vgdev, vbuf);
459 return;
460 }
461
462 sg_init_one(&ccmd, vbuf->buf, vbuf->size);
463 sgs[0] = &ccmd;
464 outcnt = 1;
465
466 spin_lock(&vgdev->cursorq.qlock);
467 retry:
468 ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
469 if (ret == -ENOSPC) {
470 spin_unlock(&vgdev->cursorq.qlock);
471 wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
472 spin_lock(&vgdev->cursorq.qlock);
473 goto retry;
> 474 } else if (ret < 0) {
475 free_vbuf(vgdev, vbuf);
476 } else {
477 vbuf->seqno = ++vgdev->cursorq.seqno;
478 trace_virtio_gpu_cmd_queue(vq,
479 virtio_gpu_vbuf_ctrl_hdr(vbuf),
480 vbuf->seqno);
481
482 notify = virtqueue_kick_prepare(vq);
483 }
484
485 spin_unlock(&vgdev->cursorq.qlock);
486
487 if (notify)
488 virtqueue_notify(vq);
489
490 drm_dev_exit(idx);
491 }
492
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
@ 2024-05-09 1:52 Weishi Li
2024-07-23 15:52 ` Dmitry Osipenko
0 siblings, 1 reply; 10+ messages in thread
From: Weishi Li @ 2024-05-09 1:52 UTC (permalink / raw)
To: airlied, kraxel, gurchetansingh, olvaffe, maarten.lankhorst,
mripard, tzimmermann, daniel
Cc: dri-devel, virtualization, linux-kernel, liweishi
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when the vbuf fails to upload and virtqueue_add_sgs
returns -EIO or -ENOMEM, the vbuf will not be able to be free by
virtio_gpu_dequeue_*_func, resulting in a continuous increase
in memory allocated to vgdev ->vbufs.
Therefore, make virtio_gpu_queue_ctrl_sgs and virtio_gpu_queue_cursor
free vbuf directly after virtqueue_add_sgs returns -EIO or -ENOMEM.
Signed-off-by: Weishi Li <liweishi@kylinos.cn>
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index b1a00c0c25a7..6701ce9d0ee8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
WARN_ON(ret);
+ if (ret < 0 && ret != -ENOSPC) {
+ free_vbuf(vgdev, vbuf);
+ } else {
+ vbuf->seqno = ++vgdev->ctrlq.seqno;
+ trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
- vbuf->seqno = ++vgdev->ctrlq.seqno;
- trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
-
- atomic_inc(&vgdev->pending_commands);
-
+ atomic_inc(&vgdev->pending_commands);
+ }
spin_unlock(&vgdev->ctrlq.qlock);
drm_dev_exit(idx);
@@ -469,6 +471,9 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
spin_lock(&vgdev->cursorq.qlock);
goto retry;
+ } else if (ret < 0) {
+ free_vbuf(vgdev, vbuf);
+ notify = false;
} else {
vbuf->seqno = ++vgdev->cursorq.seqno;
trace_virtio_gpu_cmd_queue(vq,
--
2.25.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
2024-05-09 1:52 Weishi Li
@ 2024-07-23 15:52 ` Dmitry Osipenko
0 siblings, 0 replies; 10+ messages in thread
From: Dmitry Osipenko @ 2024-07-23 15:52 UTC (permalink / raw)
To: Weishi Li, airlied, kraxel, gurchetansingh, olvaffe,
maarten.lankhorst, mripard, tzimmermann, daniel
Cc: dri-devel, virtualization, linux-kernel
On 5/9/24 04:52, Weishi Li wrote:
> @@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
>
> ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
> WARN_ON(ret);
> + if (ret < 0 && ret != -ENOSPC) {
> + free_vbuf(vgdev, vbuf);
Don't see why -ENOSPC shouldn't free buffer. If you trying to fix a
theoretical leak, then not worth doing it, IMO. Not apparent how to test
this error code path and it's not easy to review it.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
@ 2024-05-22 9:20 Weishi Li
0 siblings, 0 replies; 10+ messages in thread
From: Weishi Li @ 2024-05-22 9:20 UTC (permalink / raw)
To: airlied, kraxel, gurchetansingh, olvaffe, maarten.lankhorst,
mripard, tzimmermann, daniel
Cc: dri-devel, virtualization, linux-kernel, liweishi
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when the vbuf fails to upload and virtqueue_add_sgs
returns -EIO or -ENOMEM, the vbuf will not be able to be free by
virtio_gpu_dequeue_*_func, resulting in a continuous increase
in memory allocated to vgdev ->vbufs.
Therefore, make virtio_gpu_queue_ctrl_sgs and virtio_gpu_queue_cursor
free vbuf directly after virtqueue_add_sgs returns -EIO or -ENOMEM.
Signed-off-by: Weishi Li <liweishi@kylinos.cn>
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index b1a00c0c25a7..6701ce9d0ee8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
WARN_ON(ret);
+ if (ret < 0 && ret != -ENOSPC) {
+ free_vbuf(vgdev, vbuf);
+ } else {
+ vbuf->seqno = ++vgdev->ctrlq.seqno;
+ trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
- vbuf->seqno = ++vgdev->ctrlq.seqno;
- trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), vbuf->seqno);
-
- atomic_inc(&vgdev->pending_commands);
-
+ atomic_inc(&vgdev->pending_commands);
+ }
spin_unlock(&vgdev->ctrlq.qlock);
drm_dev_exit(idx);
@@ -469,6 +471,9 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
spin_lock(&vgdev->cursorq.qlock);
goto retry;
+ } else if (ret < 0) {
+ free_vbuf(vgdev, vbuf);
+ notify = false;
} else {
vbuf->seqno = ++vgdev->cursorq.seqno;
trace_virtio_gpu_cmd_queue(vq,
--
2.25.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-07-23 15:52 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-02 9:39 [PATCH] drm/virtio: fix memory leak of vbuf Weishi Li
2024-04-29 3:05 ` [PATCH] [PATCH RESEND] " Weishi Li
2024-04-30 21:34 ` kernel test robot
2024-04-30 22:50 ` kernel test robot
2024-04-29 6:24 ` [PATCH] " Markus Elfring
-- strict thread matches above, loose matches on Subject: below --
2024-05-07 3:38 [PATCH] [PATCH RESEND] " Weishi Li
2024-05-08 23:55 ` kernel test robot
2024-05-09 1:52 Weishi Li
2024-07-23 15:52 ` Dmitry Osipenko
2024-05-22 9:20 Weishi Li
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).