An error when creating a large buffer prevents the use of the same name for future buffers

[DavidAntliff]

Thank you for this useful driver. It works well with u-dma-buf.

There seems to be some state stuck in the Manager after a buffer creation fails. This prevents future buffer creation with the same name.

For example, if I try to create a number of 64 MB buffers, on my system the fourth one fails (presumably due to lack of available contiguous space - it's a 4 GB embedded system):

# echo "create udmabuf0 0x4000000" > /dev/u-dma-buf-mgr
# echo "create udmabuf1 0x4000000" > /dev/u-dma-buf-mgr
# echo "create udmabuf2 0x4000000" > /dev/u-dma-buf-mgr
# echo "create udmabuf3 0x4000000" > /dev/u-dma-buf-mgr

The first three creations are OK. The fourth one is not. The Linux console displays the following in response to the fourth command:

[  153.542163] u-dma-buf-mgr: create udmabuf3 size=67108864
[  153.547967] cma: cma_alloc: reserved: alloc failed, req-size: 16384 pages, ret: -12
[  153.555662] ------------[ cut here ]------------
[  153.560273] WARNING: CPU: 1 PID: 890 at mm/page_alloc.c:5534 __alloc_pages+0x2c4/0xd30
[  153.568200] Modules linked in: uio_dmem_genirq iptable_nat nf_nat iptable_filter u_dma_buf_mgr(O) u_dma_buf(O) uio_pdrv_genirq
[  153.579609] CPU: 1 PID: 890 Comm: sh Tainted: G           O       6.1.5-xilinx-v2023.1 #1
[  153.587782] Hardware name: ZynqMP ZCU208 RevA (DT)
[  153.592563] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  153.599524] pc : __alloc_pages+0x2c4/0xd30
[  153.603620] lr : __dma_direct_alloc_pages.constprop.0+0x148/0x210
[  153.609714] sp : ffff800009c3b690
[  153.613020] x29: ffff800009c3b690 x28: 0000000000000000 x27: ffff0008035e3030
[  153.620157] x26: ffff0008034b1810 x25: ffff00080183c040 x24: ffff8000080c9bc0
[  153.627292] x23: 0000000000000cc4 x22: 000000000000000e x21: 0000000000003fff
[  153.634427] x20: 0000000003ffffff x19: 0000000000000000 x18: 0000000000000006
[  153.641562] x17: 72202c7365676170 x16: 203438333631203a x15: 0720072007200720
[  153.648697] x14: 0720072007200720 x13: ffff8000094b6010 x12: 000000000000057c
[  153.655832] x11: 00000000000001d4 x10: ffff8000094e2010 x9 : ffff8000094b6010
[  153.662967] x8 : 00000000fffff7ff x7 : 0000000000000000 x6 : 80000000fffff800
[  153.670102] x5 : 0000000000005ff4 x4 : 0000000000000000 x3 : 0000000000000000
[  153.677237] x2 : ffff000802050fc0 x1 : 0000000000000001 x0 : ffff800009575000
[  153.684372] Call trace:
[  153.686810]  __alloc_pages+0x2c4/0xd30
[  153.690560]  __dma_direct_alloc_pages.constprop.0+0x148/0x210
[  153.696298]  dma_direct_alloc+0x10c/0x324
[  153.700299]  dma_alloc_attrs+0x80/0xf0
[  153.704048]  udmabuf_object_setup+0x40/0xd0 [u_dma_buf]
[  153.709274]  udmabuf_platform_driver_probe+0x310/0x5d4 [u_dma_buf]
[  153.715455]  platform_probe+0x68/0xc0
[  153.719117]  really_probe+0xbc/0x2dc
[  153.722684]  __driver_probe_device+0x78/0xe0
[  153.726946]  driver_probe_device+0x40/0x120
[  153.731122]  __device_attach_driver+0xb8/0x134
[  153.735566]  bus_for_each_drv+0x7c/0xd4
[  153.739394]  __device_attach+0x9c/0x1a0
[  153.743222]  device_initial_probe+0x14/0x20
[  153.747397]  bus_probe_device+0x98/0xa0
[  153.751225]  device_add+0x374/0x880
[  153.754705]  platform_device_add+0xfc/0x230
[  153.758889]  udmabuf_platform_device_create+0x9c/0x164 [u_dma_buf]
[  153.765071]  u_dma_buf_device_create+0xc0/0xc4 [u_dma_buf]
[  153.770556]  udmabuf_manager_file_write+0x5f4/0x6cc [u_dma_buf_mgr]
[  153.776823]  vfs_write+0xc4/0x3a4
[  153.780129]  ksys_write+0x70/0x104
[  153.783523]  __arm64_sys_write+0x1c/0x2c
[  153.787438]  invoke_syscall+0x54/0x124
[  153.791188]  el0_svc_common.constprop.0+0x44/0xec
[  153.795893]  do_el0_svc+0x2c/0xc0
[  153.799200]  el0_svc+0x2c/0x84
[  153.802246]  el0t_64_sync_handler+0xf4/0x120
[  153.806508]  el0t_64_sync+0x190/0x194
[  153.810163] ---[ end trace 0000000000000000 ]---
[  153.814804] u-dma-buf udmabuf3: dma_alloc_coherent(size=67108864) failed. return(0)
[  153.822467] u-dma-buf u-dma-buf.5.auto: driver setup failed. return=-12
[  153.829335] u-dma-buf u-dma-buf.5.auto: driver installed.
[  153.834741] u-dma-buf: probe of u-dma-buf.5.auto failed with error -12

There's no sysfs entry, confirming that the udmabuf3 buffer was not created:

# ls /sys/class/u-dma-buf/
udmabuf0  udmabuf1  udmabuf2

However if the name udmabuf3 is used again, even with a smaller buffer, it fails to create:

# echo "create udmabuf3 0x10000" > /dev/u-dma-buf-mgr
-sh: echo: write error: Invalid argument

 [  277.351016] u-dma-buf-mgr: create udmabuf3 size=65536
[  277.356122] u-dma-buf: device name(udmabuf3) or id(-2) is already exists
[  277.362827] u-dma-buf: platform device create entry failed. return=-22
[  277.369354] u-dma-buf-mgr: create error: udmabuf3 result = -22

I'm using u-dma-buf-mgr f1a9a01 on Linux 6.1.5-xilinx-v2023.1 aarch64.

[DavidAntliff]

Ok, it turns out that even though the name udmabuf3 has not been created in the /sys/class/u-dma-buf directory, it is still possible to delete it with:

# echo "delete udmabuf3" > /dev/u-dma-buf-mgr

This allows the name to be reused, if it's known ahead of time that it needs to be deleted first.

May I suggest that if the buffer creation fails, the name is dropped (forgotten) by the mgr, rather than retained? That would make it easier for a user-space program to work with u-dma-buf-mgr, because it can use the state of /sys/class/u-dma-buf to know what names are in use. Without this, a program cannot easily discover that a name is unusable as it doesn't appear in sysfs, and would need to pre-emptively attempt to delete any name it wishes to use.

[ikwzm]

Thank you for the issue.

Your remarks are worth considering.
Please give me a little more time.

[ikwzm]

This is a u-dma-buf issue and has been fixed at ikwzm/udmabuf#110.

[DavidAntliff]

Thank you :)

(I will test in due course)