linux.git, branch v4.19.156

Linux 4.19.156

2020-11-10T11:36:02+00:00

Tested-by: Jon Hunter 
Tested-by: Pavel Machek (CIP) 
Tested-by: Guenter Roeck 
Tested-by: Shuah Khan 
Tested-by: Linux Kernel Functional Testing 
Link: https://lore.kernel.org/r/20201109125019.906191744@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

arm64: dts: marvell: espressobin: Add ethernet switch aliases

2020-11-10T11:36:02+00:00

commit b64d814257b027e29a474bcd660f6372490138c7 upstream.

Espressobin boards have 3 ethernet ports and some of them got assigned more
then one MAC address. MAC addresses are stored in U-Boot environment.

Since commit a2c7023f7075c ("net: dsa: read mac address from DT for slave
device") kernel can use MAC addresses from DT for particular DSA port.

Currently Espressobin DTS file contains alias just for ethernet0.

This patch defines additional ethernet aliases in Espressobin DTS files, so
bootloader can fill correct MAC address for DSA switch ports if more MAC
addresses were specified.

DT alias ethernet1 is used for wan port, DT aliases ethernet2 and ethernet3
are used for lan ports for both Espressobin revisions (V5 and V7).

Fixes: 5253cb8c00a6f ("arm64: dts: marvell: espressobin: add ethernet alias")
Cc:  # a2c7023f7075c: dsa: read mac address
Signed-off-by: Pali Rohár 
Reviewed-by: Andrew Lunn 
Reviewed-by: Andre Heider 
Signed-off-by: Gregory CLEMENT 
[pali: Backported Espressobin rev V5 changes to 5.4 and 4.19 versions]
Signed-off-by: Greg Kroah-Hartman

net: dsa: read mac address from DT for slave device

2020-11-10T11:36:02+00:00

commit a2c7023f7075ca9b80f944d3f20f60e6574538e2 upstream.

Before creating a slave netdevice, get the mac address from DTS and
apply in case it is valid.

Signed-off-by: Xiaofei Shen 
Signed-off-by: Vinod Koul 
Signed-off-by: David S. Miller 
Cc: Pali Rohár 
Signed-off-by: Greg Kroah-Hartman

tools: perf: Fix build error in v4.19.y

2020-11-10T11:36:02+00:00

perf may fail to build in v4.19.y with the following error.

util/evsel.c: In function ‘perf_evsel__exit’:
util/util.h:25:28: error:
	passing argument 1 of ‘free’ discards ‘const’ qualifier from pointer target type

This is observed (at least) with gcc v6.5.0. The underlying problem is
the following statement.
	zfree(&evsel->pmu_name);
evsel->pmu_name is decared 'const *'. zfree in turn is defined as
	#define zfree(ptr) ({ free(*ptr); *ptr = NULL; })
and thus passes the const * to free(). The problem is not seen
in the upstream kernel since zfree() has been rewritten there.

The problem has been introduced into v4.19.y with the backport of upstream
commit d4953f7ef1a2 (perf parse-events: Fix 3 use after frees found with
clang ASAN).

One possible fix of this problem would be to not declare pmu_name
as const. This patch chooses to typecast the parameter of zfree()
to void *, following the guidance from the upstream kernel which
does the same since commit 7f7c536f23e6a ("tools lib: Adopt
zalloc()/zfree() from tools/perf")

Fixes: a0100a363098 ("perf parse-events: Fix 3 use after frees found with clang ASAN")
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

perf/core: Fix a memory leak in perf_event_parse_addr_filter()

2020-11-10T11:36:02+00:00

commit 7bdb157cdebbf95a1cd94ed2e01b338714075d00 upstream.

As shown through runtime testing, the "filename" allocation is not
always freed in perf_event_parse_addr_filter().

There are three possible ways that this could happen:

 - It could be allocated twice on subsequent iterations through the loop,
 - or leaked on the success path,
 - or on the failure path.

Clean up the code flow to make it obvious that 'filename' is always
freed in the reallocation path and in the two return paths as well.

We rely on the fact that kfree(NULL) is NOP and filename is initialized
with NULL.

This fixes the leak. No other side effects expected.

[ Dan Carpenter: cleaned up the code flow & added a changelog. ]
[ Ingo Molnar: updated the changelog some more. ]

Fixes: 375637bc5249 ("perf/core: Introduce address range filtering")
Signed-off-by: "kiyin(尹亮)" 
Signed-off-by: Dan Carpenter 
Signed-off-by: Ingo Molnar 
Cc: "Srivatsa S. Bhat" 
Cc: Anthony Liguori 
--
 kernel/events/core.c |   12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)
Signed-off-by: Greg Kroah-Hartman

PM: runtime: Resume the device earlier in __device_release_driver()

2020-11-10T11:36:01+00:00

commit 9226c504e364158a17a68ff1fe9d67d266922f50 upstream.

Since the device is resumed from runtime-suspend in
__device_release_driver() anyway, it is better to do that before
looking for busy managed device links from it to consumers, because
if there are any, device_links_unbind_consumers() will be called
and it will cause the consumer devices' drivers to unbind, so the
consumer devices will be runtime-resumed.  In turn, resuming each
consumer device will cause the supplier to be resumed and when the
runtime PM references from the given consumer to it are dropped, it
may be suspended.  Then, the runtime-resume of the next consumer
will cause the supplier to resume again and so on.

Update the code accordingly.

Signed-off-by: Rafael J. Wysocki 
Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Cc: All applicable  # All applicable
Tested-by: Xiang Chen 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

Revert "ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE"

2020-11-10T11:36:01+00:00

This reverts commit 00fdec98d9881bf5173af09aebd353ab3b9ac729.
(but only from 5.2 and prior kernels)

The original commit was a preventive fix based on code-review and was
auto-picked for stable back-port (for better or worse).
It was OK for v5.3+ kernels, but turned up needing an implicit change
68e5c6f073bcf70 "(ARC: entry: EV_Trap expects r10 (vs. r9) to have
 exception cause)" merged in v5.3 which itself was not backported.
So to summarize the stable backport of this patch for v5.2 and prior
kernels is busted and it won't boot.

The obvious solution is backport 68e5c6f073bcf70 but that is a pain as
it doesn't revert cleanly and each of affected kernels (so far v4.19,
v4.14, v4.9, v4.4) needs a slightly different massaged varaint.
So the easier fix is to simply revert the backport from 5.2 and prior.
The issue was not a big deal as it would cause strace to sporadically
not work correctly.

Waldemar Brodkorb first reported this when running ARC uClibc regressions
on latest stable kernels (with offending backport). Once he bisected it,
the analysis was trivial, so thx to him for this.

Reported-by: Waldemar Brodkorb 
Bisected-by: Waldemar Brodkorb 
Cc: stable  # 5.2 and prior
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: stack unwinding: avoid indefinite looping

2020-11-10T11:36:01+00:00

commit 328d2168ca524d501fc4b133d6be076142bd305c upstream.

Currently stack unwinder is a while(1) loop which relies on the dwarf
unwinder to signal termination, which in turn relies on dwarf info to do
so. This in theory could cause an infinite loop if the dwarf info was
somehow messed up or the register contents were etc.

This fix thus detects the excessive looping and breaks the loop.

| Mem: 26184K used, 1009136K free, 0K shrd, 0K buff, 14416K cached
| CPU:  0.0% usr 72.8% sys  0.0% nic 27.1% idle  0.0% io  0.0% irq  0.0% sirq
| Load average: 4.33 2.60 1.11 2/74 139
|   PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
|   133     2 root     SWN      0  0.0   3 22.9 [rcu_torture_rea]
|   132     2 root     SWN      0  0.0   0 22.0 [rcu_torture_rea]
|   131     2 root     SWN      0  0.0   3 21.5 [rcu_torture_rea]
|   126     2 root     RW       0  0.0   2  5.4 [rcu_torture_wri]
|   129     2 root     SWN      0  0.0   0  0.2 [rcu_torture_fak]
|   137     2 root     SW       0  0.0   0  0.2 [rcu_torture_cbf]
|   127     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
|   138   115 root     R     1464  0.1   2  0.1 top
|   130     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
|   128     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
|   115     1 root     S     1472  0.1   1  0.0 -/bin/sh
|   104     1 root     S     1464  0.1   0  0.0 inetd
|     1     0 root     S     1456  0.1   2  0.0 init
|    78     1 root     S     1456  0.1   0  0.0 syslogd -O /var/log/messages
|   134     2 root     SW       0  0.0   2  0.0 [rcu_torture_sta]
|    10     2 root     IW       0  0.0   1  0.0 [rcu_preempt]
|    88     2 root     IW       0  0.0   1  0.0 [kworker/1:1-eve]
|    66     2 root     IW       0  0.0   2  0.0 [kworker/2:2-eve]
|    39     2 root     IW       0  0.0   2  0.0 [kworker/2:1-eve]
| unwinder looping too long, aborting !

Cc: 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

usb: mtu3: fix panic in mtu3_gadget_stop()

2020-11-10T11:36:01+00:00

commit 20914919ad31849ee2b9cfe0428f4a20335c9e2a upstream.

This patch fixes a possible issue when mtu3_gadget_stop()
already assigned NULL to mtu->gadget_driver during mtu_gadget_disconnect().

[] notifier_call_chain+0xa4/0x128
[] __atomic_notifier_call_chain+0x84/0x138
[] notify_die+0xb0/0x120
[] die+0x1f8/0x5d0
[] __do_kernel_fault+0x19c/0x280
[] do_bad_area+0x44/0x140
[] do_translation_fault+0x4c/0x90
[] do_mem_abort+0xb8/0x258
[] el1_da+0x24/0x3c
[] mtu3_gadget_disconnect+0xac/0x128
[] mtu3_irq+0x34c/0xc18
[] __handle_irq_event_percpu+0x2ac/0xcd0
[] handle_irq_event_percpu+0x80/0x138
[] handle_irq_event+0xac/0x148
[] handle_fasteoi_irq+0x234/0x568
[] generic_handle_irq+0x48/0x68
[] __handle_domain_irq+0x264/0x1740
[] gic_handle_irq+0x14c/0x250
[] el1_irq+0xec/0x194
[] dma_pool_alloc+0x6e4/0xae0
[] cmdq_mbox_pool_alloc_impl+0xb0/0x238
[] cmdq_pkt_alloc_buf+0x2dc/0x7c0
[] cmdq_pkt_add_cmd_buffer+0x178/0x270
[] cmdq_pkt_perf_begin+0x108/0x148
[] cmdq_pkt_create+0x178/0x1f0
[] mtk_crtc_config_default_path+0x328/0x7a0
[] mtk_drm_idlemgr_kick+0xa6c/0x1460
[] mtk_drm_crtc_atomic_begin+0x1a4/0x1a68
[] drm_atomic_helper_commit_planes+0x154/0x878
[] mtk_atomic_complete.isra.16+0xe80/0x19c8
[] mtk_atomic_commit+0x258/0x898
[] drm_atomic_commit+0xcc/0x108
[] drm_mode_atomic_ioctl+0x1c20/0x2580
[] drm_ioctl_kernel+0x118/0x1b0
[] drm_ioctl+0x5c0/0x920
[] do_vfs_ioctl+0x188/0x1820
[] SyS_ioctl+0x8c/0xa0

Fixes: df2069acb005 ("usb: Add MediaTek USB3 DRD driver")
Signed-off-by: Macpaul Lin 
Acked-by: Chunfeng Yun 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1604642069-20961-1-git-send-email-macpaul.lin@mediatek.com
Signed-off-by: Greg Kroah-Hartman

USB: Add NO_LPM quirk for Kingston flash drive

2020-11-10T11:36:01+00:00

commit afaa2e745a246c5ab95103a65b1ed00101e1bc63 upstream.

In Bugzilla #208257, Julien Humbert reports that a 32-GB Kingston
flash drive spontaneously disconnects and reconnects, over and over.
Testing revealed that disabling Link Power Management for the drive
fixed the problem.

This patch adds a quirk entry for that drive to turn off LPM permanently.

CC: Hans de Goede 
CC: 
Reported-and-tested-by: Julien Humbert 
Signed-off-by: Alan Stern 
Link: https://lore.kernel.org/r/20201102145821.GA1478741@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman