kernel/linux.git/tools/lib/api/fs/fs.c, branch v6.12.80

tools api fs: Avoid reading whole file for a 1 byte bool

2023-11-30T22:25:19+00:00

sysfs__read_bool() used the first byte from a fully read file into a string. It then looked at the first byte's value. Avoid doing this and just read the first byte. Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Athira Jajeev Cc: Changbin Du Cc: Colin Ian King Cc: Dmitrii Dolgov <9erthalion6@gmail.com> Cc: German Gomez Cc: Guilherme Amadio Cc: Huacai Chen Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: K Prateek Nayak Cc: Kajol Jain Cc: Kan Liang Cc: Leo Yan Cc: Li Dong Cc: Liam Howlett Cc: Mark Rutland Cc: Masami Hiramatsu (Google) Cc: Miguel Ojeda Cc: Ming Wang Cc: Nick Terrell Cc: Paolo Bonzini Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sandipan Das Cc: Sean Christopherson Cc: Steinar H. Gunderson Cc: Vincent Whitchurch Cc: Wenyu Liu Cc: Yang Jihong Link: https://lore.kernel.org/r/20231127220902.1315692-6-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

tools api fs: Switch filename__read_str to use io.h

2023-11-30T22:25:19+00:00

filename__read_str() has its own string reading code that allocates memory before reading into it. The memory allocated is sized at BUFSIZ that is 8kb. Most strings are short and so most of this 8kb is wasted. Refactor io__getline(), as io__getdelim(), so that the newline character can be configurable and ignored in the case of filename__read_str(). Code like build_caches_for_cpu() in perf's header.c will read many strings and hold them in a data structure, in this case multiple strings per cache level per CPU. Using io.h's io__getline() avoids the wasted memory as strings are temporarily read into a buffer on the stack before being copied to a buffer that grows 128 bytes at a time and is never sized larger than the string. For a 16 hyperthread system the memory consumption of "perf record true" is reduced by 180kb, primarily through saving memory when reading the cache information. Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Athira Jajeev Cc: Changbin Du Cc: Colin Ian King Cc: Dmitrii Dolgov <9erthalion6@gmail.com> Cc: German Gomez Cc: Guilherme Amadio Cc: Huacai Chen Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: K Prateek Nayak Cc: Kajol Jain Cc: Kan Liang Cc: Leo Yan Cc: Li Dong Cc: Liam Howlett Cc: Mark Rutland Cc: Masami Hiramatsu (Google) Cc: Miguel Ojeda Cc: Ming Wang Cc: Nick Terrell Cc: Paolo Bonzini Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sandipan Das Cc: Sean Christopherson Cc: Steinar H. Gunderson Cc: Vincent Whitchurch Cc: Wenyu Liu Cc: Yang Jihong Link: https://lore.kernel.org/r/20231127220902.1315692-5-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

tools api fs: More thread safety for global filesystem variables

2023-06-14T02:40:32+00:00

Multiple threads, such as with "perf top", may race to initialize a file system path like hugetlbfs. The racy initialization of the path leads to at least memory leaks. To avoid this initialize each fs for reading the mount point path with pthread_once. Mounting the file system may also be racy, so introduce a mutex over the function. This does mean that the path is being accessed with and without a mutex, which is inherently racy but hopefully benign, especially as there are fewer callers to fs__mount. Remove the fs__entries by directly using global variables, this was done as no argument like the index can be passed to the init once routine. Issue found and tested with "perf top" and address sanitizer. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230609224004.180988-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

tools api fs: Avoid large static PATH_MAX arrays

2023-05-28T13:22:40+00:00

Change struct fs to have a pointer to a dynamically allocated array rather than an array. This reduces the size of fs__entries from 24,768 bytes to 240 bytes. Read paths into a stack allocated array and strdup. Fix off-by-1 fscanf %s in fs__read_mounts caught by address sanitizer. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20230526183401.2326121-7-irogers@google.com Cc: K Prateek Nayak Cc: Ravi Bangoria Cc: Mark Rutland Cc: Ross Zwisler Cc: Steven Rostedt (Google) Cc: Sean Christopherson Cc: Yang Jihong Cc: Peter Zijlstra Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu (Google) Cc: Namhyung Kim Cc: Leo Yan Cc: Andi Kleen Cc: Alexander Shishkin Cc: Kan Liang Cc: Tiezhu Yang Cc: Ingo Molnar Cc: Paolo Bonzini Cc: linux-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

tools api fs: Make xxx__mountpoint() more scalable

2020-04-16T15:19:12+00:00

The xxx_mountpoint() interface provided by fs.c finds mount points for common pseudo filesystems. The first time xxx_mountpoint() is invoked, it scans the mount table (/proc/mounts) looking for a match. If found, it is cached. The price to scan /proc/mounts is paid once if the mount is found. When the mount point is not found, subsequent calls to xxx_mountpoint() scan /proc/mounts over and over again. There is no caching. This causes a scaling issue in perf record with hugeltbfs__mountpoint(). The function is called for each process found in synthesize__mmap_events(). If the machine has thousands of processes and if the /proc/mounts has many entries this could cause major overhead in perf record. We have observed multi-second slowdowns on some configurations. As an example on a laptop: Before: $ sudo umount /dev/hugepages $ strace -e trace=openat -o /tmp/tt perf record -a ls $ fgrep mounts /tmp/tt 285 After: $ sudo umount /dev/hugepages $ strace -e trace=openat -o /tmp/tt perf record -a ls $ fgrep mounts /tmp/tt 1 One could argue that the non-caching in case the moint point is not found is intentional. That way subsequent calls may discover a moint point if the sysadmin mounts the filesystem. But the same argument could be made against caching the mount point. It could be unmounted causing errors. It all depends on the intent of the interface. This patch assumes it is expected to scan /proc/mounts once. The patch documents the caching behavior in the fs.h header file. An alternative would be to just fix perf record. But it would solve the problem with hugetlbs__mountpoint() but there could be similar issues (possibly down the line) with other xxx_mountpoint() calls in perf or other tools. Signed-off-by: Stephane Eranian Reviewed-by: Ian Rogers Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andrey Zhizhikin Cc: Kan Liang Cc: Kefeng Wang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Petr Mladek Cc: Thomas Gleixner Link: http://lore.kernel.org/lkml/20200402154357.107873-3-irogers@google.com Signed-off-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo

tools lib api fs: Fix gcc9 stringop-truncation compilation error

2020-01-06T14:46:09+00:00

GCC9 introduced string hardening mechanisms, which exhibits the error during fs api compilation: error: '__builtin_strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] This comes when the length of copy passed to strncpy is is equal to destination size, which could potentially lead to buffer overflow. There is a need to mitigate this potential issue by limiting the size of destination by 1 and explicitly terminate the destination with NULL. Signed-off-by: Andrey Zhizhikin Reviewed-by: Petr Mladek Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Kefeng Wang Cc: Martin KaFai Lau Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Song Liu Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191211080109.18765-1-andrey.zhizhikin@leica-geosystems.com Signed-off-by: Arnaldo Carvalho de Melo

tools lib api: Renaming pr_warning to pr_warn

2019-10-18T13:02:57+00:00

For kernel logging macro, pr_warning is completely removed and replaced by pr_warn, using pr_warn in tools lib api for symmetry to kernel logging macro, then we could drop pr_warning in the whole linux code. Changing __pr_warning to __pr_warn to be consistent. Link: http://lkml.kernel.org/r/20191018031850.48498-30-wangkefeng.wang@huawei.com To: linux-kernel@vger.kernel.org Cc: Arnaldo Carvalho de Melo Signed-off-by: Kefeng Wang Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek

docs: Fix some broken references

2018-06-15T21:10:01+00:00

As we move stuff around, some doc references are broken. Fix some of them via this script: ./scripts/documentation-file-ref-check --fix Manually checked if the produced result is valid, removing a few false-positives. Acked-by: Takashi Iwai Acked-by: Masami Hiramatsu Acked-by: Stephen Boyd Acked-by: Charles Keepax Acked-by: Mathieu Poirier Reviewed-by: Coly Li Signed-off-by: Mauro Carvalho Chehab Acked-by: Jonathan Corbet

tools lib api fs: Add sysfs__read_xll function

2018-02-16T13:09:23+00:00

Adding sysfs__read_xll function to be able to read sysfs files with hex numbers in, which do not have 0x prefix. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20180206181813.10943-6-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

tools lib api fs: Add filename__read_xll function

2018-02-16T13:09:23+00:00

Adding filename__read_xll function to be able to read files with hex numbers in, which do not have 0x prefix. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20180206181813.10943-5-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo