- Linaro-mm-sig - lists.linaro.org

[PATCH v2 0/2] procfs: Add file path and size to /proc/<pid>/fdinfo

by Kalesh Singh

Hi all, This is v2 of the fdinfo patches. The main update is adding path field only for files with anon inodes. Rebased on 5.19-rc3. The previous cover letter is copied below for convenience. Thanks, Kalesh ----------- Processes can pin shared memory by keeping a handle to it through a file descriptor; for instance dmabufs, memfd, and ashmem (in Android). In the case of a memory leak, to identify the process pinning the memory, userspace needs to: - Iterate the /proc/<pid>/fd/* for each process - Do a readlink on each entry to identify the type of memory from the file path. - stat() each entry to get the size of the memory. The file permissions on /proc/<pid>/fd/* only allows for the owner or root to perform the operations above; and so is not suitable for capturing the system-wide state in a production environment. This issue was addressed for dmabufs by making /proc/*/fdinfo/* accessible to a process with PTRACE_MODE_READ_FSCREDS credentials[1] To allow the same kind of tracking for other types of shared memory, add the following fields to /proc/<pid>/fdinfo/<fd>: path - This allows identifying the type of memory based on common prefixes: e.g. "/memfd...", "/dmabuf...", "/dev/ashmem..." This was not an issued when dmabuf tracking was introduced because the exp_name field of dmabuf fdinfo could be used to distinguish dmabuf fds from other types. size - To track the amount of memory that is being pinned. dmabufs expose size as an additional field in fdinfo. Remove this and make it a common field for all fds. Access to /proc/<pid>/fdinfo is governed by PTRACE_MODE_READ_FSCREDS -- the same as for /proc/<pid>/maps which also exposes the path and size for mapped memory regions. This allows for a system process with PTRACE_MODE_READ_FSCREDS to account the pinned per-process memory via fdinfo. Kalesh Singh (2): procfs: Add 'size' to /proc/<pid>/fdinfo/ procfs: Add 'path' to /proc/<pid>/fdinfo/ Documentation/filesystems/proc.rst | 22 ++++++++++++++++++++-- drivers/dma-buf/dma-buf.c | 1 - fs/libfs.c | 9 +++++++++ fs/proc/fd.c | 18 ++++++++++++++---- include/linux/fs.h | 1 + 5 files changed, 44 insertions(+), 7 deletions(-) base-commit: a111daf0c53ae91e71fd2bfe7497862d14132e3e -- 2.37.0.rc0.161.g10f37bed90-goog

2 years, 11 months

2
9
0 0

[PATCH v1] Fix: SYNCOBJ TIMELINE Test failed.

by jie1zhan

The issue cause by the commit : 721255b527(drm/syncobj: flatten dma_fence_chains on transfer). Because it use the point of dma_fence incorrectly Correct the point of dma_fence by fence array Signed-off-by: jie1zhan <jesse.zhang(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Nirmoy Das <nirmoy.das(a)linux.intel.com> --- drivers/gpu/drm/drm_syncobj.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index 7e48dcd1bee4..d5db818f1c76 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -887,7 +887,7 @@ static int drm_syncobj_flatten_chain(struct dma_fence **f) goto free_fences; dma_fence_put(*f); - *f = &array->base; + *f = array->fences[0]; return 0; free_fences: -- 2.25.1

2 years, 11 months

4
4
0 0

[PATCH] drm/i915: Remove __dma_fence_is_chain()

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> drive-by cleanup Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c b/drivers/gpu/drm/i915/gem/i915_gem_wait.c index 319936f91ac5..667841780514 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c @@ -73,11 +73,6 @@ static void fence_set_priority(struct dma_fence *fence, rcu_read_unlock(); } -static inline bool __dma_fence_is_chain(const struct dma_fence *fence) -{ - return fence->ops == &dma_fence_chain_ops; -} - void i915_gem_fence_wait_priority(struct dma_fence *fence, const struct i915_sched_attr *attr) { @@ -93,7 +88,7 @@ void i915_gem_fence_wait_priority(struct dma_fence *fence, for (i = 0; i < array->num_fences; i++) fence_set_priority(array->fences[i], attr); - } else if (__dma_fence_is_chain(fence)) { + } else if (dma_fence_is_chain(fence)) { struct dma_fence *iter; /* The chain is ordered; if we boost the last, we boost all */ -- 2.36.1

2 years, 11 months

4
3
0 0

Mail Security Alert

by IT HelpDesk Support

2 years, 11 months

1
0
0 0

[PATCH] usb: gadget: Fix unsigned comparison with less than zero

by Jiapeng Chong

This was found by coccicheck: ./drivers/usb/gadget/udc/aspeed_udc.c:496:8-13: WARNING: Unsigned expression compared with zero: chunk >= 0. Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/usb/gadget/udc/aspeed_udc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/aspeed_udc.c b/drivers/usb/gadget/udc/aspeed_udc.c index 1fc15228ff15..387a7abdcee4 100644 --- a/drivers/usb/gadget/udc/aspeed_udc.c +++ b/drivers/usb/gadget/udc/aspeed_udc.c @@ -476,8 +476,8 @@ static int ast_dma_descriptor_setup(struct ast_udc_ep *ep, u32 dma_buf, { struct ast_udc_dev *udc = ep->udc; struct device *dev = &udc->pdev->dev; - u32 offset, chunk; - int count, last; + u32 offset; + int count, last, chunk; if (!ep->descs) { dev_warn(dev, "%s: Empty DMA descs list failure\n", -- 2.20.1.7.g153144c

2 years, 11 months

3
3
0 0

[PATCH 00/22] Fix kernel-doc warnings at linux-next

by Mauro Carvalho Chehab

As we're currently discussing about making kernel-doc issues fatal when CONFIG_WERROR is enable, let's fix all 60 kernel-doc warnings inside linux-next: arch/x86/include/uapi/asm/sgx.h:19: warning: Enum value 'SGX_PAGE_MEASURE' not described in enum 'sgx_page_flags' arch/x86/include/uapi/asm/sgx.h:97: warning: Function parameter or member 'rdi' not described in 'sgx_enclave_user_handler_t' arch/x86/include/uapi/asm/sgx.h:97: warning: Function parameter or member 'rsi' not described in 'sgx_enclave_user_handler_t' arch/x86/include/uapi/asm/sgx.h:97: warning: Function parameter or member 'rdx' not described in 'sgx_enclave_user_handler_t' arch/x86/include/uapi/asm/sgx.h:97: warning: Function parameter or member 'rsp' not described in 'sgx_enclave_user_handler_t' arch/x86/include/uapi/asm/sgx.h:97: warning: Function parameter or member 'r8' not described in 'sgx_enclave_user_handler_t' arch/x86/include/uapi/asm/sgx.h:97: warning: Function parameter or member 'r9' not described in 'sgx_enclave_user_handler_t' arch/x86/include/uapi/asm/sgx.h:124: warning: Function parameter or member 'reserved' not described in 'sgx_enclave_run' drivers/devfreq/devfreq.c:707: warning: Function parameter or member 'val' not described in 'qos_min_notifier_call' drivers/devfreq/devfreq.c:707: warning: Function parameter or member 'ptr' not described in 'qos_min_notifier_call' drivers/devfreq/devfreq.c:717: warning: Function parameter or member 'val' not described in 'qos_max_notifier_call' drivers/devfreq/devfreq.c:717: warning: Function parameter or member 'ptr' not described in 'qos_max_notifier_call' drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:5095: warning: expecting prototype for amdgpu_device_gpu_recover_imp(). Prototype was for amdgpu_device_gpu_recover() instead drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'dmub_outbox_params' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'num_of_edps' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'disable_hpd_irq' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'dmub_aux_transfer_done' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:544: warning: Function parameter or member 'delayed_hpd_wq' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/include/amd_shared.h:224: warning: Enum value 'PP_GFX_DCS_MASK' not described in enum 'PP_FEATURE_MASK' drivers/gpu/drm/scheduler/sched_main.c:999: warning: Function parameter or member 'dev' not described in 'drm_sched_init' drivers/usb/dwc3/core.h:1328: warning: Function parameter or member 'async_callbacks' not described in 'dwc3' drivers/usb/dwc3/gadget.c:675: warning: Function parameter or member 'mult' not described in 'dwc3_gadget_calc_tx_fifo_size' fs/attr.c:36: warning: Function parameter or member 'ia_vfsuid' not described in 'chown_ok' fs/attr.c:36: warning: Excess function parameter 'uid' description in 'chown_ok' fs/attr.c:63: warning: Function parameter or member 'ia_vfsgid' not described in 'chgrp_ok' fs/attr.c:63: warning: Excess function parameter 'gid' description in 'chgrp_ok' fs/namei.c:649: warning: Function parameter or member 'mnt' not described in 'path_connected' fs/namei.c:649: warning: Function parameter or member 'dentry' not described in 'path_connected' fs/namei.c:1089: warning: Function parameter or member 'inode' not described in 'may_follow_link' include/drm/gpu_scheduler.h:463: warning: Function parameter or member 'dev' not described in 'drm_gpu_scheduler' include/linux/dcache.h:309: warning: expecting prototype for dget, dget_dlock(). Prototype was for dget_dlock() instead include/linux/fscache.h:270: warning: Function parameter or member 'cookie' not described in 'fscache_use_cookie' include/linux/fscache.h:270: warning: Excess function parameter 'object' description in 'fscache_use_cookie' include/linux/fscache.h:287: warning: Function parameter or member 'cookie' not described in 'fscache_unuse_cookie' include/linux/fscache.h:287: warning: Excess function parameter 'object' description in 'fscache_unuse_cookie' include/linux/genalloc.h:54: warning: Function parameter or member 'start_addr' not described in 'genpool_algo_t' include/linux/kfence.h:221: warning: Function parameter or member 'slab' not described in '__kfence_obj_info' include/linux/regulator/driver.h:434: warning: Function parameter or member 'n_ramp_values' not described in 'regulator_desc' include/linux/textsearch.h:51: warning: Function parameter or member 'list' not described in 'ts_ops' include/linux/usb/typec_altmode.h:132: warning: Function parameter or member 'altmode' not described in 'typec_altmode_get_orientation' include/net/cfg80211.h:391: warning: Function parameter or member 'bw' not described in 'ieee80211_eht_mcs_nss_supp' include/net/cfg80211.h:437: warning: Function parameter or member 'eht_cap' not described in 'ieee80211_sband_iftype_data' include/net/cfg80211.h:507: warning: Function parameter or member 's1g' not described in 'ieee80211_sta_s1g_cap' include/net/cfg80211.h:1390: warning: Function parameter or member 'counter_offset_beacon' not described in 'cfg80211_color_change_settings' include/net/cfg80211.h:1390: warning: Function parameter or member 'counter_offset_presp' not described in 'cfg80211_color_change_settings' include/net/cfg80211.h:1430: warning: Enum value 'STATION_PARAM_APPLY_STA_TXPOWER' not described in enum 'station_parameters_apply_mask' include/net/cfg80211.h:2195: warning: Function parameter or member 'dot11MeshConnectedToAuthServer' not described in 'mesh_config' include/net/cfg80211.h:2341: warning: Function parameter or member 'short_ssid' not described in 'cfg80211_scan_6ghz_params' include/net/cfg80211.h:3328: warning: Function parameter or member 'kck_len' not described in 'cfg80211_gtk_rekey_data' include/net/cfg80211.h:3698: warning: Function parameter or member 'ftm' not described in 'cfg80211_pmsr_result' include/net/cfg80211.h:3828: warning: Function parameter or member 'global_mcast_stypes' not described in 'mgmt_frame_regs' include/net/cfg80211.h:4977: warning: Function parameter or member 'ftm' not described in 'cfg80211_pmsr_capabilities' include/net/cfg80211.h:5742: warning: Function parameter or member 'u' not described in 'wireless_dev' include/net/cfg80211.h:5742: warning: Function parameter or member 'links' not described in 'wireless_dev' include/net/cfg80211.h:5742: warning: Function parameter or member 'valid_links' not described in 'wireless_dev' include/net/cfg80211.h:6076: warning: Function parameter or member 'is_amsdu' not described in 'ieee80211_data_to_8023_exthdr' include/net/cfg80211.h:6949: warning: Function parameter or member 'sig_dbm' not described in 'cfg80211_notify_new_peer_candidate' include/net/mac80211.h:6250: warning: Function parameter or member 'vif' not described in 'ieee80211_channel_switch_disconnect' mm/memory.c:1729: warning: Function parameter or member 'mt' not described in 'unmap_vmas' net/mac80211/sta_info.h:569: warning: Function parameter or member 'cur_max_bandwidth' not described in 'link_sta_info' Mauro Carvalho Chehab (22): net: cfg80211: fix kernel-doc warnings all over the file net: mac80211: add a missing comma at kernel-doc markup net: mac80211: sta_info: fix a missing kernel-doc struct element x86/sgx: fix kernel-doc markups fscache: fix kernel-doc documentation fs: attr: update vfs uid/gid parameters at kernel-doc fs: namei: address some kernel-doc issues devfreq: shut up kernel-doc warnings drm: amdgpu: amdgpu_dm: fix kernel-doc markups drm: amdgpu: amdgpu_device.c: fix a kernel-doc markup drm: amd: amd_shared.h: Add missing doc for PP_GFX_DCS_MASK drm: gpu_scheduler: fix a kernel-doc warning drm: scheduler: add a missing kernel-doc parameter kfence: fix a kernel-doc parameter mm: document maple tree pointer at unmap_vmas() at memory.c genalloc: add a description for start_addr parameter textsearch: document list inside struct ts_ops regulator: fix a kernel-doc warning dcache: fix a kernel-doc warning usb: typec_altmode: add a missing "@" at a kernel-doc parameter usb: dwc3: document async_callbacks field usb: dwc3: gadget: fix a kernel-doc warning arch/x86/include/uapi/asm/sgx.h | 10 +++++-- drivers/devfreq/devfreq.c | 4 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +++++ drivers/gpu/drm/amd/include/amd_shared.h | 1 + drivers/gpu/drm/scheduler/sched_main.c | 1 + drivers/usb/dwc3/core.h | 2 ++ drivers/usb/dwc3/gadget.c | 1 + fs/attr.c | 4 +-- fs/namei.c | 3 ++ include/drm/gpu_scheduler.h | 1 + include/linux/dcache.h | 2 +- include/linux/fscache.h | 4 +-- include/linux/genalloc.h | 1 + include/linux/kfence.h | 1 + include/linux/regulator/driver.h | 1 + include/linux/textsearch.h | 1 + include/linux/usb/typec_altmode.h | 2 +- include/net/cfg80211.h | 28 ++++++++++++++----- include/net/mac80211.h | 2 +- mm/memory.c | 2 ++ net/mac80211/sta_info.h | 2 ++ 22 files changed, 65 insertions(+), 17 deletions(-) -- 2.36.1

2 years, 11 months

4
4
0 0

[PATCH v7 0/6] Proposal for a GPU cgroup controller

by T.J. Mercier

This patch series revisits the proposal for a GPU cgroup controller to track and limit memory allocations by various device/allocator subsystems. The patch series also contains a simple prototype to illustrate how Android intends to implement DMA-BUF allocator attribution using the GPU cgroup controller. The prototype does not include resource limit enforcements. Changelog: v7: Hide gpucg and gpucg_bucket struct definitions per Michal Koutný. This means gpucg_register_bucket now returns an internally allocated struct gpucg_bucket. Move all public function documentation to the cgroup_gpu.h header. Remove comment in documentation about duplicate name rejection which is not relevant to cgroups users per Michal Koutný. v6: Move documentation into cgroup-v2.rst per Tejun Heo. Rename BINDER_FD{A}_FLAG_SENDER_NO_NEED -> BINDER_FD{A}_FLAG_XFER_CHARGE per Carlos Llamas. Return error on transfer failure per Carlos Llamas. v5: Rebase on top of v5.18-rc3 Drop the global GPU cgroup "total" (sum of all device totals) portion of the design since there is no currently known use for this per Tejun Heo. Fix commit message which still contained the old name for dma_buf_transfer_charge per Michal Koutný. Remove all GPU cgroup code except what's necessary to support charge transfer from dma_buf. Previously charging was done in export, but for non-Android graphics use-cases this is not ideal since there may be a delay between allocation and export, during which time there is no accounting. Merge dmabuf: Use the GPU cgroup charge/uncharge APIs patch into dmabuf: heaps: export system_heap buffers with GPU cgroup charging as a result of above. Put the charge and uncharge code in the same file (system_heap_allocate, system_heap_dma_buf_release) instead of splitting them between the heap and the dma_buf_release. This avoids asymmetric management of the gpucg charges. Modify the dma_buf_transfer_charge API to accept a task_struct instead of a gpucg. This avoids requiring the caller to manage the refcount of the gpucg upon failure and confusing ownership transfer logic. Support all strings for gpucg_register_bucket instead of just string literals. Enforce globally unique gpucg_bucket names. Constrain gpucg_bucket name lengths to 64 bytes. Append "-heap" to gpucg_bucket names from dmabuf-heaps. Drop patch 7 from the series, which changed the types of binder_transaction_data's sender_pid and sender_euid fields. This was done in another commit here: https://lore.kernel.org/all/20220210021129.3386083-4-masahiroy@kernel.org/ Rename: gpucg_try_charge -> gpucg_charge find_cg_rpool_locked -> cg_rpool_find_locked init_cg_rpool -> cg_rpool_init get_cg_rpool_locked -> cg_rpool_get_locked "gpu cgroup controller" -> "GPU controller" gpucg_device -> gpucg_bucket usage -> size Tests: Support both binder_fd_array_object and binder_fd_object. This is necessary because new versions of Android will use binder_fd_object instead of binder_fd_array_object, and we need to support both. Tests for both binder_fd_array_object and binder_fd_object. For binder_utils return error codes instead of struct binder{fs}_ctx. Use ifdef __ANDROID__ to choose platform-dependent temp path instead of a runtime fallback. Ensure binderfs_mntpt ends with a trailing '/' character instead of prepending it where used. v4: Skip test if not run as root per Shuah Khan Add better test logging for abnormal child termination per Shuah Khan Adjust ordering of charge/uncharge during transfer to avoid potentially hitting cgroup limit per Michal Koutný Adjust gpucg_try_charge critical section for charge transfer functionality Fix uninitialized return code error for dmabuf_try_charge error case v3: Remove Upstreaming Plan from gpu-cgroup.rst per John Stultz Use more common dual author commit message format per John Stultz Remove android from binder changes title per Todd Kjos Add a kselftest for this new behavior per Greg Kroah-Hartman Include details on behavior for all combinations of kernel/userspace versions in changelog (thanks Suren Baghdasaryan) per Greg Kroah-Hartman. Fix pid and uid types in binder UAPI header v2: See the previous revision of this change submitted by Hridya Valsaraju at: https://lore.kernel.org/all/20220115010622.3185921-1-hridya@google.com/ Move dma-buf cgroup charge transfer from a dma_buf_op defined by every heap to a single dma-buf function for all heaps per Daniel Vetter and Christian König. Pointers to struct gpucg and struct gpucg_device tracking the current associations were added to the dma_buf struct to achieve this. Fix incorrect Kconfig help section indentation per Randy Dunlap. History of the GPU cgroup controller ==================================== The GPU/DRM cgroup controller came into being when a consensus[1] was reached that the resources it tracked were unsuitable to be integrated into memcg. Originally, the proposed controller was specific to the DRM subsystem and was intended to track GEM buffers and GPU-specific resources[2]. In order to help establish a unified memory accounting model for all GPU and all related subsystems, Daniel Vetter put forth a suggestion to move it out of the DRM subsystem so that it can be used by other DMA-BUF exporters as well[3]. This RFC proposes an interface that does the same. [1]: https://patchwork.kernel.org/project/dri-devel/cover/20190501140438.9506-1-… [2]: https://lore.kernel.org/amd-gfx/20210126214626.16260-1-brian.welty@intel.co… [3]: https://lore.kernel.org/amd-gfx/YCVOl8%2F87bqRSQei@phenom.ffwll.local/ Hridya Valsaraju (3): gpu: rfc: Proposal for a GPU cgroup controller cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory binder: Add flags to relinquish ownership of fds T.J. Mercier (3): dmabuf: heaps: export system_heap buffers with GPU cgroup charging dmabuf: Add gpu cgroup charge transfer function selftests: Add binder cgroup gpu memory transfer tests Documentation/admin-guide/cgroup-v2.rst | 23 + drivers/android/binder.c | 31 +- drivers/dma-buf/dma-buf.c | 80 ++- drivers/dma-buf/dma-heap.c | 38 ++ drivers/dma-buf/heaps/system_heap.c | 28 +- include/linux/cgroup_gpu.h | 146 +++++ include/linux/cgroup_subsys.h | 4 + include/linux/dma-buf.h | 49 +- include/linux/dma-heap.h | 15 + include/uapi/linux/android/binder.h | 23 +- init/Kconfig | 7 + kernel/cgroup/Makefile | 1 + kernel/cgroup/gpu.c | 390 +++++++++++++ .../selftests/drivers/android/binder/Makefile | 8 + .../drivers/android/binder/binder_util.c | 250 +++++++++ .../drivers/android/binder/binder_util.h | 32 ++ .../selftests/drivers/android/binder/config | 4 + .../binder/test_dmabuf_cgroup_transfer.c | 526 ++++++++++++++++++ 18 files changed, 1632 insertions(+), 23 deletions(-) create mode 100644 include/linux/cgroup_gpu.h create mode 100644 kernel/cgroup/gpu.c create mode 100644 tools/testing/selftests/drivers/android/binder/Makefile create mode 100644 tools/testing/selftests/drivers/android/binder/binder_util.c create mode 100644 tools/testing/selftests/drivers/android/binder/binder_util.h create mode 100644 tools/testing/selftests/drivers/android/binder/config create mode 100644 tools/testing/selftests/drivers/android/binder/test_dmabuf_cgroup_transfer.c -- 2.36.0.512.ge40c2bad7a-goog

2 years, 11 months

6
20
0 0

Re: DMA-buf and uncached system memory

by Christian König

Hi Andy, Am 21.06.22 um 12:17 schrieb Andy.Hsieh: > On 2/16/21 4:39 AM, Nicolas Dufresne wrote: > > Le lundi 15 février 2021 à 09:58 +0100, Christian König a écrit : > >> Hi guys, > >> > >> we are currently working an Freesync and direct scan out from system > >> memory on AMD APUs in A+A laptops. > >> > >> On problem we stumbled over is that our display hardware needs to scan > >> out from uncached system memory and we currently don't have a way to > >> communicate that through DMA-buf. > >> > >> For our specific use case at hand we are going to implement something > >> driver specific, but the question is should we have something more > >> generic for this? > > > > Hopefully I'm getting this right, but this makes me think of a long standing > > issue I've met with Intel DRM and UVC driver. If I let the UVC driver allocate > > the buffer, and import the resulting DMABuf (cacheable memory written with a cpu > > copy in the kernel) into DRM, we can see cache artifact being displayed. While > > if I use the DRM driver memory (dumb buffer in that case) it's clean because > > there is a driver specific solution to that. > > > > There is no obvious way for userspace application to know what's is right/wrong > > way and in fact it feels like the kernel could solve this somehow without having > > to inform userspace (perhaps). > > > >> > >> After all the system memory access pattern is a PCIe extension and as > >> such something generic. > >> > >> Regards, > >> Christian. > > > > > > Hi All, > > We also encountered the UVC cache issue on ARMv8 CPU in Mediatek SoC when > using UVC dmabuf-export and feeding the dmabuf to the DRM display by the > following GStreamer command: > > # gst-launch-1.0 v4l2src device=/dev/video0 io-mode=dmabuf ! kmssink > > UVC driver uses videobuf2-vmalloc to allocate buffers and is able to export > them as dmabuf. But UVC uses memcpy() to fill the frame buffer by CPU without > flushing the cache. So if the display hardware directly uses the buffer, the > image shown on the screen will be dirty. > > Here are some experiments: > > 1. By doing some memory operations (e.g. devmem) when streaming the UVC, > the issue is mitigated. I guess the cache is swapped rapidly. > 2. By replacing the memcpy() with memcpy_flushcache() in the UVC driver, > the issue disappears. > 3. By adding .finish callback in videobuf2-vmalloc.c to flush the cache > before returning the buffer, the issue disappears. > > It seems to lack a cache flush stage in either UVC or Display. We may also > need communication between the producer and consumer. Then, they can decide > who is responsible for the flushing to avoid flushing cache unconditionally > leading to the performance impact. Well, that's not what this mail thread was all about. The issue you are facing is that somebody is forgetting to flush caches, but the issue discussed in this thread here is that we have hardware which bypasses caches altogether. As far as I can see in your case UVC just allocates normal cached system memory through videobuf2-vmalloc() and it is perfectly valid to fill that using memcpy(). If some hardware then accesses those buffers bypassing CPU caches then it is the responsibility of the importing driver and/or DMA subsystem to flush the caches accordingly. Regards, Christian. > > Regards, > Andy Hsieh > > ************* MEDIATEK Confidentiality Notice ******************** > The information contained in this e-mail message (including any > attachments) may be confidential, proprietary, privileged, or otherwise > exempt from disclosure under applicable laws. It is intended to be > conveyed only to the designated recipient(s). Any use, dissemination, > distribution, printing, retaining or copying of this e-mail (including its > attachments) by unintended recipient(s) is strictly prohibited and may > be unlawful. If you are not an intended recipient of this e-mail, or believe > that you have received this e-mail in error, please notify the sender > immediately (by replying to this e-mail), delete any and all copies of > this e-mail (including any attachments) from your system, and do not > disclose the content of this e-mail to any other person. Thank you!

2 years, 11 months

3
2
0 0

[PATCH 0/2] procfs: Add file path and size to /proc/<pid>/fdinfo

by Kalesh Singh

Processes can pin shared memory by keeping a handle to it through a file descriptor; for instance dmabufs, memfd, and ashmem (in Android). In the case of a memory leak, to identify the process pinning the memory, userspace needs to: - Iterate the /proc/<pid>/fd/* for each process - Do a readlink on each entry to identify the type of memory from the file path. - stat() each entry to get the size of the memory. The file permissions on /proc/<pid>/fd/* only allows for the owner or root to perform the operations above; and so is not suitable for capturing the system-wide state in a production environment. This issue was addressed for dmabufs by making /proc/*/fdinfo/* accessible to a process with PTRACE_MODE_READ_FSCREDS credentials[1] To allow the same kind of tracking for other types of shared memory, add the following fields to /proc/<pid>/fdinfo/<fd>: path - This allows identifying the type of memory based on common prefixes: e.g. "/memfd...", "/dmabuf...", "/dev/ashmem..." This was not an issued when dmabuf tracking was introduced because the exp_name field of dmabuf fdinfo could be used to distinguish dmabuf fds from other types. size - To track the amount of memory that is being pinned. dmabufs expose size as an additional field in fdinfo. Remove this and make it a common field for all fds. Access to /proc/<pid>/fdinfo is governed by PTRACE_MODE_READ_FSCREDS -- the same as for /proc/<pid>/maps which also exposes the path and size for mapped memory regions. This allows for a system process with PTRACE_MODE_READ_FSCREDS to account the pinned per-process memory via fdinfo. ----- There was some concern about exposing the file path in the RFC[2], to that effect the change was split into separte patches. Also retrieving the file path from fdinfo is guarded by the same capability (PTRACE_MODE_READ) as /proc/<pid>/maps which also exposes file path, so this may not be an issue. [1] https://lore.kernel.org/r/20210308170651.919148-1-kaleshsingh@google.com/ [2] https://lore.kernel.org/r/20220519214021.3572840-1-kaleshsingh@google.com/ Kalesh Singh (2): procfs: Add 'size' to /proc/<pid>/fdinfo/ procfs: Add 'path' to /proc/<pid>/fdinfo/ Documentation/filesystems/proc.rst | 22 ++++++++++++++++++++-- drivers/dma-buf/dma-buf.c | 1 - fs/proc/fd.c | 13 +++++++++---- 3 files changed, 29 insertions(+), 7 deletions(-) base-commit: 8ab2afa23bd197df47819a87f0265c0ac95c5b6a -- 2.36.1.255.ge46751e96f-goog

2 years, 11 months

4
11
0 0

[PATCH] dma-buf: deprecate DMABUF_SYSFS_STATS

by Christian König

Add a warning that this UAPI wasn't such a good idea and shouldn't be used by anybody. That should give us a better chance to remove it at some point and prevents others from running into the same issues. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/Kconfig | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 541efe01abc7..e4dc53a36428 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -75,7 +75,7 @@ menuconfig DMABUF_HEAPS between drivers. menuconfig DMABUF_SYSFS_STATS - bool "DMA-BUF sysfs statistics" + bool "DMA-BUF sysfs statistics (DEPRECATED)" depends on DMA_SHARED_BUFFER help Choose this option to enable DMA-BUF sysfs statistics @@ -85,6 +85,10 @@ menuconfig DMABUF_SYSFS_STATS statistics for the DMA-BUF with the unique inode number <inode_number>. + This option is deprecated and should sooner or later be removed. + Android is the only user of this and it turned out that this resulted + in quite some performance problems. + source "drivers/dma-buf/heaps/Kconfig" endmenu -- 2.25.1

2 years, 11 months

2
1
0 0

[PATCH v2] dma-buf: Move sysfs work out of DMA-BUF export path

by T.J. Mercier

Recently, we noticed an issue where a process went into direct reclaim while holding the kernfs rw semaphore for sysfs in write (exclusive) mode. This caused processes who were doing DMA-BUF exports and releases to go into uninterruptible sleep since they needed to acquire the same semaphore for the DMA-BUF sysfs entry creation/deletion. In order to avoid blocking DMA-BUF export for an indeterminate amount of time while another process is holding the sysfs rw semaphore in exclusive mode, this patch moves the per-buffer sysfs file creation to the default work queue. Note that this can lead to a short-term inaccuracy in the dmabuf sysfs statistics, but this is a tradeoff to prevent the hot path from being blocked. A work_struct is added to dma_buf to achieve this, but as it is unioned with the kobject in the sysfs_entry, dma_buf does not increase in size. Fixes: bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") Originally-by: Hridya Valsaraju <hridya(a)google.com> Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- See the originally submitted patch by Hridya Valsaraju here: https://lkml.org/lkml/2022/1/4/1066 v2 changes: - Defer only sysfs creation instead of creation and teardown per Christian König - Use a work queue instead of a kthread for deferred work per Christian König --- drivers/dma-buf/dma-buf-sysfs-stats.c | 56 ++++++++++++++++++++------- include/linux/dma-buf.h | 14 ++++++- 2 files changed, 54 insertions(+), 16 deletions(-) diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c index 2bba0babcb62..67b0a298291c 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -11,6 +11,7 @@ #include <linux/printk.h> #include <linux/slab.h> #include <linux/sysfs.h> +#include <linux/workqueue.h> #include "dma-buf-sysfs-stats.h" @@ -168,10 +169,46 @@ void dma_buf_uninit_sysfs_statistics(void) kset_unregister(dma_buf_stats_kset); } +static void sysfs_add_workfn(struct work_struct *work) +{ + struct dma_buf_sysfs_entry *sysfs_entry = + container_of(work, struct dma_buf_sysfs_entry, sysfs_add_work); + struct dma_buf *dmabuf = sysfs_entry->dmabuf; + + /* + * A dmabuf is ref-counted via its file member. If this handler holds the only + * reference to the dmabuf, there is no need for sysfs kobject creation. This is an + * optimization and a race; when the reference count drops to 1 immediately after + * this check it is not harmful as the sysfs entry will still get cleaned up in + * dma_buf_stats_teardown, which won't get called until the final dmabuf reference + * is released, and that can't happen until the end of this function. + */ + if (file_count(dmabuf->file) > 1) { + /* + * kobject_init_and_add expects kobject to be zero-filled, but we have populated it + * (the sysfs_add_work union member) to trigger this work function. + */ + memset(&dmabuf->sysfs_entry->kobj, 0, sizeof(dmabuf->sysfs_entry->kobj)); + dmabuf->sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; + if (kobject_init_and_add(&dmabuf->sysfs_entry->kobj, &dma_buf_ktype, NULL, + "%lu", file_inode(dmabuf->file)->i_ino)) { + kobject_put(&dmabuf->sysfs_entry->kobj); + dmabuf->sysfs_entry = NULL; + } + } else { + /* + * Free the sysfs_entry and reset the pointer so dma_buf_stats_teardown doesn't + * attempt to operate on it. + */ + kfree(dmabuf->sysfs_entry); + dmabuf->sysfs_entry = NULL; + } + dma_buf_put(dmabuf); +} + int dma_buf_stats_setup(struct dma_buf *dmabuf) { struct dma_buf_sysfs_entry *sysfs_entry; - int ret; if (!dmabuf || !dmabuf->file) return -EINVAL; @@ -181,25 +218,16 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf) return -EINVAL; } - sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); + sysfs_entry = kmalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); if (!sysfs_entry) return -ENOMEM; - sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; sysfs_entry->dmabuf = dmabuf; - dmabuf->sysfs_entry = sysfs_entry; - /* create the directory for buffer stats */ - ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, - "%lu", file_inode(dmabuf->file)->i_ino); - if (ret) - goto err_sysfs_dmabuf; + INIT_WORK(&dmabuf->sysfs_entry->sysfs_add_work, sysfs_add_workfn); + get_dma_buf(dmabuf); /* This reference will be dropped in sysfs_add_workfn. */ + schedule_work(&dmabuf->sysfs_entry->sysfs_add_work); return 0; - -err_sysfs_dmabuf: - kobject_put(&sysfs_entry->kobj); - dmabuf->sysfs_entry = NULL; - return ret; } diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 2097760e8e95..0200caa3c515 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -22,6 +22,7 @@ #include <linux/fs.h> #include <linux/dma-fence.h> #include <linux/wait.h> +#include <linux/workqueue.h> struct device; struct dma_buf; @@ -365,7 +366,7 @@ struct dma_buf { */ const char *name; - /** @name_lock: Spinlock to protect name acces for read access. */ + /** @name_lock: Spinlock to protect name access for read access. */ spinlock_t name_lock; /** @@ -441,6 +442,7 @@ struct dma_buf { __poll_t active; } cb_in, cb_out; + #ifdef CONFIG_DMABUF_SYSFS_STATS /** * @sysfs_entry: @@ -449,7 +451,15 @@ struct dma_buf { * `DMA-BUF statistics`_ for the uapi this enables. */ struct dma_buf_sysfs_entry { - struct kobject kobj; + union { + struct kobject kobj; + + /** @sysfs_add_work: + * + * For deferred sysfs kobject creation using a workqueue. + */ + struct work_struct sysfs_add_work; + }; struct dma_buf *dmabuf; } *sysfs_entry; #endif -- 2.36.0.550.gb090851708-goog

2 years, 11 months

5
22
0 0

[PATCH] usb: gadget: Remove unnecessary print function dev_err()

by Jiapeng Chong

The print function dev_err() is redundant because platform_get_irq() already prints an error. This was found by coccicheck: ./drivers/usb/gadget/udc/aspeed_udc.c:1546:2-9: line 1546 is redundant because platform_get_irq() already prints an error. Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/usb/gadget/udc/aspeed_udc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/udc/aspeed_udc.c b/drivers/usb/gadget/udc/aspeed_udc.c index 1fc15228ff15..2c3dc80d6b8c 100644 --- a/drivers/usb/gadget/udc/aspeed_udc.c +++ b/drivers/usb/gadget/udc/aspeed_udc.c @@ -1543,7 +1543,6 @@ static int ast_udc_probe(struct platform_device *pdev) /* Find interrupt and install handler */ udc->irq = platform_get_irq(pdev, 0); if (udc->irq < 0) { - dev_err(&pdev->dev, "Failed to get interrupt\n"); rc = udc->irq; goto err; } -- 2.20.1.7.g153144c

2 years, 11 months

2
1
0 0

Re: [PATCH] drivers: tty: serial: Add missing of_node_put() in serial-tegra.c

by Greg KH

On Wed, Jun 15, 2022 at 06:48:33PM +0800, heliang wrote: > In tegra_uart_init(), of_find_matching_node() will return a node > pointer with refcount incremented. We should use of_node_put() > when it is not used anymore. > > Signed-off-by: heliang <windhl(a)126.com> We need a real name please, one you sign documents with. thanks, greg k-h

2 years, 11 months

1
0
0 0

[PATCH] dma-buf: Don't use typeof in va_arg

by Wan Jiabing

Fix following coccicheck warning: ./drivers/dma-buf/st-dma-fence-unwrap.c:75:39-45: ERROR: reference preceded by free on line 70 Use 'struct dma_fence *' instead of 'typeof(*fences)' to avoid this warning and also fix other 'typeof(*fences)' to make them consistent. Fixes: 0c5064fa8d5a ("dma-buf: cleanup dma_fence_unwrap selftest v2") Signed-off-by: Wan Jiabing <wanjiabing(a)vivo.com> --- drivers/dma-buf/st-dma-fence-unwrap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c index 4105d5ea8dde..1137a6d90b32 100644 --- a/drivers/dma-buf/st-dma-fence-unwrap.c +++ b/drivers/dma-buf/st-dma-fence-unwrap.c @@ -56,7 +56,7 @@ static struct dma_fence *mock_array(unsigned int num_fences, ...) va_start(valist, num_fences); for (i = 0; i < num_fences; ++i) - fences[i] = va_arg(valist, typeof(*fences)); + fences[i] = va_arg(valist, struct dma_fence *); va_end(valist); array = dma_fence_array_create(num_fences, fences, @@ -72,7 +72,7 @@ static struct dma_fence *mock_array(unsigned int num_fences, ...) error_put: va_start(valist, num_fences); for (i = 0; i < num_fences; ++i) - dma_fence_put(va_arg(valist, typeof(*fences))); + dma_fence_put(va_arg(valist, struct dma_fence *)); va_end(valist); return NULL; } -- 2.36.1

2 years, 12 months

3
3
0 0

E-mail Account Notification For linaro-mm-sig@lists.linaro.org !!!

by Noreply＠lists.linaro.org

3 years

1
0
0 0

[PATCH] dma-fence: allow dma fence to have their own lock

by Sergey Senozhatsky

RFC I don't have a good name for this yet and I did not spend any time on documentataion (for that reason) We create fences (out fences) as part of operations execution, which are short-lived objects, we want to release all memory after operation execution is completed or when operation gets cancelled/deleted via ioctl(). This creates a bit of a problem. DMA fences are refcounted objects and exporter never knows when importer imports a fence or puts its refcount, so exporter never knows when fence will be destoyed, which should not be a problem for refcounted objects, but here comes the twist... operation A - creates and exports out fence X ... user-space imports fence X operation A - finishes execution, signals fence X kfree operation A, put dma_fence DMA fences are designed to borrow spinlock that DMA fences use to protect struct dma_fence members: struct dma_fence { spinlock_t *lock; const struct dma_fence_ops *ops; ..... }; void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, spinlock_t *lock, u64 context, u64 seqno); So the `lock` should have at least same lifespan as the DMA fence that borrows it, which is impossible to guarantee in our case. When we kfree operation A struct we also kfree ->lock that operation lends to DMA fence, which outlives operation A (depending on what fence importers do and when they drop imported fence refcount). This patch adds a new memnber to struct dma_fence: __lock_inplace. Which is a lock that DMA fence will use to protect its own data when it cannot reliably borrow a lock from the outside object. I also had a patch that puts inplace and borrowed locks to an unnamed uninon and adds one more dma_fence_flag_bits to distinguish between fences with borrowed and inplace locks struct dma_fence { uninon { spinlock_t *lock; spinlock_t __lock_inplace; }; ... }; And then instead of locking/unlocking ->lock directly we would use dma_fence_lock_irqsave()/dma_fence_unlock_irqrestore() macros which would check fence flags and either use borrowed lock or inplace lock. But after seeing how owten drivers directly access fence ->lock I decided to scratch that approach and just add extra spinlock member. Not-Yet-Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> --- drivers/dma-buf/dma-fence.c | 10 ++++++++++ include/linux/dma-fence.h | 6 ++++++ 2 files changed, 16 insertions(+) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 066400ed8841..7ae40b8adb73 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -958,3 +958,13 @@ dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, trace_dma_fence_init(fence); } EXPORT_SYMBOL(dma_fence_init); + +void dma_fence_inplace_lock_init(struct dma_fence *fence, + const struct dma_fence_ops *ops, + u64 context, u64 seqno) +{ + spin_lock_init(&fence->__lock_inplace); + + dma_fence_init(fence, ops, &fence->__lock_inplace, context, seqno); +} +EXPORT_SYMBOL(dma_fence_inplace_lock_init); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 1ea691753bd3..6b15a0d2eccf 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -64,6 +64,8 @@ struct dma_fence_cb; */ struct dma_fence { spinlock_t *lock; + spinlock_t __lock_inplace; + const struct dma_fence_ops *ops; /* * We clear the callback list on kref_put so that by the time we @@ -262,6 +264,10 @@ struct dma_fence_ops { void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, spinlock_t *lock, u64 context, u64 seqno); +void dma_fence_inplace_lock_init(struct dma_fence *fence, + const struct dma_fence_ops *ops, + u64 context, u64 seqno); + void dma_fence_release(struct kref *kref); void dma_fence_free(struct dma_fence *fence); void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq); -- 2.36.1.124.g0e6072fb45-goog

3 years

4
12
0 0

[PATCH v2 0/4] Add Toshiba Visconti AFFINE image processing accelerator driver

by Yuji Ishikawa

This series is the AFFINE image processing accelerator driver for Toshiba's ARM SoC, Visconti[0]. This provides DT binding documentation, device driver, MAINTAINER files. The second patch "soc: visconti: Add Toshiba Visconti image processing accelerator common source" is commonly used among acclerator drivers (affine, dnn, dspif, pyramid). Best regards, Yuji [0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recog… dt-bindings: soc: visconti: Add Toshiba Visconti AFFINE image v1 -> v2: - No update soc: visconti: Add Toshiba Visconti image processing accelerator common source v1 -> v2: - apply checkpatch.pl --strict soc: visconti: Add Toshiba Visconti AFFINE image processing accelerator v1 -> v2: - apply checkpatch.pl --strict - rename hwd_AFFINE_xxxx to hwd_affine_xxxx MAINTAINERS: Add entries for Toshiba Visconti AFFINE image processing accelerator v1 -> v2: - No update Change in V2: - apply checkpatch.pl --strict - rename hwd_AFFINE_xxxx to hwd_affine_xxxx Yuji Ishikawa (4): dt-bindings: soc: visconti: Add Toshiba Visconti AFFINE image processing accelerator bindings soc: visconti: Add Toshiba Visconti image processing accelerator common source soc: visconti: Add Toshiba Visconti AFFINE image processing accelerator MAINTAINERS: Add entries for Toshiba Visconti AFFINE image processing accelerator .../soc/visconti/toshiba,visconti-affine.yaml | 53 ++ MAINTAINERS | 2 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/visconti/Kconfig | 7 + drivers/soc/visconti/Makefile | 8 + drivers/soc/visconti/affine/Makefile | 6 + drivers/soc/visconti/affine/affine.c | 451 ++++++++++++++++++ drivers/soc/visconti/affine/hwd_affine.c | 206 ++++++++ drivers/soc/visconti/affine/hwd_affine.h | 83 ++++ drivers/soc/visconti/affine/hwd_affine_reg.h | 45 ++ drivers/soc/visconti/ipa_common.c | 55 +++ drivers/soc/visconti/ipa_common.h | 18 + drivers/soc/visconti/uapi/affine.h | 87 ++++ drivers/soc/visconti/uapi/ipa.h | 88 ++++ 15 files changed, 1111 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/visconti/toshiba,visconti-affine.yaml create mode 100644 drivers/soc/visconti/Kconfig create mode 100644 drivers/soc/visconti/Makefile create mode 100644 drivers/soc/visconti/affine/Makefile create mode 100644 drivers/soc/visconti/affine/affine.c create mode 100644 drivers/soc/visconti/affine/hwd_affine.c create mode 100644 drivers/soc/visconti/affine/hwd_affine.h create mode 100644 drivers/soc/visconti/affine/hwd_affine_reg.h create mode 100644 drivers/soc/visconti/ipa_common.c create mode 100644 drivers/soc/visconti/ipa_common.h create mode 100644 drivers/soc/visconti/uapi/affine.h create mode 100644 drivers/soc/visconti/uapi/ipa.h -- 2.17.1

3 years

4
8
0 0

[syzbot] WARNING in dma_map_sgtable (2)

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 7e062cda7d90 Merge tag 'net-next-5.19' of git://git.kernel.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=172151d3f00000 kernel config: https://syzkaller.appspot.com/x/.config?x=e9d71d3c07c36588 dashboard link: https://syzkaller.appspot.com/bug?extid=3ba551855046ba3b3806 compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12918503f00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1386fa39f00000 Bisection is inconclusive: the issue happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14107ee5f00000 final oops: https://syzkaller.appspot.com/x/report.txt?x=16107ee5f00000 console output: https://syzkaller.appspot.com/x/log.txt?x=12107ee5f00000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3ba551855046ba3b3806(a)syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3610 at kernel/dma/mapping.c:188 dma_map_sgtable+0x203/0x260 kernel/dma/mapping.c:264 Modules linked in: CPU: 0 PID: 3610 Comm: syz-executor162 Not tainted 5.18.0-syzkaller-04943-g7e062cda7d90 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs kernel/dma/mapping.c:188 [inline] RIP: 0010:dma_map_sgtable+0x203/0x260 kernel/dma/mapping.c:264 Code: 75 15 e8 50 5f 14 00 eb cb e8 49 5f 14 00 eb c4 e8 42 5f 14 00 eb bd e8 3b 5f 14 00 0f 0b bd fb ff ff ff eb af e8 2d 5f 14 00 <0f> 0b 31 ed 48 bb 00 00 00 00 00 fc ff df e9 7b ff ff ff 89 e9 80 RSP: 0018:ffffc9000305fd40 EFLAGS: 00010293 RAX: ffffffff81723873 RBX: dffffc0000000000 RCX: ffff88801fbb8000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000002 RBP: ffff8881487e5408 R08: ffffffff81723743 R09: ffffed1003592c9e R10: ffffed1003592c9e R11: 1ffff11003592c9c R12: ffff8881487e5000 R13: ffff88801ac964e0 R14: 0000000000000000 R15: 0000000000000001 FS: 0000555556c2a300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005d84c8 CR3: 000000001f1ef000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> get_sg_table+0xf9/0x150 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0xf5/0x160 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xd8/0x170 drivers/dma-buf/dma-buf.c:1172 dma_buf_ioctl+0x2a0/0x2f0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f8bf9c6dc19 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd7cfae1d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8bf9c6dc19 RDX: 0000000020000100 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f8bf9c31dc0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8bf9c31e50 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

3 years

1
0
0 0

[PATCH v5 0/3] add Aspeed udc driver for ast2600

by Neal Liu

This patch series aim to add Aspeed USB 2.0 Device Controller (udc) driver, including driver itself, device tree node and documentation. Change since v4: - Fix build test warning reported by kernel test robot, including Wtautological-pointer-compare, Wuninitialized, and Wsometimes-uninitialized. Change since v3: - Remove kernel test robot tag since it's a new driver. Change since v2: - Rename device tree nodes. - Fix unusual indentation. Change since v1: - Fix build test warning reported by kernel test robot. - Rename proper name for dt-bindings document. Neal Liu (3): usb: gadget: add Aspeed ast2600 udc driver ARM: dts: aspeed: Add USB2.0 device controller node dt-bindings: usb: add documentation for aspeed udc .../bindings/usb/aspeed,ast2600-udc.yaml | 52 + MAINTAINERS | 7 + arch/arm/boot/dts/aspeed-g6.dtsi | 10 + drivers/usb/gadget/udc/Kconfig | 13 + drivers/usb/gadget/udc/Makefile | 1 + drivers/usb/gadget/udc/aspeed_udc.c | 1596 +++++++++++++++++ 6 files changed, 1679 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml create mode 100644 drivers/usb/gadget/udc/aspeed_udc.c -- 2.25.1

3 years

3
9
0 0

[PATCH] amdgpu: amdgpu_device.c: Removed trailing whitespace

by Mitchell Augustin

Removed trailing whitespace from end of line in amdgpu_device.c Signed-off-by: Mitchell Augustin <kernel(a)mitchellaugustin.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 49f734137f15..c531c05163cf 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3365,7 +3365,7 @@ bool amdgpu_device_asic_has_dc_support(enum amd_asic_type asic_type) */ bool amdgpu_device_has_dc_support(struct amdgpu_device *adev) { - if (amdgpu_sriov_vf(adev) || + if (amdgpu_sriov_vf(adev) || adev->enable_virtual_display || (adev->harvest_ip_mask & AMD_HARVEST_IP_DMU_MASK)) return false; @@ -5762,7 +5762,7 @@ int amdgpu_in_reset(struct amdgpu_device *adev) { return atomic_read(&adev->reset_domain->in_gpu_reset); } - + /** * amdgpu_device_halt() - bring hardware to some kind of halt state * -- 2.36.1

3 years

2
1
0 0

[PATCH] dma-buf: cleanup dma_fence_chain_walk

by Christian König

Use unrcu_pointer() instead of the manual cast. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence-chain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index 06f8ef97c6e8..a0d920576ba6 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -62,8 +62,8 @@ struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence) replacement = NULL; } - tmp = cmpxchg((struct dma_fence __force **)&chain->prev, - prev, replacement); + tmp = unrcu_pointer(cmpxchg(&chain->prev, RCU_INITIALIZER(prev), + RCU_INITIALIZER(replacement))); if (tmp == prev) dma_fence_put(tmp); else -- 2.25.1

3 years

2
1
0 0

Re: Tackling the indefinite/user DMA fence problem

by Daniel Stone

Hi, On Wed, 25 May 2022 at 15:07, Simon Ser <contact(a)emersion.fr> wrote: > On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter <daniel(a)ffwll.ch> wrote: > > > You can add that to the list of reasons why compositors need to stop > > > using buffers with unsignaled fences. There's plenty of other reasons > > > there already (the big one being that otherwise slow clients can slow > > > down the compositor, even if the compositor uses a high priority context > > > and the HW supports preemption). > > > > > > Yeah that's tbh another reason why I think we shouldn't do umf as a > > transparent thing - compositors need to get better anyway, so we might as > > well take this as a chance to do this right. > > As a compositor dev, I agree -- we should definitely be smarter about > this. Note, it would help a lot to have a good way to integrate the > waits into a poll(2) event loop. The same holds for Weston. We're currently working through a bunch of internal infrastructure to be able to handle this. Mutter (aka GNOME) is also really well-placed to be able to do this. Having pollable waits would be really useful, but I don't think it's essential. In my strawman I'm just waking up at the usual just-before-repaint point and checking; if it doesn't make it for this frame then we'll wait for the next frame. If someone submits buffers which take 4 repaint periods to clear then we'll have 3 'unnecessary' wakeups, but given the GPU is already slammed then it's not an efficiency problem I don't think. (I don't know if all the other compositor people share this view.) Cheers, Daniel

3 years

3
2
0 0

Re: Tackling the indefinite/user DMA fence problem

by Daniel Vetter

On Wed, May 25, 2022 at 03:28:41PM +0200, Michel Dänzer wrote: > On 2022-05-25 15:05, Daniel Vetter wrote: > > On Tue, May 17, 2022 at 12:28:17PM +0200, Christian König wrote: > >> Am 09.05.22 um 16:10 schrieb Daniel Vetter: > >>> On Mon, May 09, 2022 at 08:56:41AM +0200, Christian König wrote: > >>>> Am 04.05.22 um 12:08 schrieb Daniel Vetter: > >>>>> > >>>>> If the goal is specifically atomic kms, then there's an entire can of > >>>>> worms there that I really don't want to think about, but it exists: We > >>>>> have dma_fence as out-fences from atomic commit, and that's already > >>>>> massively broken since most drivers allocate some memory or at least take > >>>>> locks which can allocate memory in their commit path. Like i2c. Putting a > >>>>> userspace memory fence as in-fence in there makes that problem > >>>>> substantially worse, since at least in theory you're just not allowed to > >>>>> might_faul in atomic_commit_tail. > >>>> Yes, that's unfortunately one of the goals as well and yes I completely > >>>> agree on the can of worms. But I think I've solved that. > >>>> > >>>> What I do in the patch set is to enforce that the out fence is an user fence > >>>> when the driver supports user in fences as well. > >>>> > >>>> Since user fences doesn't have the memory management dependency drivers can > >>>> actually allocate memory or call I2C functions which takes locks which have > >>>> memory allocation dependencies. > >>>> > >>>> Or do I miss some other reason why you can't fault or allocate memory in > >>>> atomic_commit_tail? At least lockdep seems to be happy about that now. > >>> The problem is a bit that this breaks the uapi already. At least if the > >>> goal is to have this all be perfectly transparent for userspace - as you > >>> as you have multi-gpu setups going on at least. > >> > >> Question here is why do you think there is an UAPI break? We currently wait > >> in a work item already, so where exactly is the problem? > > > > It's a bit washy, but dma_fence and hence implicit sync is supposed to > > finish in finite time. umf just doesn't. > > > > Ofc in reality you can still flood your compositor and they're not very > > robust, but with umf it's trivial to just hang your compositor forever and > > nothing happens. > > You can add that to the list of reasons why compositors need to stop > using buffers with unsignaled fences. There's plenty of other reasons > there already (the big one being that otherwise slow clients can slow > down the compositor, even if the compositor uses a high priority context > and the HW supports preemption). Yeah that's tbh another reason why I think we shouldn't do umf as a transparent thing - compositors need to get better anyway, so we might as well take this as a chance to do this right. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years

1
0
0 0

Tackling the indefinite/user DMA fence problem

by Christian König

Hello everyone, it's a well known problem that the DMA-buf subsystem mixed synchronization and memory management requirements into the same dma_fence and dma_resv objects. Because of this dma_fence objects need to guarantee that they complete within a finite amount of time or otherwise the system can easily deadlock. One of the few good things about this problem is that it is really good understood by now. Daniel and others came up with some documentation: https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html?highlight=dma_… And Jason did an excellent presentation about that problem on last years LPC: https://lpc.events/event/11/contributions/1115/ Based on that we had been able to reject new implementations of infinite/user DMA fences and mitigate the effect of the few existing ones. The still remaining down side is that we don't have a way of using user fences as dependency in both the explicit (sync_file, drm_syncobj) as well as the implicit (dma_resv) synchronization objects, resulting in numerous problems and limitations for things like HMM, user queues etc.... This patch set here now tries to tackle this problem by untangling the synchronization from the memory management. What it does *not* try to do is to fix the existing kernel fences, because I think we now can all agree on that this isn't really possible. To archive this goal what I do in this patch set is to add some parallel infrastructure to cleanly separate normal kernel dma_fence objects from indefinite/user fences: 1. It introduce a DMA_FENCE_FLAG_USER define (after renaming some existing driver defines). To note that a certain dma_fence is an user fence and *must* be ignore by memory management and never used as dependency for normal none user dma_fence objects. 2. The dma_fence_array and dma_fence_chain containers are modified so that they are marked as user fences whenever any of their contained fences are an user fence. 3. The dma_resv object gets a new DMA_RESV_USAGE_USER flag which must be used with indefinite/user fences and separates those into it's own synchronization domain. 4. The existing dma_buf_poll_add_cb() function is modified so that indefinite/user fences are included in the polling. 5. The sync_file synchronization object is modified so that we essentially have two fence streams instead of just one. 6. The drm_syncobj is modified in a similar way. User fences are just ignored unless the driver explicitly states support to wait for them. 7. The DRM subsystem gains a new DRIVER_USER_FENCE flag which drivers can use to indicate the need for user fences. If user fences are used the atomic mode setting starts to support user fences as IN/OUT fences. 8. Lockdep is used at various critical locations to ensure that nobody ever tries to mix user fences with non user fences. The general approach is to just ignore user fences unless a driver stated explicitely support for them. On top of all of this I've hacked amdgpu so that we add the resulting CS fence only as kernel dependency to the dma_resv object and an additional wrapped up with a dma_fence_array and a stub user fence. The result is that the newly added atomic modeset functions now correctly wait for the user fence to complete before doing the flip. And dependent CS don't pipeline any more, but rather block on the CPU before submitting work. After tons of debugging and testing everything now seems to not go up in flames immediately and even lockdep is happy with the annotations. I'm perfectly aware that this is probably by far the most controversial patch set I've ever created and I really wish we wouldn't need it. But we certainly have the requirement for this and I don't see much other chance to get that working in an UAPI compatible way. Thoughts/comments? Regards, Christian.

3 years

4
22
0 0

[PATCH v4 0/3] add Aspeed udc driver for ast2600

by Neal Liu

This patch series aim to add Aspeed USB 2.0 Device Controller (udc) driver, including driver itself, device tree node and documentation. Change since v3: - Remove kernel test robot tag since it's a new driver. Change since v2: - Rename device tree nodes. - Fix unusual indentation. Change since v1: - Fix build test warning reported by kernel test robot. - Rename proper name for dt-bindings document. Neal Liu (3): usb: gadget: add Aspeed ast2600 udc driver ARM: dts: aspeed: Add USB2.0 device controller node dt-bindings: usb: add documentation for aspeed udc .../bindings/usb/aspeed,ast2600-udc.yaml | 52 + MAINTAINERS | 7 + arch/arm/boot/dts/aspeed-g6.dtsi | 10 + drivers/usb/gadget/udc/Kconfig | 13 + drivers/usb/gadget/udc/Makefile | 1 + drivers/usb/gadget/udc/aspeed_udc.c | 1601 +++++++++++++++++ 6 files changed, 1684 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml create mode 100644 drivers/usb/gadget/udc/aspeed_udc.c -- 2.25.1

3 years

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig