Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

5 participants
2541 discussions

[PATCH v3 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 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. *** BLURB HERE *** 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

2 years, 7 months

[RFC PATCH] 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 ashsmem (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. [1] https://lore.kernel.org/lkml/20210308170651.919148-1-kaleshsingh@google.com/ Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> --- Documentation/filesystems/proc.rst | 22 ++++++++++++++++++++-- drivers/dma-buf/dma-buf.c | 1 - fs/proc/fd.c | 9 +++++++-- 3 files changed, 27 insertions(+), 5 deletions(-) diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 061744c436d9..ad66d78aca51 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -1922,13 +1922,16 @@ if precise results are needed. 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file --------------------------------------------------------------- This file provides information associated with an opened file. The regular -files have at least four fields -- 'pos', 'flags', 'mnt_id' and 'ino'. +files have at least six fields -- 'pos', 'flags', 'mnt_id', 'ino', 'size', +and 'path'. + The 'pos' represents the current offset of the opened file in decimal form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the file has been created with [see open(2) for details] and 'mnt_id' represents mount ID of the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo for details]. 'ino' represents the inode number of -the file. +the file, 'size' represents the size of the file in bytes, and 'path' +represents the file path. A typical output is:: @@ -1936,6 +1939,8 @@ A typical output is:: flags: 0100002 mnt_id: 19 ino: 63107 + size: 0 + path: /dev/null All locks associated with a file descriptor are shown in its fdinfo too:: @@ -1953,6 +1958,8 @@ Eventfd files flags: 04002 mnt_id: 9 ino: 63107 + size: 0 + path: anon_inode:[eventfd] eventfd-count: 5a where 'eventfd-count' is hex value of a counter. @@ -1966,6 +1973,8 @@ Signalfd files flags: 04002 mnt_id: 9 ino: 63107 + size: 0 + path: anon_inode:[signalfd] sigmask: 0000000000000200 where 'sigmask' is hex value of the signal mask associated @@ -1980,6 +1989,8 @@ Epoll files flags: 02 mnt_id: 9 ino: 63107 + size: 0 + path: anon_inode:[eventpoll] tfd: 5 events: 1d data: ffffffffffffffff pos:0 ino:61af sdev:7 where 'tfd' is a target file descriptor number in decimal form, @@ -1998,6 +2009,8 @@ For inotify files the format is the following:: flags: 02000000 mnt_id: 9 ino: 63107 + size: 0 + path: anon_inode:inotify inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d where 'wd' is a watch descriptor in decimal form, i.e. a target file @@ -2021,6 +2034,8 @@ For fanotify files the format is:: flags: 02 mnt_id: 9 ino: 63107 + size: 0 + path: anon_inode:[fanotify] fanotify flags:10 event-flags:0 fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 @@ -2046,6 +2061,8 @@ Timerfd files flags: 02 mnt_id: 9 ino: 63107 + size: 0 + path: anon_inode:[timerfd] clockid: 0 ticks: 0 settime flags: 01 @@ -2070,6 +2087,7 @@ DMA Buffer files mnt_id: 9 ino: 63107 size: 32768 + path: /dmabuf: count: 2 exp_name: system-heap diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index b1e25ae98302..d61183ff3c30 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -377,7 +377,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) { struct dma_buf *dmabuf = file->private_data; - seq_printf(m, "size:\t%zu\n", dmabuf->size); /* Don't count the temporary reference taken inside procfs seq_show */ seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1); seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name); diff --git a/fs/proc/fd.c b/fs/proc/fd.c index 913bef0d2a36..a8a968bc58f0 100644 --- a/fs/proc/fd.c +++ b/fs/proc/fd.c @@ -54,10 +54,15 @@ static int seq_show(struct seq_file *m, void *v) if (ret) return ret; - seq_printf(m, "pos:\t%lli\nflags:\t0%o\nmnt_id:\t%i\nino:\t%lu\n", + seq_printf(m, "pos:\t%lli\nflags:\t0%o\nmnt_id:\t%i\nino:\t%lu\nsize:\t%zu\n", (long long)file->f_pos, f_flags, real_mount(file->f_path.mnt)->mnt_id, - file_inode(file)->i_ino); + file_inode(file)->i_ino, + file_inode(file)->i_size); + + seq_puts(m, "path:\t"); + seq_file_path(m, file, "\n"); + seq_putc(m, '\n'); /* show_fd_locks() never deferences files so a stale value is safe */ show_fd_locks(m, file, files); base-commit: b015dcd62b86d298829990f8261d5d154b8d7af5 -- 2.36.1.124.g0e6072fb45-goog

2 years, 7 months

Re: [syzbot] WARNING in __dma_map_sg_attrs

by Daniel Vetter

On Sat, Feb 05, 2022 at 12:18:23PM -0800, syzbot wrote: > syzbot has found a reproducer for the following issue on: > > HEAD commit: 0457e5153e0e Merge tag 'for-linus' of git://git.kernel.org.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=11b2637c700000 > kernel config: https://syzkaller.appspot.com/x/.config?x=6f043113811433a5 > dashboard link: https://syzkaller.appspot.com/bug?extid=10e27961f4da37c443b2 > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c65542700000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1163f480700000 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+10e27961f4da37c443b2(a)syzkaller.appspotmail.com Adding Gerd, since this seems to blow up in udmabuf. I wonder why syzbot didn't figure this out, since it seems to have correctly added both dma-api and dma-buf people. Just not the maintainer for the begin_cpu_udmabuf function in the middle of the backtrace? -Daniel > > ------------[ cut here ]------------ > WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > Modules linked in: > CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 > RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 > RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 > RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f > R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 > R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 > FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 > get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 > begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 > dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 > dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:874 [inline] > __se_sys_ioctl fs/ioctl.c:860 [inline] > __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7f62fcf530f9 > 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:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 > RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 > RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > </TASK> > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

2 years, 7 months

[PATCH v2 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 v1: - Fix build test warning reported by kernel test robot. - Rename proper name for dt-bindings document. *** BLURB HERE *** 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

2 years, 7 months

[PATCH 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. *** BLURB HERE *** 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 .../devicetree/bindings/usb/aspeed,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 | 1594 +++++++++++++++++ 6 files changed, 1677 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/aspeed,udc.yaml create mode 100644 drivers/usb/gadget/udc/aspeed_udc.c -- 2.25.1

2 years, 8 months

[PATCH V3 RESEND] dma-buf: ensure unique directory name for dmabuf stats

by Charan Teja Kalla

2 years, 8 months

[PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

by Charan Teja Kalla

2 years, 8 months

[PATCH V2] dmabuf: ensure unique directory name for dmabuf stats

by Charan Teja Kalla

The dmabuf file uses get_next_ino()(through dma_buf_getfile() -> alloc_anon_inode()) to get an inode number and uses the same as a directory name under /sys/kernel/dmabuf/buffers/<ino>. This directory is used to collect the dmabuf stats and it is created through dma_buf_stats_setup(). At current, failure to create this directory entry can make the dma_buf_export() to fail. Now, as the get_next_ino() can definitely give a repetitive inode no causing the directory entry creation to fail with -EEXIST. This is a problem on the systems where dmabuf stats functionality is enabled on the production builds can make the dma_buf_export(), though the dmabuf memory is allocated successfully, to fail just because it couldn't create stats entry. This issue we are able to see on the snapdragon system within 13 days where there already exists a directory with inode no "122602" so dma_buf_stats_setup() failed with -EEXIST as it is trying to create the same directory entry. To make the directory entry as unique, append the unique_id for every inode. With this change the stats directory entries will be in the format of: /sys/kernel/dmabuf/buffers/<inode_number-unique_id>. Signed-off-by: Charan Teja Kalla <quic_charante(a)quicinc.com> --- Changes in V2: -- Used the atomic64_t variable to generate a unique_id to be appended to inode to have an unique directory with name <inode_number-unique_id> -- Suggested by christian -- Updated the ABI documentation -- Identified by Greg. -- Massaged the commit log. Changes in V1: -- Used the inode->i_ctime->tv_secs as an id appended to inode to create the unique directory with name <inode_number-time_in_secs>. -- https://lore.kernel.org/all/1652178212-22383-1-git-send-email-quic_charante… Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers | 10 +++++----- drivers/dma-buf/Kconfig | 6 +++--- drivers/dma-buf/dma-buf-sysfs-stats.c | 8 +++++--- 3 files changed, 13 insertions(+), 11 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers index 5d3bc99..9fffbd3 100644 --- a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -4,19 +4,19 @@ KernelVersion: v5.13 Contact: Hridya Valsaraju <hridya(a)google.com> Description: The /sys/kernel/dmabuf/buffers directory contains a snapshot of the internal state of every DMA-BUF. - /sys/kernel/dmabuf/buffers/<inode_number> will contain the - statistics for the DMA-BUF with the unique inode number - <inode_number> + /sys/kernel/dmabuf/buffers/<inode_number-unique_id> will + contain the statistics for the DMA-BUF with the unique + pair <inode_number-unique_id> Users: kernel memory tuning/debugging tools -What: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name +What: /sys/kernel/dmabuf/buffers/<inode_number-unique_id>/exporter_name Date: May 2021 KernelVersion: v5.13 Contact: Hridya Valsaraju <hridya(a)google.com> Description: This file is read-only and contains the name of the exporter of the DMA-BUF. -What: /sys/kernel/dmabuf/buffers/<inode_number>/size +What: /sys/kernel/dmabuf/buffers/<inode_number-unique_id>/size Date: May 2021 KernelVersion: v5.13 Contact: Hridya Valsaraju <hridya(a)google.com> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 541efe0..5bcbdb1 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -81,9 +81,9 @@ menuconfig DMABUF_SYSFS_STATS Choose this option to enable DMA-BUF sysfs statistics in location /sys/kernel/dmabuf/buffers. - /sys/kernel/dmabuf/buffers/<inode_number> will contain - statistics for the DMA-BUF with the unique inode number - <inode_number>. + /sys/kernel/dmabuf/buffers/<inode_number-unique_id> will contain + statistics for the DMA-BUF with the unique pair + <inode_number-unique_id>. source "drivers/dma-buf/heaps/Kconfig" diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c index 2bba0ba..29e9e23 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -38,8 +38,8 @@ * * The following stats are exposed by the interface: * - * * ``/sys/kernel/dmabuf/buffers/<inode_number>/exporter_name`` - * * ``/sys/kernel/dmabuf/buffers/<inode_number>/size`` + * * ``/sys/kernel/dmabuf/buffers/<inode_number-unique_id>/exporter_name`` + * * ``/sys/kernel/dmabuf/buffers/<inode_number-unique_id>/size`` * * The information in the interface can also be used to derive per-exporter * statistics. The data from the interface can be gathered on error conditions @@ -172,6 +172,7 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf) { struct dma_buf_sysfs_entry *sysfs_entry; int ret; + static atomic64_t unique_id = ATOMIC_INIT(0); if (!dmabuf || !dmabuf->file) return -EINVAL; @@ -192,7 +193,8 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf) /* 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); + "%lu-%lu", file_inode(dmabuf->file)->i_ino, + atomic64_add_return(1, &unique_id)); if (ret) goto err_sysfs_dmabuf; -- 2.7.4

2 years, 8 months

Re: [syzbot] WARNING in drm_gem_shmem_vm_open

by syzbot

syzbot suspects this issue was fixed by commit: commit 0499f419b76f94ede08304aad5851144813ac55c Author: Javier Martinez Canillas <javierm(a)redhat.com> Date: Mon Jan 10 09:56:25 2022 +0000 video: vga16fb: Only probe for EGA and VGA 16 color graphic cards bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=126571e0700000 start commit: 5d6ab0bb408f Merge tag 'xtensa-20211008' of git://github.c.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=32e6048063923b7b dashboard link: https://syzkaller.appspot.com/bug?extid=91525b2bd4b5dff71619 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11073300b00000 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: video: vga16fb: Only probe for EGA and VGA 16 color graphic cards For information about bisection process see: https://goo.gl/tpsmEJ#bisection

2 years, 8 months

[PATCH] dmabuf: ensure unique directory name for dmabuf stats

by Charan Teja Kalla

2 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig