<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v5.4.148</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.148</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.148'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2021-09-22T10:26:46Z</updated>
<entry>
<title>Linux 5.4.148</title>
<updated>2021-09-22T10:26:46Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2021-09-22T10:26:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=07e5f23d3fa6ca98457d1a2177a735fcc65923c2'/>
<id>urn:sha1:07e5f23d3fa6ca98457d1a2177a735fcc65923c2</id>
<content type='text'>
Link: https://lore.kernel.org/r/20210920163931.123590023@linuxfoundation.org
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Hulk Robot &lt;hulkrobot@huawei.com&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>s390/bpf: Fix 64-bit subtraction of the -0x80000000 constant</title>
<updated>2021-09-22T10:26:46Z</updated>
<author>
<name>Ilya Leoshkevich</name>
<email>iii@linux.ibm.com</email>
</author>
<published>2021-09-07T11:41:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=54ac8339ae99e54139637f8cd409de047a101d7a'/>
<id>urn:sha1:54ac8339ae99e54139637f8cd409de047a101d7a</id>
<content type='text'>
commit 6e61dc9da0b7a0d91d57c2e20b5ea4fd2d4e7e53 upstream.

The JIT uses agfi for subtracting constants, but -(-0x80000000) cannot
be represented as a 32-bit signed binary integer. Fix by using algfi in
this particular case.

Reported-by: Johan Almbladh &lt;johan.almbladh@anyfinetworks.com&gt;
Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend")
Reviewed-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>s390/bpf: Fix optimizing out zero-extensions</title>
<updated>2021-09-22T10:26:46Z</updated>
<author>
<name>Ilya Leoshkevich</name>
<email>iii@linux.ibm.com</email>
</author>
<published>2021-09-06T13:04:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a5fc48000b0ed5c389d426c341b43f580faa7904'/>
<id>urn:sha1:a5fc48000b0ed5c389d426c341b43f580faa7904</id>
<content type='text'>
commit db7bee653859ef7179be933e7d1384644f795f26 upstream.

Currently the JIT completely removes things like `reg32 += 0`,
however, the BPF_ALU semantics requires the target register to be
zero-extended in such cases.

Fix by optimizing out only the arithmetic operation, but not the
subsequent zero-extension.

Reported-by: Johan Almbladh &lt;johan.almbladh@anyfinetworks.com&gt;
Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend")
Reviewed-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: renesas: sh_eth: Fix freeing wrong tx descriptor</title>
<updated>2021-09-22T10:26:46Z</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2021-09-07T11:29:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f7f1bac8983f65dd974079c3cfd5644a87fbf177'/>
<id>urn:sha1:f7f1bac8983f65dd974079c3cfd5644a87fbf177</id>
<content type='text'>
[ Upstream commit 0341d5e3d1ee2a36dd5a49b5bef2ce4ad1cfa6b4 ]

The cur_tx counter must be incremented after TACT bit of
txdesc-&gt;status was set. However, a CPU is possible to reorder
instructions and/or memory accesses between cur_tx and
txdesc-&gt;status. And then, if TX interrupt happened at such a
timing, the sh_eth_tx_free() may free the descriptor wrongly.
So, add wmb() before cur_tx++.
Otherwise NETDEV WATCHDOG timeout is possible to happen.

Fixes: 86a74ff21a7a ("net: sh_eth: add support for Renesas SuperH Ethernet")
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ip_gre: validate csum_start only on pull</title>
<updated>2021-09-22T10:26:45Z</updated>
<author>
<name>Willem de Bruijn</name>
<email>willemb@google.com</email>
</author>
<published>2021-09-05T15:21:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3d32ce5472bb2ca720bef84089b85f76a705fd1a'/>
<id>urn:sha1:3d32ce5472bb2ca720bef84089b85f76a705fd1a</id>
<content type='text'>
[ Upstream commit 8a0ed250f911da31a2aef52101bc707846a800ff ]

The GRE tunnel device can pull existing outer headers in ipge_xmit.
This is a rare path, apparently unique to this device. The below
commit ensured that pulling does not move skb-&gt;data beyond csum_start.

But it has a false positive if ip_summed is not CHECKSUM_PARTIAL and
thus csum_start is irrelevant.

Refine to exclude this. At the same time simplify and strengthen the
test.

Simplify, by moving the check next to the offending pull, making it
more self documenting and removing an unnecessary branch from other
code paths.

Strengthen, by also ensuring that the transport header is correct and
therefore the inner headers will be after skb_reset_inner_headers.
The transport header is set to csum_start in skb_partial_csum_set.

Link: https://lore.kernel.org/netdev/YS+h%2FtqCJJiQei+W@shredder/
Fixes: 1d011c4803c7 ("ip_gre: add validation for csum_start")
Reported-by: Ido Schimmel &lt;idosch@idosch.org&gt;
Suggested-by: Alexander Duyck &lt;alexander.duyck@gmail.com&gt;
Signed-off-by: Willem de Bruijn &lt;willemb@google.com&gt;
Reviewed-by: Alexander Duyck &lt;alexanderduyck@fb.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>qlcnic: Remove redundant unlock in qlcnic_pinit_from_rom</title>
<updated>2021-09-22T10:26:45Z</updated>
<author>
<name>Dinghao Liu</name>
<email>dinghao.liu@zju.edu.cn</email>
</author>
<published>2021-09-03T07:35:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f9b308f7302efbb3de087c087ad0d18eda071d92'/>
<id>urn:sha1:f9b308f7302efbb3de087c087ad0d18eda071d92</id>
<content type='text'>
[ Upstream commit 9ddbc2a00d7f63fa9748f4278643193dac985f2d ]

Previous commit 68233c583ab4 removes the qlcnic_rom_lock()
in qlcnic_pinit_from_rom(), but remains its corresponding
unlock function, which is odd. I'm not very sure whether the
lock is missing, or the unlock is redundant. This bug is
suggested by a static analysis tool, please advise.

Fixes: 68233c583ab4 ("qlcnic: updated reset sequence")
Signed-off-by: Dinghao Liu &lt;dinghao.liu@zju.edu.cn&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fq_codel: reject silly quantum parameters</title>
<updated>2021-09-22T10:26:45Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2021-09-03T22:03:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=93f54354ccc8cffd4daea2837f7b95b6da0966a9'/>
<id>urn:sha1:93f54354ccc8cffd4daea2837f7b95b6da0966a9</id>
<content type='text'>
[ Upstream commit c7c5e6ff533fe1f9afef7d2fa46678987a1335a7 ]

syzbot found that forcing a big quantum attribute would crash hosts fast,
essentially using this:

tc qd replace dev eth0 root fq_codel quantum 4294967295

This is because fq_codel_dequeue() would have to loop
~2^31 times in :

	if (flow-&gt;deficit &lt;= 0) {
		flow-&gt;deficit += q-&gt;quantum;
		list_move_tail(&amp;flow-&gt;flowchain, &amp;q-&gt;old_flows);
		goto begin;
	}

SFQ max quantum is 2^19 (half a megabyte)
Lets adopt a max quantum of one megabyte for FQ_CODEL.

Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>netfilter: socket: icmp6: fix use-after-scope</title>
<updated>2021-09-22T10:26:45Z</updated>
<author>
<name>Benjamin Hesmans</name>
<email>benjamin.hesmans@tessares.net</email>
</author>
<published>2021-09-03T13:23:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d448b240b17501b2f9a168e9d3689446413ca29a'/>
<id>urn:sha1:d448b240b17501b2f9a168e9d3689446413ca29a</id>
<content type='text'>
[ Upstream commit 730affed24bffcd1eebd5903171960f5ff9f1f22 ]

Bug reported by KASAN:

BUG: KASAN: use-after-scope in inet6_ehashfn (net/ipv6/inet6_hashtables.c:40)
Call Trace:
(...)
inet6_ehashfn (net/ipv6/inet6_hashtables.c:40)
(...)
nf_sk_lookup_slow_v6 (net/ipv6/netfilter/nf_socket_ipv6.c:91
net/ipv6/netfilter/nf_socket_ipv6.c:146)

It seems that this bug has already been fixed by Eric Dumazet in the
past in:
commit 78296c97ca1f ("netfilter: xt_socket: fix a stack corruption bug")

But a variant of the same issue has been introduced in
commit d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match")

`daddr` and `saddr` potentially hold a reference to ipv6_var that is no
longer in scope when the call to `nf_socket_get_sock_v6` is made.

Fixes: d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match")
Acked-by: Matthieu Baerts &lt;matthieu.baerts@tessares.net&gt;
Signed-off-by: Benjamin Hesmans &lt;benjamin.hesmans@tessares.net&gt;
Reviewed-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: b53: Fix calculating number of switch ports</title>
<updated>2021-09-22T10:26:45Z</updated>
<author>
<name>Rafał Miłecki</name>
<email>rafal@milecki.pl</email>
</author>
<published>2021-09-02T08:30:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b79204169de5941e645a011b3a45c1c40b0800bd'/>
<id>urn:sha1:b79204169de5941e645a011b3a45c1c40b0800bd</id>
<content type='text'>
[ Upstream commit cdb067d31c0fe4cce98b9d15f1f2ef525acaa094 ]

It isn't true that CPU port is always the last one. Switches BCM5301x
have 9 ports (port 6 being inactive) and they use port 5 as CPU by
default (depending on design some other may be CPU ports too).

A more reliable way of determining number of ports is to check for the
last set bit in the "enabled_ports" bitfield.

This fixes b53 internal state, it will allow providing accurate info to
the DSA and is required to fix BCM5301x support.

Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf unwind: Do not overwrite FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64}</title>
<updated>2021-09-22T10:26:45Z</updated>
<author>
<name>Li Huafei</name>
<email>lihuafei1@huawei.com</email>
</author>
<published>2021-08-23T13:43:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d5c0f016ae85337f3fe22a533eeec7e261bced02'/>
<id>urn:sha1:d5c0f016ae85337f3fe22a533eeec7e261bced02</id>
<content type='text'>
[ Upstream commit cdf32b44678c382a31dc183d9a767306915cda7b ]

When setting LIBUNWIND_DIR, we first set

 FEATURE_CHECK_LDFLAGS-libunwind-{aarch64,x86} = -L$(LIBUNWIND_DIR)/lib.

&lt;committer note&gt;
This happens a bit before, the overwritting, in:

  libunwind_arch_set_flags = $(eval $(libunwind_arch_set_flags_code))
  define libunwind_arch_set_flags_code
    FEATURE_CHECK_CFLAGS-libunwind-$(1)  = -I$(LIBUNWIND_DIR)/include
    FEATURE_CHECK_LDFLAGS-libunwind-$(1) = -L$(LIBUNWIND_DIR)/lib
  endef

  ifdef LIBUNWIND_DIR
    LIBUNWIND_CFLAGS  = -I$(LIBUNWIND_DIR)/include
    LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib
    LIBUNWIND_ARCHS = x86 x86_64 arm aarch64 debug-frame-arm debug-frame-aarch64
    $(foreach libunwind_arch,$(LIBUNWIND_ARCHS),$(call libunwind_arch_set_flags,$(libunwind_arch)))
  endif

Look at that 'foreach' on all the LIBUNWIND_ARCHS.
&lt;/&gt;

After commit 5c4d7c82c0dc ("perf unwind: Do not put libunwind-{x86,aarch64}
in FEATURE_TESTS_BASIC"), FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64} is
overwritten. As a result, the remote libunwind libraries cannot be searched
from $(LIBUNWIND_DIR)/lib directory during feature check tests. Fix it with
variable appending.

Before this patch:

  perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64
   BUILD:   Doing 'make -j16' parallel build
  &lt;SNIP&gt;
  ...
  ...                    libopencsd: [ OFF ]
  ...                 libunwind-x86: [ OFF ]
  ...              libunwind-x86_64: [ OFF ]
  ...                 libunwind-arm: [ OFF ]
  ...             libunwind-aarch64: [ OFF ]
  ...         libunwind-debug-frame: [ OFF ]
  ...     libunwind-debug-frame-arm: [ OFF ]
  ... libunwind-debug-frame-aarch64: [ OFF ]
  ...                           cxx: [ OFF ]
  &lt;SNIP&gt;

  perf$ cat ../build/feature/test-libunwind-aarch64.make.output
  /usr/bin/ld: cannot find -lunwind-aarch64
  /usr/bin/ld: cannot find -lunwind-aarch64
  collect2: error: ld returned 1 exit status

After this patch:

  perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64
   BUILD:   Doing 'make -j16' parallel build
  &lt;SNIP&gt;
  ...                    libopencsd: [ OFF ]
  ...                 libunwind-x86: [ OFF ]
  ...              libunwind-x86_64: [ OFF ]
  ...                 libunwind-arm: [ OFF ]
  ...             libunwind-aarch64: [ on  ]
  ...         libunwind-debug-frame: [ OFF ]
  ...     libunwind-debug-frame-arm: [ OFF ]
  ... libunwind-debug-frame-aarch64: [ OFF ]
  ...                           cxx: [ OFF ]
  &lt;SNIP&gt;

  perf$ cat ../build/feature/test-libunwind-aarch64.make.output

  perf$ ldd ./perf
        linux-vdso.so.1 (0x00007ffdf07da000)
        libpthread.so.0 =&gt; /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30953dc000)
        librt.so.1 =&gt; /lib/x86_64-linux-gnu/librt.so.1 (0x00007f30951d4000)
        libm.so.6 =&gt; /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3094e36000)
        libdl.so.2 =&gt; /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3094c32000)
        libelf.so.1 =&gt; /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f3094a18000)
        libdw.so.1 =&gt; /usr/lib/x86_64-linux-gnu/libdw.so.1 (0x00007f30947cc000)
        libunwind-x86_64.so.8 =&gt; /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8 (0x00007f30945ad000)
        libunwind.so.8 =&gt; /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007f3094392000)
        liblzma.so.5 =&gt; /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f309416c000)
        libunwind-aarch64.so.8 =&gt; not found
        libslang.so.2 =&gt; /lib/x86_64-linux-gnu/libslang.so.2 (0x00007f3093c8a000)
        libpython2.7.so.1.0 =&gt; /usr/local/lib/libpython2.7.so.1.0 (0x00007f309386b000)
        libz.so.1 =&gt; /lib/x86_64-linux-gnu/libz.so.1 (0x00007f309364e000)
        libnuma.so.1 =&gt; /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f3093443000)
        libc.so.6 =&gt; /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3093052000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3096097000)
        libbz2.so.1.0 =&gt; /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3092e42000)
        libutil.so.1 =&gt; /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3092c3f000)

Fixes: 5c4d7c82c0dceccf ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC")
Signed-off-by: Li Huafei &lt;lihuafei1@huawei.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: He Kuang &lt;hekuang@huawei.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Zhang Jinhao &lt;zhangjinhao2@huawei.com&gt;
Link: http://lore.kernel.org/lkml/20210823134340.60955-1-lihuafei1@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
