<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/tools, branch v4.19.237</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.237</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.237'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-03-23T08:10:45+00:00</updated>
<entry>
<title>perf symbols: Fix symbol size calculation condition</title>
<updated>2022-03-23T08:10:45+00:00</updated>
<author>
<name>Michael Petlan</name>
<email>mpetlan@redhat.com</email>
</author>
<published>2022-03-17T13:55:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d12d3f6d9c4219ba3d0bcf6546802ef4e0fe289b'/>
<id>urn:sha1:d12d3f6d9c4219ba3d0bcf6546802ef4e0fe289b</id>
<content type='text'>
commit 3cf6a32f3f2a45944dd5be5c6ac4deb46bcd3bee upstream.

Before this patch, the symbol end address fixup to be called, needed two
conditions being met:

  if (prev-&gt;end == prev-&gt;start &amp;&amp; prev-&gt;end != curr-&gt;start)

Where
  "prev-&gt;end == prev-&gt;start" means that prev is zero-long
                             (and thus needs a fixup)
and
  "prev-&gt;end != curr-&gt;start" means that fixup hasn't been applied yet

However, this logic is incorrect in the following situation:

*curr  = {rb_node = {__rb_parent_color = 278218928,
  rb_right = 0x0, rb_left = 0x0},
  start = 0xc000000000062354,
  end = 0xc000000000062354, namelen = 40, type = 2 '\002',
  binding = 0 '\000', idle = 0 '\000', ignore = 0 '\000',
  inlined = 0 '\000', arch_sym = 0 '\000', annotate2 = false,
  name = 0x1159739e "kprobe_optinsn_page\t[__builtin__kprobes]"}

*prev = {rb_node = {__rb_parent_color = 278219041,
  rb_right = 0x109548b0, rb_left = 0x109547c0},
  start = 0xc000000000062354,
  end = 0xc000000000062354, namelen = 12, type = 2 '\002',
  binding = 1 '\001', idle = 0 '\000', ignore = 0 '\000',
  inlined = 0 '\000', arch_sym = 0 '\000', annotate2 = false,
  name = 0x1095486e "optinsn_slot"}

In this case, prev-&gt;start == prev-&gt;end == curr-&gt;start == curr-&gt;end,
thus the condition above thinks that "we need a fixup due to zero
length of prev symbol, but it has been probably done, since the
prev-&gt;end == curr-&gt;start", which is wrong.

After the patch, the execution path proceeds to arch__symbols__fixup_end
function which fixes up the size of prev symbol by adding page_size to
its end offset.

Fixes: 3b01a413c196c910 ("perf symbols: Improve kallsyms symbol end addr calculation")
Signed-off-by: Michael Petlan &lt;mpetlan@redhat.com&gt;
Cc: Athira Jajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kajol Jain &lt;kjain@linux.ibm.com&gt;
Cc: Madhavan Srinivasan &lt;maddy@linux.ibm.com&gt;
Link: http://lore.kernel.org/lkml/20220317135536.805-1-mpetlan@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kselftest/vm: fix tests build with old libc</title>
<updated>2022-03-23T08:10:41+00:00</updated>
<author>
<name>Chengming Zhou</name>
<email>zhouchengming@bytedance.com</email>
</author>
<published>2022-03-05T04:29:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1cab4278b375d91e20bf298e6e833769e5f78953'/>
<id>urn:sha1:1cab4278b375d91e20bf298e6e833769e5f78953</id>
<content type='text'>
[ Upstream commit b773827e361952b3f53ac6fa4c4e39ccd632102e ]

The error message when I build vm tests on debian10 (GLIBC 2.28):

    userfaultfd.c: In function `userfaultfd_pagemap_test':
    userfaultfd.c:1393:37: error: `MADV_PAGEOUT' undeclared (first use
    in this function); did you mean `MADV_RANDOM'?
      if (madvise(area_dst, test_pgsize, MADV_PAGEOUT))
                                         ^~~~~~~~~~~~
                                         MADV_RANDOM

This patch includes these newer definitions from UAPI linux/mman.h, is
useful to fix tests build on systems without these definitions in glibc
sys/mman.h.

Link: https://lkml.kernel.org/r/20220227055330.43087-2-zhouchengming@bytedance.com
Signed-off-by: Chengming Zhou &lt;zhouchengming@bytedance.com&gt;
Reviewed-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests/memfd: clean up mapping in mfd_fail_write</title>
<updated>2022-03-16T12:20:27+00:00</updated>
<author>
<name>Mike Kravetz</name>
<email>mike.kravetz@oracle.com</email>
</author>
<published>2022-02-26T03:11:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a86588cbda14af770162c70df8e2008161393ca7'/>
<id>urn:sha1:a86588cbda14af770162c70df8e2008161393ca7</id>
<content type='text'>
[ Upstream commit fda153c89af344d21df281009a9d046cf587ea0f ]

Running the memfd script ./run_hugetlbfs_test.sh will often end in error
as follows:

    memfd-hugetlb: CREATE
    memfd-hugetlb: BASIC
    memfd-hugetlb: SEAL-WRITE
    memfd-hugetlb: SEAL-FUTURE-WRITE
    memfd-hugetlb: SEAL-SHRINK
    fallocate(ALLOC) failed: No space left on device
    ./run_hugetlbfs_test.sh: line 60: 166855 Aborted                 (core dumped) ./memfd_test hugetlbfs
    opening: ./mnt/memfd
    fuse: DONE

If no hugetlb pages have been preallocated, run_hugetlbfs_test.sh will
allocate 'just enough' pages to run the test.  In the SEAL-FUTURE-WRITE
test the mfd_fail_write routine maps the file, but does not unmap.  As a
result, two hugetlb pages remain reserved for the mapping.  When the
fallocate call in the SEAL-SHRINK test attempts allocate all hugetlb
pages, it is short by the two reserved pages.

Fix by making sure to unmap in mfd_fail_write.

Link: https://lkml.kernel.org/r/20220219004340.56478-1-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz &lt;mike.kravetz@oracle.com&gt;
Cc: Joel Fernandes &lt;joel@joelfernandes.org&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE</title>
<updated>2022-03-11T09:15:11+00:00</updated>
<author>
<name>Peter Zijlstra (Intel)</name>
<email>peterz@infradead.org</email>
</author>
<published>2022-02-16T19:57:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=25440a8c77dd2fde6a8e9cfc0c616916febf408e'/>
<id>urn:sha1:25440a8c77dd2fde6a8e9cfc0c616916febf408e</id>
<content type='text'>
commit d45476d9832409371537013ebdd8dc1a7781f97a upstream.

The RETPOLINE_AMD name is unfortunate since it isn't necessarily
AMD only, in fact Hygon also uses it. Furthermore it will likely be
sufficient for some Intel processors. Therefore rename the thing to
RETPOLINE_LFENCE to better describe what it is.

Add the spectre_v2=retpoline,lfence option as an alias to
spectre_v2=retpoline,amd to preserve existing setups. However, the output
of /sys/devices/system/cpu/vulnerabilities/spectre_v2 will be changed.

  [ bp: Fix typos, massage. ]

Co-developed-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
[fllinden@amazon.com: backported to 4.19]
Signed-off-by: Frank van der Linden &lt;fllinden@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libsubcmd: Fix use-after-free for realloc(..., 0)</title>
<updated>2022-02-23T10:58:40+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2022-02-13T18:24:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1029268dc50d3eb54ab0e8d7075d33b190cad9d2'/>
<id>urn:sha1:1029268dc50d3eb54ab0e8d7075d33b190cad9d2</id>
<content type='text'>
commit 52a9dab6d892763b2a8334a568bd4e2c1a6fde66 upstream.

GCC 12 correctly reports a potential use-after-free condition in the
xrealloc helper. Fix the warning by avoiding an implicit "free(ptr)"
when size == 0:

In file included from help.c:12:
In function 'xrealloc',
    inlined from 'add_cmdname' at help.c:24:2: subcmd-util.h:56:23: error: pointer may be used after 'realloc' [-Werror=use-after-free]
   56 |                 ret = realloc(ptr, size);
      |                       ^~~~~~~~~~~~~~~~~~
subcmd-util.h:52:21: note: call to 'realloc' here
   52 |         void *ret = realloc(ptr, size);
      |                     ^~~~~~~~~~~~~~~~~~
subcmd-util.h:58:31: error: pointer may be used after 'realloc' [-Werror=use-after-free]
   58 |                         ret = realloc(ptr, 1);
      |                               ^~~~~~~~~~~~~~~
subcmd-util.h:52:21: note: call to 'realloc' here
   52 |         void *ret = realloc(ptr, size);
      |                     ^~~~~~~~~~~~~~~~~~

Fixes: 2f4ce5ec1d447beb ("perf tools: Finalize subcmd independence")
Reported-by: Valdis Klētnieks &lt;valdis.kletnieks@vt.edu&gt;
Signed-off-by: Kees Kook &lt;keescook@chromium.org&gt;
Tested-by: Valdis Klētnieks &lt;valdis.kletnieks@vt.edu&gt;
Tested-by: Justin M. Forbes &lt;jforbes@fedoraproject.org&gt;
Acked-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: linux-hardening@vger.kernel.org
Cc: Valdis Klētnieks &lt;valdis.kletnieks@vt.edu&gt;
Link: http://lore.kernel.org/lkml/20220213182443.4037039-1-keescook@chromium.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selftests/zram: Adapt the situation that /dev/zram0 is being used</title>
<updated>2022-02-23T10:58:38+00:00</updated>
<author>
<name>Yang Xu</name>
<email>xuyang2018.jy@fujitsu.com</email>
</author>
<published>2022-01-27T09:11:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=04bd141c4305a8738a39571927973e26d2d1a352'/>
<id>urn:sha1:04bd141c4305a8738a39571927973e26d2d1a352</id>
<content type='text'>
[ Upstream commit 01dabed20573804750af5c7bf8d1598a6bf7bf6e ]

If zram-generator package is installed and works, then we can not remove
zram module because zram swap is being used. This case needs a clean zram
environment, change this test by using hot_add/hot_remove interface. So
even zram device is being used, we still can add zram device and remove
them in cleanup.

The two interface was introduced since kernel commit 6566d1a32bf7("zram:
add dynamic device add/remove functionality") in v4.2-rc1. If kernel
supports these two interface, we use hot_add/hot_remove to slove this
problem, if not, just check whether zram is being used or built in, then
skip it on old kernel.

Signed-off-by: Yang Xu &lt;xuyang2018.jy@fujitsu.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests/zram01.sh: Fix compression ratio calculation</title>
<updated>2022-02-23T10:58:38+00:00</updated>
<author>
<name>Yang Xu</name>
<email>xuyang2018.jy@fujitsu.com</email>
</author>
<published>2022-01-27T09:11:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ec85569a92f17da30645e0e99f2a052196b85ca2'/>
<id>urn:sha1:ec85569a92f17da30645e0e99f2a052196b85ca2</id>
<content type='text'>
[ Upstream commit d18da7ec3719559d6e74937266d0416e6c7e0b31 ]

zram01 uses `free -m` to measure zram memory usage. The results are no
sense because they are polluted by all running processes on the system.

We Should only calculate the free memory delta for the current process.
So use the third field of /sys/block/zram&lt;id&gt;/mm_stat to measure memory
usage instead. The file is available since kernel 4.1.

orig_data_size(first): uncompressed size of data stored in this disk.
compr_data_size(second): compressed size of data stored in this disk
mem_used_total(third): the amount of memory allocated for this disk

Also remove useless zram cleanup call in zram_fill_fs and so we don't
need to cleanup zram twice if fails.

Signed-off-by: Yang Xu &lt;xuyang2018.jy@fujitsu.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests/zram: Skip max_comp_streams interface on newer kernel</title>
<updated>2022-02-23T10:58:38+00:00</updated>
<author>
<name>Yang Xu</name>
<email>xuyang2018.jy@fujitsu.com</email>
</author>
<published>2022-01-27T09:11:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2eed1b06f0abf00916ceb6ce61e4605928cec762'/>
<id>urn:sha1:2eed1b06f0abf00916ceb6ce61e4605928cec762</id>
<content type='text'>
[ Upstream commit fc4eb486a59d70bd35cf1209f0e68c2d8b979193 ]

Since commit 43209ea2d17a ("zram: remove max_comp_streams internals"), zram
has switched to per-cpu streams. Even kernel still keep this interface for
some reasons, but writing to max_comp_stream doesn't take any effect. So
skip it on newer kernel ie 4.7.

The code that comparing kernel version is from xfstests testsuite ext4/053.

Signed-off-by: Yang Xu &lt;xuyang2018.jy@fujitsu.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf probe: Fix ppc64 'perf probe add events failed' case</title>
<updated>2022-02-16T11:51:45+00:00</updated>
<author>
<name>Zechuan Chen</name>
<email>chenzechuan1@huawei.com</email>
</author>
<published>2021-12-28T11:13:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7ae6c390899ab8b2a5e2faea1957e15e6a19492a'/>
<id>urn:sha1:7ae6c390899ab8b2a5e2faea1957e15e6a19492a</id>
<content type='text'>
commit 4624f199327a704dd1069aca1c3cadb8f2a28c6f upstream.

Because of commit bf794bf52a80c627 ("powerpc/kprobes: Fix kallsyms
lookup across powerpc ABIv1 and ABIv2"), in ppc64 ABIv1, our perf
command eliminates the need to use the prefix "." at the symbol name.

But when the command "perf probe -a schedule" is executed on ppc64
ABIv1, it obtains two symbol address information through /proc/kallsyms,
for example:

  cat /proc/kallsyms | grep -w schedule
  c000000000657020 T .schedule
  c000000000d4fdb8 D schedule

The symbol "D schedule" is not a function symbol, and perf will print:
"p:probe/schedule _text+13958584"Failed to write event: Invalid argument

Therefore, when searching symbols from map and adding probe point for
them, a symbol type check is added. If the type of symbol is not a
function, skip it.

Fixes: bf794bf52a80c627 ("powerpc/kprobes: Fix kallsyms lookup across powerpc ABIv1 and ABIv2")
Signed-off-by: Zechuan Chen &lt;chenzechuan1@huawei.com&gt;
Acked-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jianlin Lv &lt;Jianlin.Lv@arm.com&gt;
Cc: Jin Yao &lt;yao.jin@linux.intel.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Naveen N. Rao &lt;naveen.n.rao@linux.vnet.ibm.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Ravi Bangoria &lt;ravi.bangoria@linux.ibm.com&gt;
Cc: Yang Jihong &lt;yangjihong1@huawei.com&gt;
Link: https://lore.kernel.org/r/20211228111338.218602-1-chenzechuan1@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selftests: futex: Use variable MAKE instead of make</title>
<updated>2022-02-08T17:23:18+00:00</updated>
<author>
<name>Muhammad Usama Anjum</name>
<email>usama.anjum@collabora.com</email>
</author>
<published>2022-01-27T17:44:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=34fcb509dd6d938c08e3edce8cff60e3942bb5d9'/>
<id>urn:sha1:34fcb509dd6d938c08e3edce8cff60e3942bb5d9</id>
<content type='text'>
commit b9199181a9ef8252e47e207be8c23e1f50662620 upstream.

Recursive make commands should always use the variable MAKE, not the
explicit command name ‘make’. This has benefits and removes the
following warning when multiple jobs are used for the build:

make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.

Fixes: a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT")
Signed-off-by: Muhammad Usama Anjum &lt;usama.anjum@collabora.com&gt;
Reviewed-by: André Almeida &lt;andrealmeid@collabora.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
