Bo Wu [Wed, 20 Nov 2019 13:26:17 +0000 (13:26 +0000)]
scsi: iscsi: Avoid potential deadlock in iscsi_if_rx func
commit
bba340c79bfe3644829db5c852fdfa9e33837d6d upstream.
In iscsi_if_rx func, after receiving one request through
iscsi_if_recv_msg func, iscsi_if_send_reply will be called to try to
reply to the request in a do-while loop. If the iscsi_if_send_reply
function keeps returning -EAGAIN, a deadlock will occur.
For example, a client only send msg without calling recvmsg func, then
it will result in the watchdog soft lockup. The details are given as
follows:
sock_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ISCSI);
retval = bind(sock_fd, (struct sock addr*) & src_addr, sizeof(src_addr);
while (1) {
state_msg = sendmsg(sock_fd, &msg, 0);
//Note: recvmsg(sock_fd, &msg, 0) is not processed here.
}
close(sock_fd);
watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [netlink_test:253305] Sample time:
4000897528 ns(HZ: 250) Sample stat:
curr: user:
675503481560, nice:
321724050, sys:
448689506750, idle:
4654054240530, iowait:
40885550700, irq:
14161174020, softirq:
8104324140, st: 0
deta: user: 0, nice: 0, sys:
3998210100, idle: 0, iowait: 0, irq: 1547170, softirq: 242870, st: 0 Sample softirq:
TIMER: 992
SCHED: 8
Sample irqstat:
irq 2: delta 1003, curr: 3103802, arch_timer
CPU: 7 PID: 253305 Comm: netlink_test Kdump: loaded Tainted: G OE
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate:
40400005 (nZcv daif +PAN -UAO)
pc : __alloc_skb+0x104/0x1b0
lr : __alloc_skb+0x9c/0x1b0
sp :
ffff000033603a30
x29:
ffff000033603a30 x28:
00000000000002dd
x27:
ffff800b34ced810 x26:
ffff800ba7569f00
x25:
00000000ffffffff x24:
0000000000000000
x23:
ffff800f7c43f600 x22:
0000000000480020
x21:
ffff0000091d9000 x20:
ffff800b34eff200
x19:
ffff800ba7569f00 x18:
0000000000000000
x17:
0000000000000000 x16:
0000000000000000
x15:
0000000000000000 x14:
0001000101000100
x13:
0000000101010000 x12:
0101000001010100
x11:
0001010101010001 x10:
00000000000002dd
x9 :
ffff000033603d58 x8 :
ffff800b34eff400
x7 :
ffff800ba7569200 x6 :
ffff800b34eff400
x5 :
0000000000000000 x4 :
00000000ffffffff
x3 :
0000000000000000 x2 :
0000000000000001
x1 :
ffff800b34eff2c0 x0 :
0000000000000300 Call trace:
__alloc_skb+0x104/0x1b0
iscsi_if_rx+0x144/0x12bc [scsi_transport_iscsi]
netlink_unicast+0x1e0/0x258
netlink_sendmsg+0x310/0x378
sock_sendmsg+0x4c/0x70
sock_write_iter+0x90/0xf0
__vfs_write+0x11c/0x190
vfs_write+0xac/0x1c0
ksys_write+0x6c/0xd8
__arm64_sys_write+0x24/0x30
el0_svc_common+0x78/0x130
el0_svc_handler+0x38/0x78
el0_svc+0x8/0xc
Link: https://lore.kernel.org/r/EDBAAA0BBBA2AC4E9C8B6B81DEEE1D6915E3D4D2@dggeml505-mbx.china.huawei.com
Signed-off-by: Bo Wu <wubo40@huawei.com>
Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 6 Sep 2017 06:26:00 +0000 (14:26 +0800)]
bcache: silence static checker warning
commit
da22f0eea555baf9b0a84b52afe56db2052cfe8d upstream.
In olden times, closure_return() used to have a hidden return built in.
We removed the hidden return but forgot to add a new return here. If
"c" were NULL we would oops on the next line, but fortunately "c" is
never NULL. Let's just remove the if statement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wen Huang [Thu, 28 Nov 2019 10:51:04 +0000 (18:51 +0800)]
libertas: Fix two buffer overflows at parsing bss descriptor
commit
e5e884b42639c74b5b57dc277909915c0aefc8bb upstream.
add_ie_rates() copys rates without checking the length
in bss descriptor from remote AP.when victim connects to
remote attacker, this may trigger buffer overflow.
lbs_ibss_join_existing() copys rates without checking the length
in bss descriptor from remote IBSS node.when victim connects to
remote attacker, this may trigger buffer overflow.
Fix them by putting the length check before performing copy.
This fix addresses CVE-2019-14896 and CVE-2019-14897.
This also fix build warning of mixed declarations and code.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Wen Huang <huangwenabc@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Thu, 20 Jun 2019 22:12:35 +0000 (16:12 -0600)]
coresight: tmc-etf: Do not call smp_processor_id from preemptible
commit
024c1fd9dbcc1d8a847f1311f999d35783921b7f upstream.
During a perf session we try to allocate buffers on the "node" associated
with the CPU the event is bound to. If it is not bound to a CPU, we
use the current CPU node, using smp_processor_id(). However this is unsafe
in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [
00000000] code: perf/2544
caller is tmc_alloc_etf_buffer+0x5c/0x60
CPU: 2 PID: 2544 Comm: perf Not tainted 5.1.0-rc6-147786-g116841e #344
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019
Call trace:
dump_backtrace+0x0/0x150
show_stack+0x14/0x20
dump_stack+0x9c/0xc4
debug_smp_processor_id+0x10c/0x110
tmc_alloc_etf_buffer+0x5c/0x60
etm_setup_aux+0x1c4/0x230
rb_alloc_aux+0x1b8/0x2b8
perf_mmap+0x35c/0x478
mmap_region+0x34c/0x4f0
do_mmap+0x2d8/0x418
vm_mmap_pgoff+0xd0/0xf8
ksys_mmap_pgoff+0x88/0xf8
__arm64_sys_mmap+0x28/0x38
el0_svc_handler+0xd8/0x138
el0_svc+0x8/0xc
Use NUMA_NO_NODE hint instead of using the current node for events
not bound to CPUs.
Fixes:
2e499bbc1a929ac ("coresight: tmc: implementing TMC-ETF AUX space API")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: stable <stable@vger.kernel.org> # 4.7+
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20190620221237.3536-4-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Thu, 20 Jun 2019 22:12:36 +0000 (16:12 -0600)]
coresight: etb10: Do not call smp_processor_id from preemptible
commit
730766bae3280a25d40ea76a53dc6342e84e6513 upstream.
During a perf session we try to allocate buffers on the "node" associated
with the CPU the event is bound to. If it is not bound to a CPU, we
use the current CPU node, using smp_processor_id(). However this is unsafe
in a pre-emptible context and could generate the splats as below :
BUG: using smp_processor_id() in preemptible [
00000000] code: perf/2544
Use NUMA_NO_NODE hint instead of using the current node for events
not bound to CPUs.
Fixes:
2997aa4063d97fdb39 ("coresight: etb10: implementing AUX API")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: stable <stable@vger.kernel.org> # 4.6+
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20190620221237.3536-5-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Thu, 13 Dec 2018 13:47:38 +0000 (13:47 +0000)]
arm64: kpti: Whitelist Cortex-A CPUs that don't implement the CSV3 field
commit
2a355ec25729053bb9a1a89b6c1d1cdd6c3b3fb1 upstream.
While the CSV3 field of the ID_AA64_PFR0 CPU ID register can be checked
to see if a CPU is susceptible to Meltdown and therefore requires kpti
to be enabled, existing CPUs do not implement this field.
We therefore whitelist all unaffected Cortex-A CPUs that do not implement
the CSV3 field.
Signed-off-by: Will Deacon <will.deacon@arm.com>
[florian: adjust whilelist location and table to stable-4.9.y]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeremy Linton [Fri, 25 Jan 2019 18:07:00 +0000 (12:07 -0600)]
Documentation: Document arm64 kpti control
commit
de19055564c8f8f9d366f8db3395836da0b2176c upstream.
For a while Arm64 has been capable of force enabling
or disabling the kpti mitigations. Lets make sure the
documentation reflects that.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
[florian: patch the correct file]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 26 Jan 2020 14:29:34 +0000 (09:29 -0500)]
do_last(): fetch directory ->i_mode and ->i_uid before it's too late
commit
d0cb50185ae942b03c4327be322055d622dc79f6 upstream.
may_create_in_sticky() call is done when we already have dropped the
reference to dir.
Fixes:
30aba6656f61e (namei: allow restricted O_CREAT of FIFOs and regular files)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Changbin Du [Sun, 12 Jan 2020 03:42:31 +0000 (11:42 +0800)]
tracing: xen: Ordered comparison of function pointers
commit
d0695e2351102affd8efae83989056bc4b275917 upstream.
Just as commit
0566e40ce7 ("tracing: initcall: Ordered comparison of
function pointers"), this patch fixes another remaining one in xen.h
found by clang-9.
In file included from arch/x86/xen/trace.c:21:
In file included from ./include/trace/events/xen.h:475:
In file included from ./include/trace/define_trace.h:102:
In file included from ./include/trace/trace_events.h:473:
./include/trace/events/xen.h:69:7: warning: ordered comparison of function \
pointers ('xen_mc_callback_fn_t' (aka 'void (*)(void *)') and 'xen_mc_callback_fn_t') [-Wordered-compare-function-pointers]
__field(xen_mc_callback_fn_t, fn)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/trace/trace_events.h:421:29: note: expanded from macro '__field'
^
./include/trace/trace_events.h:407:6: note: expanded from macro '__field_ext'
is_signed_type(type), filter_type); \
^
./include/linux/trace_events.h:554:44: note: expanded from macro 'is_signed_type'
^
Fixes:
c796f213a6934 ("xen/trace: add multicall tracing")
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Thu, 16 Jan 2020 04:47:37 +0000 (20:47 -0800)]
scsi: RDMA/isert: Fix a recently introduced regression related to logout
commit
04060db41178c7c244f2c7dcd913e7fd331de915 upstream.
iscsit_close_connection() calls isert_wait_conn(). Due to commit
e9d3009cb936 both functions call target_wait_for_sess_cmds() although that
last function should be called only once. Fix this by removing the
target_wait_for_sess_cmds() call from isert_wait_conn() and by only calling
isert_wait_conn() after target_wait_for_sess_cmds().
Fixes:
e9d3009cb936 ("scsi: target: iscsi: Wait for all commands to finish before freeing a session").
Link: https://lore.kernel.org/r/20200116044737.19507-1-bvanassche@acm.org
Reported-by: Rahul Kundu <rahul.kundu@chelsio.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gilles Buloz [Wed, 27 Nov 2019 17:09:34 +0000 (18:09 +0100)]
hwmon: (nct7802) Fix voltage limits to wrong registers
commit
7713e62c8623c54dac88d1fa724aa487a38c3efb upstream.
in0 thresholds are written to the in2 thresholds registers
in2 thresholds to in3 thresholds
in3 thresholds to in4 thresholds
in4 thresholds to in0 thresholds
Signed-off-by: Gilles Buloz <gilles.buloz@kontron.com>
Link: https://lore.kernel.org/r/5de0f509.rc0oEvPOMjbfPW1w%gilles.buloz@kontron.com
Fixes:
3434f3783580 ("hwmon: Driver for Nuvoton NCT7802Y")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chuhong Yuan [Fri, 10 Jan 2020 18:30:04 +0000 (10:30 -0800)]
Input: sun4i-ts - add a check for devm_thermal_zone_of_sensor_register
commit
97e24b095348a15ec08c476423c3b3b939186ad7 upstream.
The driver misses a check for devm_thermal_zone_of_sensor_register().
Add a check to fix it.
Fixes:
e28d0c9cd381 ("input: convert sun4i-ts to use devm_thermal_zone_of_sensor_register")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 19:55:47 +0000 (11:55 -0800)]
Input: pegasus_notetaker - fix endpoint sanity check
commit
bcfcb7f9b480dd0be8f0df2df17340ca92a03b98 upstream.
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could be used by a
malicious device (or USB descriptor fuzzer) to trigger a NULL-pointer
dereference.
Fixes:
1afca2b66aac ("Input: add Pegasus Notetaker tablet driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Martin Kepplinger <martink@posteo.de>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-2-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 19:59:32 +0000 (11:59 -0800)]
Input: aiptek - fix endpoint sanity check
commit
3111491fca4f01764e0c158c5e0f7ced808eef51 upstream.
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could lead to the
driver binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
8e20cf2bce12 ("Input: aiptek - fix crash on detecting device without endpoints")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-3-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 20:00:18 +0000 (12:00 -0800)]
Input: gtco - fix endpoint sanity check
commit
a8eeb74df5a6bdb214b2b581b14782c5f5a0cf83 upstream.
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could lead to the
driver binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
162f98dea487 ("Input: gtco - fix crash on detecting device without endpoints")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-5-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Jan 2020 20:01:27 +0000 (12:01 -0800)]
Input: sur40 - fix interface sanity checks
commit
6b32391ed675827f8425a414abbc6fbd54ea54fe upstream.
Make sure to use the current alternate setting when verifying the
interface descriptors to avoid binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes:
bdb5c57f209c ("Input: add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Vladis Dronov <vdronov@redhat.com>
Link: https://lore.kernel.org/r/20191210113737.4016-8-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Mirosław [Wed, 15 Jan 2020 09:54:35 +0000 (10:54 +0100)]
mmc: sdhci: fix minimum clock rate for v3 controller
commit
2a187d03352086e300daa2044051db00044cd171 upstream.
For SDHCIv3+ with programmable clock mode, minimal clock frequency is
still base clock / max(divider). Minimal programmable clock frequency is
always greater than minimal divided clock frequency. Without this patch,
SDHCI uses out-of-spec initial frequency when multiplier is big enough:
mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz
[for 480 MHz source clock divided by 1024]
The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode.
Fixes:
c3ed3877625f ("mmc: sdhci: add support for programmable clock mode")
Cc: <stable@vger.kernel.org> # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present
Cc: <stable@vger.kernel.org>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Mirosław [Tue, 7 Jan 2020 09:47:34 +0000 (10:47 +0100)]
mmc: tegra: fix SDR50 tuning override
commit
f571389c0b015e76f91c697c4c1700aba860d34f upstream.
Commit
7ad2ed1dfcbe inadvertently mixed up a quirk flag's name and
broke SDR50 tuning override. Use correct NVQUIRK_ name.
Fixes:
7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")
Cc: <stable@vger.kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/9aff1d859935e59edd81e4939e40d6c55e0b55f6.1578390388.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Sverdlin [Wed, 8 Jan 2020 14:57:47 +0000 (15:57 +0100)]
ARM: 8950/1: ftrace/recordmcount: filter relocation types
commit
927d780ee371d7e121cea4fc7812f6ef2cea461c upstream.
Scenario 1, ARMv7
=================
If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer
the following may be generated:
00000230 <prealloc_fixed_plts>:
230: b5f8 push {r3, r4, r5, r6, r7, lr}
232: b500 push {lr}
234: f7ff fffe bl 0 <__gnu_mcount_nc>
234: R_ARM_THM_CALL __gnu_mcount_nc
238: f240 0600 movw r6, #0
238: R_ARM_THM_MOVW_ABS_NC __gnu_mcount_nc
23c: f8d0 1180 ldr.w r1, [r0, #384] ; 0x180
FTRACE currently is not able to deal with it:
WARNING: CPU: 0 PID: 0 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1ad/0x230()
...
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.116-... #1
...
[<
c0314e3d>] (unwind_backtrace) from [<
c03115e9>] (show_stack+0x11/0x14)
[<
c03115e9>] (show_stack) from [<
c051a7f1>] (dump_stack+0x81/0xa8)
[<
c051a7f1>] (dump_stack) from [<
c0321c5d>] (warn_slowpath_common+0x69/0x90)
[<
c0321c5d>] (warn_slowpath_common) from [<
c0321cf3>] (warn_slowpath_null+0x17/0x1c)
[<
c0321cf3>] (warn_slowpath_null) from [<
c038ee9d>] (ftrace_bug+0x1ad/0x230)
[<
c038ee9d>] (ftrace_bug) from [<
c038f1f9>] (ftrace_process_locs+0x27d/0x444)
[<
c038f1f9>] (ftrace_process_locs) from [<
c08915bd>] (ftrace_init+0x91/0xe8)
[<
c08915bd>] (ftrace_init) from [<
c0885a67>] (start_kernel+0x34b/0x358)
[<
c0885a67>] (start_kernel) from [<
00308095>] (0x308095)
---[ end trace
cb88537fdc8fa200 ]---
ftrace failed to modify [<
c031266c>] prealloc_fixed_plts+0x8/0x60
actual: 44:f2:e1:36
ftrace record flags: 0
(0) expected tramp:
c03143e9
Scenario 2, ARMv4T
==================
ftrace: allocating 14435 entries in 43 pages
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2029 ftrace_bug+0x204/0x310
CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.5 #1
Hardware name: Cirrus Logic EDB9302 Evaluation Board
[<
c0010a24>] (unwind_backtrace) from [<
c000ecb0>] (show_stack+0x20/0x2c)
[<
c000ecb0>] (show_stack) from [<
c03c72e8>] (dump_stack+0x20/0x30)
[<
c03c72e8>] (dump_stack) from [<
c0021c18>] (__warn+0xdc/0x104)
[<
c0021c18>] (__warn) from [<
c0021d7c>] (warn_slowpath_null+0x4c/0x5c)
[<
c0021d7c>] (warn_slowpath_null) from [<
c0095360>] (ftrace_bug+0x204/0x310)
[<
c0095360>] (ftrace_bug) from [<
c04dabac>] (ftrace_init+0x3b4/0x4d4)
[<
c04dabac>] (ftrace_init) from [<
c04cef4c>] (start_kernel+0x20c/0x410)
[<
c04cef4c>] (start_kernel) from [<
00000000>] ( (null))
---[ end trace
0506a2f5dae6b341 ]---
ftrace failed to modify
[<
c000c350>] perf_trace_sys_exit+0x5c/0xe8
actual: 1e:ff:2f:e1
Initializing ftrace call sites
ftrace record flags: 0
(0)
expected tramp:
c000fb24
The analysis for this problem has been already performed previously,
refer to the link below.
Fix the above problems by allowing only selected reloc types in
__mcount_loc. The list itself comes from the legacy recordmcount.pl
script.
Link: https://lore.kernel.org/lkml/56961010.6000806@pengutronix.de/
Cc: stable@vger.kernel.org
Fixes:
ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 13 Jan 2020 18:38:57 +0000 (10:38 -0800)]
Input: keyspan-remote - fix control-message timeouts
commit
ba9a103f40fc4a3ec7558ec9b0b97d4f92034249 upstream.
The driver was issuing synchronous uninterruptible control requests
without using a timeout. This could lead to the driver hanging on probe
due to a malfunctioning (or malicious) device until the device is
physically disconnected. While sleeping in probe the driver prevents
other devices connected to the same hub from being added to (or removed
from) the bus.
The USB upper limit of five seconds per request should be more than
enough.
Fixes:
99f83c9c9ac9 ("[PATCH] USB: add driver for Keyspan Digital Remote")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org> # 2.6.13
Link: https://lore.kernel.org/r/20200113171715.30621-1-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Thu, 16 Jan 2020 18:44:17 +0000 (10:44 -0800)]
hwmon: (core) Do not use device managed functions for memory allocations
commit
3bf8bdcf3bada771eb12b57f2a30caee69e8ab8d upstream.
The hwmon core uses device managed functions, tied to the hwmon parent
device, for various internal memory allocations. This is problematic
since hwmon device lifetime does not necessarily match its parent's
device lifetime. If there is a mismatch, memory leaks will accumulate
until the parent device is released.
Fix the problem by managing all memory allocations internally. The only
exception is memory allocation for thermal device registration, which
can be tied to the hwmon device, along with thermal device registration
itself.
Fixes:
d560168b5d0f ("hwmon: (core) New hwmon registration API")
Cc: stable@vger.kernel.org # v4.14.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem
Cc: stable@vger.kernel.org # v4.14.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register()
Cc: stable@vger.kernel.org # v4.9.x: 3a412d5e4a1c: hwmon: (core) Simplify sysfs attribute name allocation
Cc: stable@vger.kernel.org # v4.9.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem
Cc: stable@vger.kernel.org # v4.9.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register()
Cc: stable@vger.kernel.org # v4.9+
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Osipenko [Wed, 24 Oct 2018 19:37:13 +0000 (22:37 +0300)]
hwmon: (core) Fix double-free in __hwmon_device_register()
commit
74e3512731bd5c9673176425a76a7cc5efa8ddb6 upstream.
Fix double-free that happens when thermal zone setup fails, see KASAN log
below.
==================================================================
BUG: KASAN: double-free or invalid-free in __hwmon_device_register+0x5dc/0xa7c
CPU: 0 PID: 132 Comm: kworker/0:2 Tainted: G B 4.19.0-rc8-next-
20181016-00042-gb52cd80401e9-dirty #41
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
Backtrace:
[<
c0110540>] (dump_backtrace) from [<
c0110944>] (show_stack+0x20/0x24)
[<
c0110924>] (show_stack) from [<
c105cb08>] (dump_stack+0x9c/0xb0)
[<
c105ca6c>] (dump_stack) from [<
c02fdaec>] (print_address_description+0x68/0x250)
[<
c02fda84>] (print_address_description) from [<
c02fd4ac>] (kasan_report_invalid_free+0x68/0x88)
[<
c02fd444>] (kasan_report_invalid_free) from [<
c02fc85c>] (__kasan_slab_free+0x1f4/0x200)
[<
c02fc668>] (__kasan_slab_free) from [<
c02fd0c0>] (kasan_slab_free+0x14/0x18)
[<
c02fd0ac>] (kasan_slab_free) from [<
c02f9c6c>] (kfree+0x90/0x294)
[<
c02f9bdc>] (kfree) from [<
c0b41bbc>] (__hwmon_device_register+0x5dc/0xa7c)
[<
c0b415e0>] (__hwmon_device_register) from [<
c0b421e8>] (hwmon_device_register_with_info+0xa0/0xa8)
[<
c0b42148>] (hwmon_device_register_with_info) from [<
c0b42324>] (devm_hwmon_device_register_with_info+0x74/0xb4)
[<
c0b422b0>] (devm_hwmon_device_register_with_info) from [<
c0b4481c>] (lm90_probe+0x414/0x578)
[<
c0b44408>] (lm90_probe) from [<
c0aeeff4>] (i2c_device_probe+0x35c/0x384)
[<
c0aeec98>] (i2c_device_probe) from [<
c08776cc>] (really_probe+0x290/0x3e4)
[<
c087743c>] (really_probe) from [<
c0877a2c>] (driver_probe_device+0x80/0x1c4)
[<
c08779ac>] (driver_probe_device) from [<
c0877da8>] (__device_attach_driver+0x104/0x11c)
[<
c0877ca4>] (__device_attach_driver) from [<
c0874dd8>] (bus_for_each_drv+0xa4/0xc8)
[<
c0874d34>] (bus_for_each_drv) from [<
c08773b0>] (__device_attach+0xf0/0x15c)
[<
c08772c0>] (__device_attach) from [<
c0877e24>] (device_initial_probe+0x1c/0x20)
[<
c0877e08>] (device_initial_probe) from [<
c08762f4>] (bus_probe_device+0xdc/0xec)
[<
c0876218>] (bus_probe_device) from [<
c0876a08>] (deferred_probe_work_func+0xa8/0xd4)
[<
c0876960>] (deferred_probe_work_func) from [<
c01527c4>] (process_one_work+0x3dc/0x96c)
[<
c01523e8>] (process_one_work) from [<
c01541e0>] (worker_thread+0x4ec/0x8bc)
[<
c0153cf4>] (worker_thread) from [<
c015b238>] (kthread+0x230/0x240)
[<
c015b008>] (kthread) from [<
c01010bc>] (ret_from_fork+0x14/0x38)
Exception stack(0xcf743fb0 to 0xcf743ff8)
3fa0:
00000000 00000000 00000000 00000000
3fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0:
00000000 00000000 00000000 00000000 00000013 00000000
Allocated by task 132:
kasan_kmalloc.part.1+0x58/0xf4
kasan_kmalloc+0x90/0xa4
kmem_cache_alloc_trace+0x90/0x2a0
__hwmon_device_register+0xbc/0xa7c
hwmon_device_register_with_info+0xa0/0xa8
devm_hwmon_device_register_with_info+0x74/0xb4
lm90_probe+0x414/0x578
i2c_device_probe+0x35c/0x384
really_probe+0x290/0x3e4
driver_probe_device+0x80/0x1c4
__device_attach_driver+0x104/0x11c
bus_for_each_drv+0xa4/0xc8
__device_attach+0xf0/0x15c
device_initial_probe+0x1c/0x20
bus_probe_device+0xdc/0xec
deferred_probe_work_func+0xa8/0xd4
process_one_work+0x3dc/0x96c
worker_thread+0x4ec/0x8bc
kthread+0x230/0x240
ret_from_fork+0x14/0x38
(null)
Freed by task 132:
__kasan_slab_free+0x12c/0x200
kasan_slab_free+0x14/0x18
kfree+0x90/0x294
hwmon_dev_release+0x1c/0x20
device_release+0x4c/0xe8
kobject_put+0xac/0x11c
device_unregister+0x2c/0x30
__hwmon_device_register+0xa58/0xa7c
hwmon_device_register_with_info+0xa0/0xa8
devm_hwmon_device_register_with_info+0x74/0xb4
lm90_probe+0x414/0x578
i2c_device_probe+0x35c/0x384
really_probe+0x290/0x3e4
driver_probe_device+0x80/0x1c4
__device_attach_driver+0x104/0x11c
bus_for_each_drv+0xa4/0xc8
__device_attach+0xf0/0x15c
device_initial_probe+0x1c/0x20
bus_probe_device+0xdc/0xec
deferred_probe_work_func+0xa8/0xd4
process_one_work+0x3dc/0x96c
worker_thread+0x4ec/0x8bc
kthread+0x230/0x240
ret_from_fork+0x14/0x38
(null)
Cc: <stable@vger.kernel.org> # v4.15+
Fixes:
47c332deb8e8 ("hwmon: Deal with errors from the thermal subsystem")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Tue, 5 Dec 2017 08:36:14 +0000 (09:36 +0100)]
hwmon: Deal with errors from the thermal subsystem
commit
47c332deb8e89f6c59b0bb2615945c6e7fad1a60 upstream.
If the thermal subsystem returne -EPROBE_DEFER or any other error
when hwmon calls devm_thermal_zone_of_sensor_register(), this is
silently ignored.
I ran into this with an incorrectly defined thermal zone, making
it non-existing and thus this call failed with -EPROBE_DEFER
assuming it would appear later. The sensor was still added
which is incorrect: sensors must strictly be added after the
thermal zones, so deferred probe must be respected.
Fixes:
d560168b5d0f ("hwmon: (core) New hwmon registration API")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Sun, 16 Oct 2016 17:52:04 +0000 (10:52 -0700)]
hwmon: (core) Simplify sysfs attribute name allocation
commit
3a412d5e4a1c831723d0aaf305f1cf9a78ad9c90 upstream.
Allocating the sysfs attribute name only if needed and only with the
required minimum length looks optimal, but does not take the additional
overhead for both devm_ data structures and the allocation header itself
into account. This also results in unnecessary memory fragmentation.
Move the sysfs name string into struct hwmon_device_attribute and give it
a sufficient length to reduce this overhead.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luuk Paulussen [Thu, 5 Dec 2019 23:16:59 +0000 (12:16 +1300)]
hwmon: (adt7475) Make volt2reg return same reg as reg2volt input
commit
cf3ca1877574a306c0207cbf7fdf25419d9229df upstream.
reg2volt returns the voltage that matches a given register value.
Converting this back the other way with volt2reg didn't return the same
register value because it used truncation instead of rounding.
This meant that values read from sysfs could not be written back to sysfs
to set back the same register value.
With this change, volt2reg will return the same value for every voltage
previously returned by reg2volt (for the set of possible input values)
Signed-off-by: Luuk Paulussen <luuk.paulussen@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20191205231659.1301-1-luuk.paulussen@alliedtelesis.co.nz
cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 22 Jan 2020 07:17:14 +0000 (23:17 -0800)]
gtp: make sure only SOCK_DGRAM UDP sockets are accepted
[ Upstream commit
940ba14986657a50c15f694efca1beba31fa568f ]
A malicious user could use RAW sockets and fool
GTP using them as standard SOCK_DGRAM UDP sockets.
BUG: KMSAN: uninit-value in udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline]
BUG: KMSAN: uninit-value in setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85
CPU: 0 PID: 11262 Comm: syz-executor613 Not tainted 5.5.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline]
setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85
gtp_encap_enable_socket+0x37f/0x5a0 drivers/net/gtp.c:827
gtp_encap_enable drivers/net/gtp.c:844 [inline]
gtp_newlink+0xfb/0x1e50 drivers/net/gtp.c:666
__rtnl_newlink net/core/rtnetlink.c:3305 [inline]
rtnl_newlink+0x2973/0x3920 net/core/rtnetlink.c:3363
rtnetlink_rcv_msg+0x1153/0x1570 net/core/rtnetlink.c:5424
netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:639 [inline]
sock_sendmsg net/socket.c:659 [inline]
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
___sys_sendmsg net/socket.c:2384 [inline]
__sys_sendmsg+0x451/0x5f0 net/socket.c:2417
__do_sys_sendmsg net/socket.c:2426 [inline]
__se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441359
Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 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 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007fff1cd0ac28 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
0000000000441359
RDX:
0000000000000000 RSI:
0000000020000100 RDI:
0000000000000003
RBP:
00000000006cb018 R08:
00000000004002c8 R09:
00000000004002c8
R10:
00000000004002c8 R11:
0000000000000246 R12:
00000000004020d0
R13:
0000000000402160 R14:
0000000000000000 R15:
0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags+0x3c/0x90 mm/kmsan/kmsan.c:144
kmsan_internal_alloc_meta_for_pages mm/kmsan/kmsan_shadow.c:307 [inline]
kmsan_alloc_page+0x12a/0x310 mm/kmsan/kmsan_shadow.c:336
__alloc_pages_nodemask+0x57f2/0x5f60 mm/page_alloc.c:4800
alloc_pages_current+0x67d/0x990 mm/mempolicy.c:2207
alloc_pages include/linux/gfp.h:534 [inline]
alloc_slab_page+0x111/0x12f0 mm/slub.c:1511
allocate_slab mm/slub.c:1656 [inline]
new_slab+0x2bc/0x1130 mm/slub.c:1722
new_slab_objects mm/slub.c:2473 [inline]
___slab_alloc+0x1533/0x1f30 mm/slub.c:2624
__slab_alloc mm/slub.c:2664 [inline]
slab_alloc_node mm/slub.c:2738 [inline]
slab_alloc mm/slub.c:2783 [inline]
kmem_cache_alloc+0xb23/0xd70 mm/slub.c:2788
sk_prot_alloc+0xf2/0x620 net/core/sock.c:1597
sk_alloc+0xf0/0xbe0 net/core/sock.c:1657
inet_create+0x7c7/0x1370 net/ipv4/af_inet.c:321
__sock_create+0x8eb/0xf00 net/socket.c:1420
sock_create net/socket.c:1471 [inline]
__sys_socket+0x1a1/0x600 net/socket.c:1513
__do_sys_socket net/socket.c:1522 [inline]
__se_sys_socket+0x8d/0xb0 net/socket.c:1520
__x64_sys_socket+0x4a/0x70 net/socket.c:1520
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Pablo Neira <pablo@netfilter.org>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hughes [Mon, 20 Jan 2020 11:12:40 +0000 (11:12 +0000)]
net: usb: lan78xx: Add .ndo_features_check
[ Upstream commit
ce896476c65d72b4b99fa09c2f33436b4198f034 ]
As reported by Eric Dumazet, there are still some outstanding
cases where the driver does not handle TSO correctly when skb's
are over a certain size. Most cases have been fixed, this patch
should ensure that forwarded SKB's that are greater than
MAX_SINGLE_PACKET_SIZE - TX_OVERHEAD are software segmented
and handled correctly.
Signed-off-by: James Hughes <james.hughes@raspberrypi.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wen Yang [Mon, 20 Jan 2020 10:04:56 +0000 (18:04 +0800)]
tcp_bbr: improve arithmetic division in bbr_update_bw()
[ Upstream commit
5b2f1f3070b6447b76174ea8bfb7390dc6253ebd ]
do_div() does a 64-by-32 division. Use div64_long() instead of it
if the divisor is long, to avoid truncation to 32-bit.
And as a nice side effect also cleans up the function a bit.
Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cong Wang [Wed, 22 Jan 2020 23:42:02 +0000 (15:42 -0800)]
net_sched: fix datalen for ematch
[ Upstream commit
61678d28d4a45ef376f5d02a839cc37509ae9281 ]
syzbot reported an out-of-bound access in em_nbyte. As initially
analyzed by Eric, this is because em_nbyte sets its own em->datalen
in em_nbyte_change() other than the one specified by user, but this
value gets overwritten later by its caller tcf_em_validate().
We should leave em->datalen untouched to respect their choices.
I audit all the in-tree ematch users, all of those implement
->change() set em->datalen, so we can just avoid setting it twice
in this case.
Reported-and-tested-by: syzbot+5af9a90dad568aa9f611@syzkaller.appspotmail.com
Reported-by: syzbot+2f07903a5b05e7f36410@syzkaller.appspotmail.com
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Dauchy [Tue, 21 Jan 2020 14:26:24 +0000 (15:26 +0100)]
net, ip_tunnel: fix namespaces move
[ Upstream commit
d0f418516022c32ecceaf4275423e5bd3f8743a9 ]
in the same manner as commit
690afc165bb3 ("net: ip6_gre: fix moving
ip6gre between namespaces"), fix namespace moving as it was broken since
commit
2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.").
Indeed, the ip6_gre commit removed the local flag for collect_md
condition, so there is no reason to keep it for ip_gre/ip_tunnel.
this patch will fix both ip_tunnel and ip_gre modules.
Fixes:
2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Dauchy [Tue, 21 Jan 2020 20:49:54 +0000 (21:49 +0100)]
net, ip6_tunnel: fix namespaces move
[ Upstream commit
5311a69aaca30fa849c3cc46fb25f75727fb72d0 ]
in the same manner as commit
d0f418516022 ("net, ip_tunnel: fix
namespaces move"), fix namespace moving as it was broken since commit
8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel"), but for
ipv6 this time; there is no reason to keep it for ip6_tunnel.
Fixes:
8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel")
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Fri, 24 Jan 2020 09:41:44 +0000 (20:41 +1100)]
net: cxgb3_main: Add CAP_NET_ADMIN check to CHELSIO_GET_MEM
[ Upstream commit
3546d8f1bbe992488ed91592cf6bf76e7114791a =
The cxgb3 driver for "Chelsio T3-based gigabit and 10Gb Ethernet
adapters" implements a custom ioctl as SIOCCHIOCTL/SIOCDEVPRIVATE in
cxgb_extension_ioctl().
One of the subcommands of the ioctl is CHELSIO_GET_MEM, which appears
to read memory directly out of the adapter and return it to userspace.
It's not entirely clear what the contents of the adapter memory
contains, but the assumption is that it shouldn't be accessible to all
users.
So add a CAP_NET_ADMIN check to the CHELSIO_GET_MEM case. Put it after
the is_offload() check, which matches two of the other subcommands in
the same function which also check for is_offload() and CAP_NET_ADMIN.
Found by Ilja by code inspection, not tested as I don't have the
required hardware.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wenwen Wang [Sat, 25 Jan 2020 14:33:29 +0000 (14:33 +0000)]
firestream: fix memory leaks
[ Upstream commit
fa865ba183d61c1ec8cbcab8573159c3b72b89a4 ]
In fs_open(), 'vcc' is allocated through kmalloc() and assigned to
'atm_vcc->dev_data.' In the following execution, if an error occurs, e.g.,
there is no more free channel, an error code EBUSY or ENOMEM will be
returned. However, 'vcc' is not deallocated, leading to memory leaks. Note
that, in normal cases where fs_open() returns 0, 'vcc' will be deallocated
in fs_close(). But, if fs_open() fails, there is no guarantee that
fs_close() will be invoked.
To fix this issue, deallocate 'vcc' before the error code is returned.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Palethorpe [Tue, 21 Jan 2020 13:42:58 +0000 (14:42 +0100)]
can, slip: Protect tty->disc_data in write_wakeup and close with RCU
[ Upstream commit
0ace17d56824165c7f4c68785d6b58971db954dd ]
write_wakeup can happen in parallel with close/hangup where tty->disc_data
is set to NULL and the netdevice is freed thus also freeing
disc_data. write_wakeup accesses disc_data so we must prevent close from
freeing the netdev while write_wakeup has a non-NULL view of
tty->disc_data.
We also need to make sure that accesses to disc_data are atomic. Which can
all be done with RCU.
This problem was found by Syzkaller on SLCAN, but the same issue is
reproducible with the SLIP line discipline using an LTP test based on the
Syzkaller reproducer.
A fix which didn't use RCU was posted by Hillf Danton.
Fixes:
661f7fda21b1 ("slip: Fix deadlock in write_wakeup")
Fixes:
a8e83b17536a ("slcan: Port write_wakeup deadlock fix from slip")
Reported-by: syzbot+017e491ae13c0068598a@syzkaller.appspotmail.com
Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Tyler Hall <tylerwhall@gmail.com>
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Wed, 20 Sep 2017 22:52:14 +0000 (15:52 -0700)]
net: phy: Keep reporting transceiver type
commit
ceb628134a75564d7bfa8e4ef902e6e588339e11 upstream.
With commit
2d55173e71b0 ("phy: add generic function to support
ksetting support"), we lost the ability to report the transceiver type
like we used to. Now that we have added back the transceiver type to
ethtool_link_settings, we can report it back like we used to and have no
loss of information.
Fixes:
3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
Fixes:
2d55173e71b0 ("phy: add generic function to support ksetting support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Wed, 20 Sep 2017 22:52:13 +0000 (15:52 -0700)]
net: ethtool: Add back transceiver type
commit
19cab8872692960535aa6d12e3a295ac51d1a648 upstream.
Commit
3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
deprecated the ethtool_cmd::transceiver field, which was fine in
premise, except that the PHY library was actually using it to report the
type of transceiver: internal or external.
Use the first word of the reserved field to put this __u8 transceiver
field back in. It is made read-only, and we don't expect the
ETHTOOL_xLINKSETTINGS API to be doing anything with this anyway, so this
is mostly for the legacy path where we do:
ethtool_get_settings()
-> dev->ethtool_ops->get_link_ksettings()
-> convert_link_ksettings_to_legacy_settings()
to have no information loss compared to the legacy get_settings API.
Fixes:
3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Finn Thain [Sat, 1 Dec 2018 00:53:10 +0000 (11:53 +1100)]
m68k: Call timer_interrupt() with interrupts disabled
[ Upstream commit
1efdd4bd254311498123a15fa0acd565f454da97 ]
Some platforms execute their timer handler with the interrupt priority
level set below 6. That means the handler could be interrupted by another
driver and this could lead to re-entry of the timer core.
Avoid this by use of local_irq_save/restore for timer interrupt dispatch.
This provides mutual exclusion around the timer interrupt flag access
which is needed later in this series for the clocksource conversion.
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1811131407120.2697@nanos.tec.linutronix.de
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Max Gurtovoy [Tue, 26 Feb 2019 10:22:11 +0000 (12:22 +0200)]
IB/iser: Fix dma_nents type definition
[ Upstream commit
c1545f1a200f4adc4ef8dd534bf33e2f1aa22c2f ]
The retured value from ib_dma_map_sg saved in dma_nents variable. To avoid
future mismatch between types, define dma_nents as an integer instead of
unsigned.
Fixes:
57b26497fabe ("IB/iser: Pass the correct number of entries for dma mapped SGL")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Israel Rukshin <israelr@mellanox.com>
Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andre Przywara [Tue, 19 Nov 2019 12:03:31 +0000 (12:03 +0000)]
arm64: dts: juno: Fix UART frequency
[ Upstream commit
39a1a8941b27c37f79508426e27a2ec29829d66c ]
Older versions of the Juno *SoC* TRM [1] recommended that the UART clock
source should be 7.2738 MHz, whereas the *system* TRM [2] stated a more
correct value of 7.3728 MHz. Somehow the wrong value managed to end up in
our DT.
Doing a prime factorisation, a modulo divide by 115200 and trying
to buy a 7.2738 MHz crystal at your favourite electronics dealer suggest
that the old value was actually a typo. The actual UART clock is driven
by a PLL, configured via a parameter in some board.txt file in the
firmware, which reads 7.37 MHz (sic!).
Fix this to correct the baud rate divisor calculation on the Juno board.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515b.b/DDI0515B_b_juno_arm_development_platform_soc_trm.pdf
[2] http://infocenter.arm.com/help/topic/com.arm.doc.100113_0000_07_en/arm_versatile_express_juno_development_platform_(v2m_juno)_technical_reference_manual_100113_0000_07_en.pdf
Fixes:
71f867ec130e ("arm64: Add Juno board device tree.")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sam Bobroff [Sun, 17 Nov 2019 23:53:53 +0000 (10:53 +1100)]
drm/radeon: fix bad DMA from INTERRUPT_CNTL2
[ Upstream commit
62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]
The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address. This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).
Instead, use the DMA address of the dummy page because it will always
be safe.
Fixes:
d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)")
Fixes:
25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes:
a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Mon, 18 Nov 2019 07:38:02 +0000 (15:38 +0800)]
dmaengine: ti: edma: fix missed failure handling
[ Upstream commit
340049d453682a9fe8d91fe794dd091730f4bb25 ]
When devm_kcalloc fails, it forgets to call edma_free_slot.
Replace direct return with failure handler to fix it.
Fixes:
1be5336bc7ba ("dmaengine: edma: New device tree binding")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191118073802.28424-1-hslester96@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Fri, 8 Nov 2019 13:07:46 +0000 (05:07 -0800)]
packet: fix data-race in fanout_flow_is_huge()
[ Upstream commit
b756ad928d98e5ef0b74af7546a6a31a8dadde00 ]
KCSAN reported the following data-race [1]
Adding a couple of READ_ONCE()/WRITE_ONCE() should silence it.
Since the report hinted about multiple cpus using the history
concurrently, I added a test avoiding writing on it if the
victim slot already contains the desired value.
[1]
BUG: KCSAN: data-race in fanout_demux_rollover / fanout_demux_rollover
read to 0xffff8880b01786cc of 4 bytes by task 18921 on cpu 1:
fanout_flow_is_huge net/packet/af_packet.c:1303 [inline]
fanout_demux_rollover+0x33e/0x3f0 net/packet/af_packet.c:1353
packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453
deliver_skb net/core/dev.c:1888 [inline]
dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958
xmit_one net/core/dev.c:3195 [inline]
dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215
__dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792
dev_queue_xmit+0x21/0x30 net/core/dev.c:3825
neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530
neigh_output include/net/neighbour.h:511 [inline]
ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
__ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
__ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
dst_output include/net/dst.h:436 [inline]
ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179
ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795
udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173
udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471
inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0x9f/0xc0 net/socket.c:657
___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311
__sys_sendmmsg+0x123/0x350 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg net/socket.c:2439 [inline]
__x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
write to 0xffff8880b01786cc of 4 bytes by task 18922 on cpu 0:
fanout_flow_is_huge net/packet/af_packet.c:1306 [inline]
fanout_demux_rollover+0x3a4/0x3f0 net/packet/af_packet.c:1353
packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453
deliver_skb net/core/dev.c:1888 [inline]
dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958
xmit_one net/core/dev.c:3195 [inline]
dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215
__dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792
dev_queue_xmit+0x21/0x30 net/core/dev.c:3825
neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530
neigh_output include/net/neighbour.h:511 [inline]
ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116
__ip6_finish_output net/ipv6/ip6_output.c:142 [inline]
__ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127
ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175
dst_output include/net/dst.h:436 [inline]
ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179
ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795
udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173
udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471
inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0x9f/0xc0 net/socket.c:657
___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311
__sys_sendmmsg+0x123/0x350 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg net/socket.c:2439 [inline]
__x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 18922 Comm: syz-executor.3 Not tainted 5.4.0-rc6+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Fixes:
3b3a5b0aab5b ("packet: rollover huge flows before small flows")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Tue, 5 Nov 2019 22:11:49 +0000 (14:11 -0800)]
net: neigh: use long type to store jiffies delta
[ Upstream commit
9d027e3a83f39b819e908e4e09084277a2e45e95 ]
A difference of two unsigned long needs long storage.
Fixes:
c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tiezhu Yang [Mon, 4 Nov 2019 13:33:50 +0000 (21:33 +0800)]
MIPS: Loongson: Fix return value of loongson_hwmon_init
[ Upstream commit
dece3c2a320b0a6d891da6ff774ab763969b6860 ]
When call function hwmon_device_register failed, use the actual
return value instead of always -ENOMEM.
Fixes:
64f09aa967e1 ("MIPS: Loongson-3: Add CPU Hwmon platform driver")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Janusz Krzysztofik [Tue, 3 Sep 2019 20:11:41 +0000 (17:11 -0300)]
media: ov6650: Fix .get_fmt() V4L2_SUBDEV_FORMAT_TRY support
[ Upstream commit
39034bb0c26b76a2c3abc54aa28c185f18b40c2f ]
Commit
da298c6d98d5 ("[media] v4l2: replace video op g_mbus_fmt by pad
op get_fmt") converted a former ov6650_g_fmt() video operation callback
to an ov6650_get_fmt() pad operation callback. However, the converted
function disregards a format->which flag that pad operations should
obey and always returns active frame format settings.
That can be fixed by always responding to V4L2_SUBDEV_FORMAT_TRY with
-EINVAL, or providing the response from a pad config argument, likely
updated by a former user call to V4L2_SUBDEV_FORMAT_TRY .set_fmt().
Since implementation of the latter is trivial, go for it.
Fixes:
da298c6d98d5 ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt")
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Janusz Krzysztofik [Tue, 3 Sep 2019 20:11:40 +0000 (17:11 -0300)]
media: ov6650: Fix some format attributes not under control
[ Upstream commit
1c6a2b63095154bbf9e8f38d79487a728331bf65 ]
User arguments passed to .get/set_fmt() pad operation callbacks may
contain unsupported values. The driver takes control over frame size
and pixel code as well as colorspace and field attributes but has never
cared for remainig format attributes, i.e., ycbcr_enc, quantization
and xfer_func, introduced by commit
11ff030c7365 ("[media]
v4l2-mediabus: improve colorspace support"). Fix it.
Set up a static v4l2_mbus_framefmt structure with attributes
initialized to reasonable defaults and use it for updating content of
user provided arguments. In case of V4L2_SUBDEV_FORMAT_ACTIVE,
postpone frame size update, now performed from inside ov6650_s_fmt()
helper, util the user argument is first updated in ov6650_set_fmt() with
default frame format content. For V4L2_SUBDEV_FORMAT_TRY, don't copy
all attributes to pad config, only those handled by the driver, then
fill the response with the default frame format updated with resulting
pad config format code and frame size.
Fixes:
11ff030c7365 ("[media] v4l2-mediabus: improve colorspace support")
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Janusz Krzysztofik [Tue, 3 Sep 2019 20:11:39 +0000 (17:11 -0300)]
media: ov6650: Fix incorrect use of JPEG colorspace
[ Upstream commit
12500731895ef09afc5b66b86b76c0884fb9c7bf ]
Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG
for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8. According
to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies
exclusively to V4L2_PIX_FMT_JPEG. Since the sensor does not support
JPEG format, fix it to always select V4L2_COLORSPACE_SRGB.
Fixes:
2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor")
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marc Dionne [Thu, 21 Nov 2019 15:37:26 +0000 (15:37 +0000)]
afs: Fix large file support
[ Upstream commit
b485275f1aca8a9da37fd35e4fad673935e827da ]
By default s_maxbytes is set to MAX_NON_LFS, which limits the usable
file size to 2GB, enforced by the vfs.
Commit
b9b1f8d5930a ("AFS: write support fixes") added support for the
64-bit fetch and store server operations, but did not change this value.
As a result, attempts to write past the 2G mark result in EFBIG errors:
$ dd if=/dev/zero of=foo bs=1M count=1 seek=2048
dd: error writing 'foo': File too large
Set s_maxbytes to MAX_LFS_FILESIZE.
Fixes:
b9b1f8d5930a ("AFS: write support fixes")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Wahren [Wed, 20 Nov 2019 17:29:13 +0000 (18:29 +0100)]
net: qca_spi: Move reset_count to struct qcaspi
[ Upstream commit
bc19c32904e36548335b35fdce6ce734e20afc0a ]
The reset counter is specific for every QCA700x chip. So move this
into the private driver struct. Otherwise we get unpredictable reset
behavior in setups with multiple QCA700x chips.
Fixes:
291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000)
Signed-off-by: Stefan Wahren <stefan.wahren@in-tech.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Fri, 18 Oct 2019 16:16:58 +0000 (09:16 -0700)]
net: netem: correct the parent's backlog when corrupted packet was dropped
[ Upstream commit
e0ad032e144731a5928f2d75e91c2064ba1a764c ]
If packet corruption failed we jump to finish_segs and return
NET_XMIT_SUCCESS. Seeing success will make the parent qdisc
increment its backlog, that's incorrect - we need to return
NET_XMIT_DROP.
Fixes:
6071bd1aa13e ("netem: Segment GSO packets on enqueue")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Fri, 18 Oct 2019 16:16:57 +0000 (09:16 -0700)]
net: netem: fix error path for corrupted GSO frames
[ Upstream commit
a7fa12d15855904aff1716e1fc723c03ba38c5cc ]
To corrupt a GSO frame we first perform segmentation. We then
proceed using the first segment instead of the full GSO skb and
requeue the rest of the segments as separate packets.
If there are any issues with processing the first segment we
still want to process the rest, therefore we jump to the
finish_segs label.
Commit
177b8007463c ("net: netem: fix backlog accounting for
corrupted GSO frames") started using the pointer to the first
segment in the "rest of segments processing", but as mentioned
above the first segment may had already been freed at this point.
Backlog corrections for parent qdiscs have to be adjusted.
Fixes:
177b8007463c ("net: netem: fix backlog accounting for corrupted GSO frames")
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robin Gong [Tue, 24 Sep 2019 09:49:18 +0000 (09:49 +0000)]
dmaengine: imx-sdma: fix size check for sdma script_number
[ Upstream commit
bd73dfabdda280fc5f05bdec79b6721b4b2f035f ]
Illegal memory will be touch if SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
(41) exceed the size of structure sdma_script_start_addrs(40),
thus cause memory corrupt such as slob block header so that kernel
trap into while() loop forever in slob_free(). Please refer to below
code piece in imx-sdma.c:
for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i]; /* memory corrupt here */
That issue was brought by commit
a572460be9cf ("dmaengine: imx-sdma: Add
support for version 3 firmware") because SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
(38->41 3 scripts added) not align with script number added in
sdma_script_start_addrs(2 scripts).
Fixes:
a572460be9cf ("dmaengine: imx-sdma: Add support for version 3 firmware")
Cc: stable@vger.kernel
Link: https://www.spinics.net/lists/arm-kernel/msg754895.html
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reported-by: Jurgen Lambrecht <J.Lambrecht@TELEVIC.com>
Link: https://lore.kernel.org/r/1569347584-3478-1-git-send-email-yibin.gong@nxp.com
[vkoul: update the patch title]
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jeffrey Hugo [Fri, 11 Oct 2019 13:39:39 +0000 (06:39 -0700)]
drm/msm/dsi: Implement reset correctly
[ Upstream commit
78e31c42261779a01bc73472d0f65f15378e9de3 ]
On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP. This is because the reset
logic is not correct per the hardware documentation.
The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.
wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes. Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.
Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.
Fixes:
a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: Hai Li <hali@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: Sean Paul <sean@poorly.run>
[seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Wed, 9 Oct 2019 03:10:52 +0000 (11:10 +0800)]
act_mirred: Fix mirred_init_module error handling
[ Upstream commit
11c9a7d38af524217efb7a176ad322b97ac2f163 ]
If tcf_register_action failed, mirred_device_notifier
should be unregistered.
Fixes:
3b87956ea645 ("net sched: fix race in mirred device removal")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antonio Borneo [Mon, 7 Oct 2019 15:43:04 +0000 (17:43 +0200)]
net: stmmac: fix length of PTP clock's name string
[ Upstream commit
5da202c88f8c355ad79bc2e8eb582e6d433060e7 ]
The field "name" in struct ptp_clock_info has a fixed size of 16
chars and is used as zero terminated string by clock_name_show()
in drivers/ptp/ptp_sysfs.c
The current initialization value requires 17 chars to fit also the
null termination, and this causes overflow to the next bytes in
the struct when the string is read as null terminated:
hexdump -C /sys/class/ptp/ptp0/clock_name
00000000 73 74 6d 6d 61 63 5f 70 74 70 5f 63 6c 6f 63 6b |stmmac_ptp_clock|
00000010 a0 ac b9 03 0a |.....|
where the extra 4 bytes (excluding the newline) after the string
represent the integer 0x03b9aca0 =
62500000 assigned to the field
"max_adj" that follows "name" in the same struct.
There is no strict requirement for the "name" content and in the
comment in ptp_clock_kernel.h it's reported it should just be 'A
short "friendly name" to identify the clock'.
Replace it with "stmmac ptp".
Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Fixes:
92ba6888510c ("stmmac: add the support for PTP hw clock driver")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Biggers [Sun, 6 Oct 2019 21:24:27 +0000 (14:24 -0700)]
llc: fix sk_buff refcounting in llc_conn_state_process()
[ Upstream commit
36453c852816f19947ca482a595dffdd2efa4965 ]
If llc_conn_state_process() sees that llc_conn_service() put the skb on
a list, it will drop one fewer references to it. This is wrong because
the current behavior is that llc_conn_service() never consumes a
reference to the skb.
The code also makes the number of skb references being dropped
conditional on which of ind_prim and cfm_prim are nonzero, yet neither
of these affects how many references are *acquired*. So there is extra
code that tries to fix this up by sometimes taking another reference.
Remove the unnecessary/broken refcounting logic and instead just add an
skb_get() before the only two places where an extra reference is
actually consumed.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Biggers [Sun, 6 Oct 2019 21:24:26 +0000 (14:24 -0700)]
llc: fix another potential sk_buff leak in llc_ui_sendmsg()
[ Upstream commit
fc8d5db10cbe1338a52ebc74e7feab9276721774 ]
All callers of llc_conn_state_process() except llc_build_and_send_pkt()
(via llc_ui_sendmsg() -> llc_ui_send_data()) assume that it always
consumes a reference to the skb. Fix this caller to do the same.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Fri, 4 Oct 2019 12:37:05 +0000 (15:37 +0300)]
mac80211: accept deauth frames in IBSS mode
[ Upstream commit
95697f9907bfe3eab0ef20265a766b22e27dde64 ]
We can process deauth frames and all, but we drop them very
early in the RX path today - this could never have worked.
Fixes:
2cc59e784b54 ("mac80211: reply to AUTH with DEAUTH if sta allocation fails in IBSS")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/20191004123706.15768-2-luca@coelho.fi
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jose Abreu [Sun, 6 Oct 2019 11:08:56 +0000 (13:08 +0200)]
net: stmmac: gmac4+: Not all Unicast addresses may be available
[ Upstream commit
25683bab09a70542b9f8e3e28f79b3369e56701f ]
Some setups may not have all Unicast addresses filters available. Check
the number of available filters before trying to setup it.
Fixes:
477286b53f55 ("stmmac: add GMAC4 core support")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Thu, 3 Oct 2019 11:57:29 +0000 (13:57 +0200)]
nvme: retain split access workaround for capability reads
[ Upstream commit
3a8ecc935efabdad106b5e06d07b150c394b4465 ]
Commit
7fd8930f26be4
"nvme: add a common helper to read Identify Controller data"
has re-introduced an issue that we have attempted to work around in the
past, in commit
a310acd7a7ea ("NVMe: use split lo_hi_{read,write}q").
The problem is that some PCIe NVMe controllers do not implement 64-bit
outbound accesses correctly, which is why the commit above switched
to using lo_hi_[read|write]q for all 64-bit BAR accesses occuring in
the code.
In the mean time, the NVMe subsystem has been refactored, and now calls
into the PCIe support layer for NVMe via a .reg_read64() method, which
fails to use lo_hi_readq(), and thus reintroduces the problem that the
workaround above aimed to address.
Given that, at the moment, .reg_read64() is only used to read the
capability register [which is known to tolerate split reads], let's
switch .reg_read64() to lo_hi_readq() as well.
This fixes a boot issue on some ARM boxes with NVMe behind a Synopsys
DesignWare PCIe host controller.
Fixes:
7fd8930f26be4 ("nvme: add a common helper to read Identify Controller data")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 25 Sep 2019 11:05:54 +0000 (14:05 +0300)]
net: ethernet: stmmac: Fix signedness bug in ipq806x_gmac_of_parse()
[ Upstream commit
231042181dc9d6122c6faba64e99ccb25f13cc6c ]
The "gmac->phy_mode" variable is an enum and in this context GCC will
treat it as an unsigned int so the error handling will never be
triggered.
Fixes:
b1c17215d718 ("stmmac: add ipq806x glue layer")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 25 Sep 2019 11:01:00 +0000 (14:01 +0300)]
of: mdio: Fix a signedness bug in of_phy_get_and_connect()
[ Upstream commit
d7eb651212fdbafa82d485d8e76095ac3b14c193 ]
The "iface" variable is an enum and in this context GCC treats it as
an unsigned int so the error handling is never triggered.
Fixes:
b78624125304 ("of_mdio: Abstract a general interface for phy connect")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 25 Sep 2019 10:58:22 +0000 (13:58 +0300)]
net: stmmac: dwmac-meson8b: Fix signedness bug in probe
[ Upstream commit
f10210517a2f37feea2edf85eb34c98977265c16 ]
The "dwmac->phy_mode" is an enum and in this context GCC treats it as
an unsigned int so the error handling is never triggered.
Fixes:
566e82516253 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 25 Sep 2019 10:56:04 +0000 (13:56 +0300)]
net: broadcom/bcmsysport: Fix signedness in bcm_sysport_probe()
[ Upstream commit
25a584955f020d6ec499c513923fb220f3112d2b ]
The "priv->phy_interface" variable is an enum and in this context GCC
will treat it as unsigned so the error handling will never be
triggered.
Fixes:
80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 25 Sep 2019 10:55:32 +0000 (13:55 +0300)]
net: hisilicon: Fix signedness bug in hix5hd2_dev_probe()
[ Upstream commit
002dfe8085255b7bf1e0758c3d195c5412d35be9 ]
The "priv->phy_mode" variable is an enum and in this context GCC will
treat it as unsigned to the error handling will never trigger.
Fixes:
57c5bc9ad7d7 ("net: hisilicon: add hix5hd2 mac driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Filippo Sironi [Tue, 10 Sep 2019 17:49:21 +0000 (19:49 +0200)]
iommu/amd: Wait for completion of IOTLB flush in attach_device
[ Upstream commit
0b15e02f0cc4fb34a9160de7ba6db3a4013dc1b7 ]
To make sure the domain tlb flush completes before the
function returns, explicitly wait for its completion.
Signed-off-by: Filippo Sironi <sironi@amazon.de>
Fixes:
42a49f965a8d ("amd-iommu: flush domain tlb when attaching a new device")
[joro: Added commit message and fixes tag]
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gerd Rausch [Thu, 12 Sep 2019 20:49:41 +0000 (13:49 -0700)]
net/rds: Fix 'ib_evt_handler_call' element in 'rds_ib_stat_names'
[ Upstream commit
05a82481a3024b94db00b8c816bb3d526b5209e0 ]
All entries in 'rds_ib_stat_names' are stringified versions
of the corresponding "struct rds_ib_statistics" element
without the "s_"-prefix.
Fix entry 'ib_evt_handler_call' to do the same.
Fixes:
f4f943c958a2 ("RDS: IB: ack more receive completions to improve performance")
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mao Wenan [Wed, 11 Sep 2019 01:36:23 +0000 (09:36 +0800)]
net: sonic: replace dev_kfree_skb in sonic_send_packet
[ Upstream commit
49f6c90bf6805948b597eabb499e500a47cf24be ]
sonic_send_packet will be processed in irq or non-irq
context, so it would better use dev_kfree_skb_any
instead of dev_kfree_skb.
Fixes:
d9fb9f384292 ("*sonic/natsemi/ns83829: Move the National Semi-conductor drivers")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Robertson [Thu, 5 Sep 2019 01:45:54 +0000 (01:45 +0000)]
hwmon: (shtc1) fix shtc1 and shtw1 id mask
[ Upstream commit
fdc7d8e829ec755c5cfb2f5a8d8c0cdfb664f895 ]
Fix an error in the bitmaskfor the shtc1 and shtw1 bitmask used to
retrieve the chip ID from the ID register. See section 5.7 of the shtw1
or shtc1 datasheet for details.
Fixes:
1a539d372edd9832444e7a3daa710c444c014dc9 ("hwmon: add support for Sensirion SHTC1 sensor")
Signed-off-by: Dan Robertson <dan@dlrobertson.com>
Link: https://lore.kernel.org/r/20190905014554.21658-3-dan@dlrobertson.com
[groeck: Reordered to be first in series and adjusted accordingly]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Filipe Manana [Thu, 4 Jul 2019 15:24:09 +0000 (16:24 +0100)]
Btrfs: fix hang when loading existing inode cache off disk
[ Upstream commit
7764d56baa844d7f6206394f21a0e8c1f303c476 ]
If we are able to load an existing inode cache off disk, we set the state
of the cache to BTRFS_CACHE_FINISHED, but we don't wake up any one waiting
for the cache to be available. This means that anyone waiting for the
cache to be available, waiting on the condition that either its state is
BTRFS_CACHE_FINISHED or its available free space is greather than zero,
can hang forever.
This could be observed running fstests with MOUNT_OPTIONS="-o inode_cache",
in particular test case generic/161 triggered it very frequently for me,
producing a trace like the following:
[63795.739712] BTRFS info (device sdc): enabling inode map caching
[63795.739714] BTRFS info (device sdc): disk space caching is enabled
[63795.739716] BTRFS info (device sdc): has skinny extents
[64036.653886] INFO: task btrfs-transacti:3917 blocked for more than 120 seconds.
[64036.654079] Not tainted 5.2.0-rc4-btrfs-next-50 #1
[64036.654143] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[64036.654232] btrfs-transacti D 0 3917 2 0x80004000
[64036.654239] Call Trace:
[64036.654258] ? __schedule+0x3ae/0x7b0
[64036.654271] schedule+0x3a/0xb0
[64036.654325] btrfs_commit_transaction+0x978/0xae0 [btrfs]
[64036.654339] ? remove_wait_queue+0x60/0x60
[64036.654395] transaction_kthread+0x146/0x180 [btrfs]
[64036.654450] ? btrfs_cleanup_transaction+0x620/0x620 [btrfs]
[64036.654456] kthread+0x103/0x140
[64036.654464] ? kthread_create_worker_on_cpu+0x70/0x70
[64036.654476] ret_from_fork+0x3a/0x50
[64036.654504] INFO: task xfs_io:3919 blocked for more than 120 seconds.
[64036.654568] Not tainted 5.2.0-rc4-btrfs-next-50 #1
[64036.654617] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[64036.654685] xfs_io D 0 3919 3633 0x00000000
[64036.654691] Call Trace:
[64036.654703] ? __schedule+0x3ae/0x7b0
[64036.654716] schedule+0x3a/0xb0
[64036.654756] btrfs_find_free_ino+0xa9/0x120 [btrfs]
[64036.654764] ? remove_wait_queue+0x60/0x60
[64036.654809] btrfs_create+0x72/0x1f0 [btrfs]
[64036.654822] lookup_open+0x6bc/0x790
[64036.654849] path_openat+0x3bc/0xc00
[64036.654854] ? __lock_acquire+0x331/0x1cb0
[64036.654869] do_filp_open+0x99/0x110
[64036.654884] ? __alloc_fd+0xee/0x200
[64036.654895] ? do_raw_spin_unlock+0x49/0xc0
[64036.654909] ? do_sys_open+0x132/0x220
[64036.654913] do_sys_open+0x132/0x220
[64036.654926] do_syscall_64+0x60/0x1d0
[64036.654933] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fix this by adding a wake_up() call right after setting the cache state to
BTRFS_CACHE_FINISHED, at start_caching(), when we are able to load the
cache from disk.
Fixes:
82d5902d9c681b ("Btrfs: Support reading/writing on disk free ino cache")
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mao Wenan [Thu, 5 Sep 2019 01:57:12 +0000 (09:57 +0800)]
net: sonic: return NETDEV_TX_OK if failed to map buffer
[ Upstream commit
6e1cdedcf0362fed3aedfe051d46bd7ee2a85fe1 ]
NETDEV_TX_BUSY really should only be used by drivers that call
netif_tx_stop_queue() at the wrong moment. If dma_map_single() is
failed to map tx DMA buffer, it might trigger an infinite loop.
This patch use NETDEV_TX_OK instead of NETDEV_TX_BUSY, and change
printk to pr_err_ratelimited.
Fixes:
d9fb9f384292 ("*sonic/natsemi/ns83829: Move the National Semi-conductor drivers")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Mon, 19 Aug 2019 07:41:39 +0000 (09:41 +0200)]
ath9k: dynack: fix possible deadlock in ath_dynack_node_{de}init
[ Upstream commit
e1aa1a1db3b01c9890e82cf065cee99962ba1ed9 ]
Fix following lockdep warning disabling bh in
ath_dynack_node_init/ath_dynack_node_deinit
[ 75.955878] --------------------------------
[ 75.955880] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 75.955884] swapper/0/0 [HC0[0]:SC1[3]:HE1:SE0] takes:
[ 75.955888]
00000000792a7ee0 (&(&da->qlock)->rlock){+.?.}, at: ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
[ 75.955905] {SOFTIRQ-ON-W} state was registered at:
[ 75.955912] lock_acquire+0x9a/0x160
[ 75.955917] _raw_spin_lock+0x2c/0x70
[ 75.955927] ath_dynack_node_init+0x2a/0x60 [ath9k_hw]
[ 75.955934] ath9k_sta_state+0xec/0x160 [ath9k]
[ 75.955976] drv_sta_state+0xb2/0x740 [mac80211]
[ 75.956008] sta_info_insert_finish+0x21a/0x420 [mac80211]
[ 75.956039] sta_info_insert_rcu+0x12b/0x2c0 [mac80211]
[ 75.956069] sta_info_insert+0x7/0x70 [mac80211]
[ 75.956093] ieee80211_prep_connection+0x42e/0x730 [mac80211]
[ 75.956120] ieee80211_mgd_auth.cold+0xb9/0x15c [mac80211]
[ 75.956152] cfg80211_mlme_auth+0x143/0x350 [cfg80211]
[ 75.956169] nl80211_authenticate+0x25e/0x2b0 [cfg80211]
[ 75.956172] genl_family_rcv_msg+0x198/0x400
[ 75.956174] genl_rcv_msg+0x42/0x90
[ 75.956176] netlink_rcv_skb+0x35/0xf0
[ 75.956178] genl_rcv+0x1f/0x30
[ 75.956180] netlink_unicast+0x154/0x200
[ 75.956182] netlink_sendmsg+0x1bf/0x3d0
[ 75.956186] ___sys_sendmsg+0x2c2/0x2f0
[ 75.956187] __sys_sendmsg+0x44/0x80
[ 75.956190] do_syscall_64+0x55/0x1a0
[ 75.956192] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 75.956194] irq event stamp: 2357092
[ 75.956196] hardirqs last enabled at (2357092): [<
ffffffff818c62de>] _raw_spin_unlock_irqrestore+0x3e/0x50
[ 75.956199] hardirqs last disabled at (2357091): [<
ffffffff818c60b1>] _raw_spin_lock_irqsave+0x11/0x80
[ 75.956202] softirqs last enabled at (2357072): [<
ffffffff8106dc09>] irq_enter+0x59/0x60
[ 75.956204] softirqs last disabled at (2357073): [<
ffffffff8106dcbe>] irq_exit+0xae/0xc0
[ 75.956206]
other info that might help us debug this:
[ 75.956207] Possible unsafe locking scenario:
[ 75.956208] CPU0
[ 75.956209] ----
[ 75.956210] lock(&(&da->qlock)->rlock);
[ 75.956213] <Interrupt>
[ 75.956214] lock(&(&da->qlock)->rlock);
[ 75.956216]
*** DEADLOCK ***
[ 75.956217] 1 lock held by swapper/0/0:
[ 75.956219] #0:
000000003bb5675c (&(&sc->sc_pcu_lock)->rlock){+.-.}, at: ath9k_tasklet+0x55/0x240 [ath9k]
[ 75.956225]
stack backtrace:
[ 75.956228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc1-wdn+ #13
[ 75.956229] Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009
[ 75.956231] Call Trace:
[ 75.956233] <IRQ>
[ 75.956236] dump_stack+0x67/0x90
[ 75.956239] mark_lock+0x4c1/0x640
[ 75.956242] ? check_usage_backwards+0x130/0x130
[ 75.956245] ? sched_clock_local+0x12/0x80
[ 75.956247] __lock_acquire+0x484/0x7a0
[ 75.956250] ? __lock_acquire+0x3b9/0x7a0
[ 75.956252] lock_acquire+0x9a/0x160
[ 75.956259] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
[ 75.956262] _raw_spin_lock_bh+0x34/0x80
[ 75.956268] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
[ 75.956275] ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
[ 75.956280] ath_rx_tasklet+0xd09/0xe90 [ath9k]
[ 75.956286] ath9k_tasklet+0x102/0x240 [ath9k]
[ 75.956288] tasklet_action_common.isra.0+0x6d/0x170
[ 75.956291] __do_softirq+0xcc/0x425
[ 75.956294] irq_exit+0xae/0xc0
[ 75.956296] do_IRQ+0x8a/0x110
[ 75.956298] common_interrupt+0xf/0xf
[ 75.956300] </IRQ>
[ 75.956303] RIP: 0010:cpuidle_enter_state+0xb2/0x400
[ 75.956308] RSP: 0018:
ffffffff82203e70 EFLAGS:
00000202 ORIG_RAX:
ffffffffffffffd7
[ 75.956310] RAX:
ffffffff82219800 RBX:
ffffffff822bd0a0 RCX:
0000000000000000
[ 75.956312] RDX:
0000000000000046 RSI:
0000000000000006 RDI:
ffffffff82219800
[ 75.956314] RBP:
ffff888155a01c00 R08:
00000011af51aabe R09:
0000000000000000
[ 75.956315] R10:
0000000000000000 R11:
0000000000000000 R12:
0000000000000002
[ 75.956317] R13:
00000011af51aabe R14:
0000000000000003 R15:
ffffffff82219800
[ 75.956321] cpuidle_enter+0x24/0x40
[ 75.956323] do_idle+0x1ac/0x220
[ 75.956326] cpu_startup_entry+0x14/0x20
[ 75.956329] start_kernel+0x482/0x489
[ 75.956332] secondary_startup_64+0xa4/0xb0
Fixes:
c774d57fd47c ("ath9k: add dynamic ACK timeout estimation")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Thu, 15 Aug 2019 11:58:46 +0000 (12:58 +0100)]
iio: dac: ad5380: fix incorrect assignment to val
[ Upstream commit
b1e18768ef1214c0a8048327918a182cabe09f9d ]
Currently the pointer val is being incorrectly incremented
instead of the value pointed to by val. Fix this by adding
in the missing * indirection operator.
Addresses-Coverity: ("Unused value")
Fixes:
c03f2c536818 ("staging:iio:dac: Add AD5380 driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Tue, 27 Aug 2019 08:16:20 +0000 (09:16 +0100)]
bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA
[ Upstream commit
420c20be08a4597404d272ae9793b642401146eb ]
An earlier commit re-worked the setting of the bitmask and is now
assigning v with some bit flags rather than bitwise or-ing them
into v, consequently the earlier bit-settings of v are being lost.
Fix this by replacing an assignment with the bitwise or instead.
Addresses-Coverity: ("Unused value")
Fixes:
2be25cac8402 ("bcma: add constants for PCI and use them")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 29 Aug 2019 12:28:39 +0000 (15:28 +0300)]
staging: greybus: light: fix a couple double frees
[ Upstream commit
329101244f214952606359d254ae883b7109e1a5 ]
The problem is in gb_lights_request_handler(). If we get a request to
change the config then we release the light with gb_lights_light_release()
and re-allocated it. However, if the allocation fails part way through
then we call gb_lights_light_release() again. This can lead to a couple
different double frees where we haven't cleared out the original values:
gb_lights_light_v4l2_unregister(light);
...
kfree(light->channels);
kfree(light->name);
I also made a small change to how we set "light->channels_count = 0;".
The original code handled this part fine and did not cause a use after
free but it was sort of complicated to read.
Fixes:
2870b52bae4c ("greybus: lights: add lights implementation")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Link: https://lore.kernel.org/r/20190829122839.GA20116@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Sun, 1 Sep 2019 03:03:08 +0000 (12:03 +0900)]
x86, perf: Fix the dependency of the x86 insn decoder selftest
[ Upstream commit
7720804a2ae46c90265a32c81c45fb6f8d2f4e8b ]
Since x86 instruction decoder is not only for kprobes,
it should be tested when the insn.c is compiled.
(e.g. perf is enabled but kprobes is disabled)
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes:
cbe5c34c8c1f ("x86: Compile insn.c and inat.c only for KPROBES")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Boyd [Thu, 1 Aug 2019 21:33:30 +0000 (14:33 -0700)]
power: supply: Init device wakeup after device_add()
[ Upstream commit
8288022284859acbcc3cf1a073a1e2692d6c2543 ]
We may want to use the device pointer in device_init_wakeup() with
functions that expect the device to already be added with device_add().
For example, if we were to link the device initializing wakeup to
something in sysfs such as a class for wakeups we'll run into an error.
It looks like this code was written with the assumption that the device
would be added before initializing wakeup due to the order of operations
in power_supply_unregister().
Let's change the order of operations so we don't run into problems here.
Fixes:
948dcf966228 ("power_supply: Prevent suspend until power supply events are processed")
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tri Vo <trong@android.com>
Cc: Kalesh Singh <kaleshsingh@google.com>
Cc: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guenter Roeck [Thu, 8 Aug 2019 19:00:18 +0000 (12:00 -0700)]
hwmon: (lm75) Fix write operations for negative temperatures
[ Upstream commit
7d82fcc9d9e81241778aaa22fda7be753e237d86 ]
Writes into limit registers fail if the temperature written is negative.
The regmap write operation checks the value range, regmap_write accepts
an unsigned int as parameter, and the temperature value passed to
regmap_write is kept in a variable declared as long. Negative values
are converted large unsigned integers, which fails the range check.
Fix by type casting the temperature to u16 when calling regmap_write().
Cc: Iker Perez del Palomar Sustatxa <iker.perez@codethink.co.uk>
Fixes:
e65365fed87f ("hwmon: (lm75) Convert to use regmap")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Torvalds [Sat, 31 Aug 2019 01:47:15 +0000 (18:47 -0700)]
Partially revert "kfifo: fix kfifo_alloc() and kfifo_init()"
[ Upstream commit
ab9bb6318b0967671e0c9b6537c1537d51ca4f45 ]
Commit
dfe2a77fd243 ("kfifo: fix kfifo_alloc() and kfifo_init()") made
the kfifo code round the number of elements up. That was good for
__kfifo_alloc(), but it's actually wrong for __kfifo_init().
The difference? __kfifo_alloc() will allocate the rounded-up number of
elements, but __kfifo_init() uses an allocation done by the caller. We
can't just say "use more elements than the caller allocated", and have
to round down.
The good news? All the normal cases will be using power-of-two arrays
anyway, and most users of kfifo's don't use kfifo_init() at all, but one
of the helper macros to declare a KFIFO that enforce the proper
power-of-two behavior. But it looks like at least ibmvscsis might be
affected.
The bad news? Will Deacon refers to an old thread and points points out
that the memory ordering in kfifo's is questionable. See
https://lore.kernel.org/lkml/
20181211034032.32338-1-yuleixzhang@tencent.com/
for more.
Fixes:
dfe2a77fd243 ("kfifo: fix kfifo_alloc() and kfifo_init()")
Reported-by: laokz <laokz@foxmail.com>
Cc: Stefani Seibold <stefani@seibold.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Greg KH <greg@kroah.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Fri, 30 Aug 2019 19:42:55 +0000 (22:42 +0300)]
ahci: Do not export local variable ahci_em_messages
[ Upstream commit
60fc35f327e0a9e60b955c0f3c3ed623608d1baa ]
The commit
ed08d40cdec4
("ahci: Changing two module params with static and __read_mostly")
moved ahci_em_messages to be static while missing the fact of exporting it.
WARNING: "ahci_em_messages" [vmlinux] is a static EXPORT_SYMBOL_GPL
Drop export for the local variable ahci_em_messages.
Fixes:
ed08d40cdec4 ("ahci: Changing two module params with static and __read_mostly")
Cc: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nick Desaulniers [Mon, 29 Jul 2019 21:10:12 +0000 (14:10 -0700)]
mips: avoid explicit UB in assignment of mips_io_port_base
[ Upstream commit
12051b318bc3ce5b42d6d786191008284b067d83 ]
The code in question is modifying a variable declared const through
pointer manipulation. Such code is explicitly undefined behavior, and
is the lone issue preventing malta_defconfig from booting when built
with Clang:
If an attempt is made to modify an object defined with a const-qualified
type through use of an lvalue with non-const-qualified type, the
behavior is undefined.
LLVM is removing such assignments. A simple fix is to not declare
variables const that you plan on modifying. Limiting the scope would be
a better method of preventing unwanted writes to such a variable.
Further, the code in question mentions "compiler bugs" without any links
to bug reports, so it is difficult to know if the issue is resolved in
GCC. The patch was authored in 2006, which would have been GCC 4.0.3 or
4.1.1. The minimal supported version of GCC in the Linux kernel is
currently 4.6.
For what its worth, there was UB before the commit in question, it just
added a barrier and got lucky IRT codegen. I don't think there's any
actual compiler bugs related, just runtime bugs due to UB.
Link: https://github.com/ClangBuiltLinux/linux/issues/610
Fixes:
966f4406d903 ("[MIPS] Work around bad code generation for <asm/io.h>.")
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Debugged-by: Nathan Chancellor <natechancellor@gmail.com>
Suggested-by: Eli Friedman <efriedma@quicinc.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: ralf@linux-mips.org
Cc: jhogan@kernel.org
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: Stephen Kitt <steve@sk2.org>
Cc: Serge Semin <fancer.lancer@gmail.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: clang-built-linux@googlegroups.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Felix Fietkau [Tue, 20 Aug 2019 09:54:46 +0000 (11:54 +0200)]
mac80211: minstrel_ht: fix per-group max throughput rate initialization
[ Upstream commit
56dd918ff06e3ee24d8067e93ed12b2a39e71394 ]
The group number needs to be multiplied by the number of rates per group
to get the full rate index
Fixes:
5935839ad735 ("mac80211: improve minstrel_ht rate sorting by throughput & probability")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20190820095449.45255-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Tue, 20 Aug 2019 13:15:43 +0000 (16:15 +0300)]
dmaengine: dw: platform: Switch to acpi_dma_controller_register()
[ Upstream commit
e7b8514e4d68bec21fc6385fa0a66797ddc34ac9 ]
There is a possibility to have registered ACPI DMA controller
while it has been gone already.
To avoid the potential crash, move to non-managed
acpi_dma_controller_register().
Fixes:
42c91ee71d6d ("dw_dmac: add ACPI support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20190820131546.75744-8-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxime Ripard [Mon, 19 Aug 2019 19:25:17 +0000 (21:25 +0200)]
ASoC: sun4i-i2s: RX and TX counter registers are swapped
[ Upstream commit
cf2c0e1ce9544df42170fb921f12da82dc0cc8d6 ]
The RX and TX counters registers offset have been swapped, fix that.
Fixes:
fa7c0d13cb26 ("ASoC: sunxi: Add Allwinner A10 Digital Audio driver")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/8b26477560ad5fd8f69e037b167c5e61de5c26a3.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric W. Biederman [Fri, 16 Aug 2019 17:33:54 +0000 (12:33 -0500)]
signal: Allow cifs and drbd to receive their terminating signals
[ Upstream commit
33da8e7c814f77310250bb54a9db36a44c5de784 ]
My recent to change to only use force_sig for a synchronous events
wound up breaking signal reception cifs and drbd. I had overlooked
the fact that by default kthreads start out with all signals set to
SIG_IGN. So a change I thought was safe turned out to have made it
impossible for those kernel thread to catch their signals.
Reverting the work on force_sig is a bad idea because what the code
was doing was very much a misuse of force_sig. As the way force_sig
ultimately allowed the signal to happen was to change the signal
handler to SIG_DFL. Which after the first signal will allow userspace
to send signals to these kernel threads. At least for
wake_ack_receiver in drbd that does not appear actively wrong.
So correct this problem by adding allow_kernel_signal that will allow
signals whose siginfo reports they were sent by the kernel through,
but will not allow userspace generated signals, and update cifs and
drbd to call allow_kernel_signal in an appropriate place so that their
thread can receive this signal.
Fixing things this way ensures that userspace won't be able to send
signals and cause problems, that it is clear which signals the
threads are expecting to receive, and it guarantees that nothing
else in the system will be affected.
This change was partly inspired by similar cifs and drbd patches that
added allow_signal.
Reported-by: ronnie sahlberg <ronniesahlberg@gmail.com>
Reported-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Tested-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Cc: Steve French <smfrench@gmail.com>
Cc: Philipp Reisner <philipp.reisner@linbit.com>
Cc: David Laight <David.Laight@ACULAB.COM>
Fixes:
247bc9470b1e ("cifs: fix rmmod regression in cifs.ko caused by force_sig changes")
Fixes:
72abe3bcf091 ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig")
Fixes:
fee109901f39 ("signal/drbd: Use send_sig not force_sig")
Fixes:
3cf5d076fb4d ("signal: Remove task parameter from force_sig")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Thu, 15 Aug 2019 09:19:20 +0000 (17:19 +0800)]
ASoC: wm8737: Fix copy-paste error in wm8737_snd_controls
[ Upstream commit
554b75bde64bcad9662530726d1483f7ef012069 ]
sound/soc/codecs/wm8737.c:112:29: warning:
high_3d defined but not used [-Wunused-const-variable=]
'high_3d' should be used for 3D High Cut-off.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes:
2a9ae13a2641 ("ASoC: Add initial WM8737 driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20190815091920.64480-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Thu, 15 Aug 2019 09:01:57 +0000 (17:01 +0800)]
ASoC: cs4349: Use PM ops 'cs4349_runtime_pm'
[ Upstream commit
9b4275c415acca6264a3d7f1182589959c93d530 ]
sound/soc/codecs/cs4349.c:358:32: warning:
cs4349_runtime_pm defined but not used [-Wunused-const-variable=]
cs4349_runtime_pm ops already defined, it seems
we should enable it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: e40da86 ("ASoC: cs4349: Add support for Cirrus Logic CS4349")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190815090157.70036-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Thu, 15 Aug 2019 09:23:00 +0000 (17:23 +0800)]
ASoC: es8328: Fix copy-paste error in es8328_right_line_controls
[ Upstream commit
630742c296341a8cfe00dfd941392025ba8dd4e8 ]
It seems 'es8328_rline_enum' should be used
in es8328_right_line_controls
Fixes:
567e4f98922c ("ASoC: add es8328 codec driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190815092300.68712-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Mon, 12 Aug 2019 18:29:38 +0000 (14:29 -0400)]
ext4: set error return correctly when ext4_htree_store_dirent fails
[ Upstream commit
7a14826ede1d714f0bb56de8167c0e519041eeda ]
Currently when the call to ext4_htree_store_dirent fails the error return
variable 'ret' is is not being set to the error code and variable count is
instead, hence the error code is not being returned. Fix this by assigning
ret to the error return code.
Addresses-Coverity: ("Unused value")
Fixes:
8af0f0822797 ("ext4: fix readdir error in the case of inline_data+dir_index")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Iuliana Prodan [Wed, 31 Jul 2019 13:08:12 +0000 (16:08 +0300)]
crypto: caam - free resources in case caam_rng registration failed
[ Upstream commit
c59a1d41672a89b5cac49db1a472ff889e35a2d2 ]
Check the return value of the hardware registration for caam_rng and free
resources in case of failure.
Fixes:
e24f7c9e87d4 ("crypto: caam - hwrng support")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steve French [Wed, 24 Jul 2019 03:14:29 +0000 (22:14 -0500)]
cifs: fix rmmod regression in cifs.ko caused by force_sig changes
[ Upstream commit
247bc9470b1eeefc7b58cdf2c39f2866ba651509 ]
Fixes:
72abe3bcf091 ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig")
The global change from force_sig caused module unloading of cifs.ko
to fail (since the cifsd process could not be killed, "rmmod cifs"
now would always fail)
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
CC: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mark Zhang [Wed, 31 Jul 2019 11:40:13 +0000 (14:40 +0300)]
net/mlx5: Fix mlx5_ifc_query_lag_out_bits
[ Upstream commit
ea77388b02270b0af8dc57f668f311235ea068f0 ]
Remove the "reserved_at_40" field to match the device specification.
Fixes:
84df61ebc69b ("net/mlx5: Add HW interfaces used by LAG")
Signed-off-by: Mark Zhang <markz@mellanox.com>
Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Mon, 29 Jul 2019 07:14:22 +0000 (09:14 +0200)]
ALSA: aoa: onyx: always initialize register read value
[ Upstream commit
f474808acb3c4b30552d9c59b181244e0300d218 ]
A lot of places in the driver use onyx_read_register() without
checking the return value, and it's been working OK for ~10 years
or so, so probably never fails ... Rather than trying to check the
return value everywhere, which would be relatively intrusive, at
least make sure we don't use an uninitialized value.
Fixes:
f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thomas Gleixner [Mon, 22 Jul 2019 18:47:06 +0000 (20:47 +0200)]
x86/kgbd: Use NMI_VECTOR not APIC_DM_NMI
[ Upstream commit
2591bc4e8d70b4e1330d327fb7e3921f4e070a51 ]
apic->send_IPI_allbutself() takes a vector number as argument.
APIC_DM_NMI is clearly not a vector number. It's defined to 0x400 which is
outside the vector space.
Use NMI_VECTOR instead as that's what it is intended to be.
Fixes:
82da3ff89dc2 ("x86: kgdb support")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20190722105218.855189979@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Fri, 12 Jul 2019 09:24:09 +0000 (11:24 +0200)]
mic: avoid statically declaring a 'struct device'.
[ Upstream commit
bc83f79bd2119230888fb8574639d5a51b38f903 ]
Generally, declaring a platform device as a static variable is
a bad idea and can cause all kinds of problems, in particular
with the DMA configuration and lifetime rules.
A specific problem we hit here is from a bug in clang that warns
about certain (otherwise valid) macros when used in static variables:
drivers/misc/mic/card/mic_x100.c:285:27: warning: shift count >= width of type [-Wshift-count-overflow]
static u64 mic_dma_mask = DMA_BIT_MASK(64);
^~~~~~~~~~~~~~~~
include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK'
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
^ ~~~
A slightly better way here is to create the platform device dynamically
and set the dma mask in the probe function.
This avoids the warning and some other problems, but is still not ideal
because the device creation should really be separated from the driver,
and the fact that the device has no parent means we have to force
the dma mask rather than having it set up from the bus that the device
is actually on.
Fixes:
dd8d8d44df64 ("misc: mic: MIC card driver specific changes to enable SCIF")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20190712092426.872625-1-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ruslan Bilovol [Sun, 7 Jul 2019 12:17:19 +0000 (15:17 +0300)]
usb: host: xhci-hub: fix extra endianness conversion
[ Upstream commit
6269e4c76eacabaea0d0099200ae1a455768d208 ]
Don't do extra cpu_to_le32 conversion for
put_unaligned_le32 because it is already implemented
in this function.
Fixes sparse error:
xhci-hub.c:1152:44: warning: incorrect type in argument 1 (different base types)
xhci-hub.c:1152:44: expected unsigned int [usertype] val
xhci-hub.c:1152:44: got restricted __le32 [usertype]
Fixes: 395f540 "xhci: support new USB 3.1 hub request to get extended port status"
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/1562501839-26522-1-git-send-email-ruslan.bilovol@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Mon, 22 Jul 2019 15:01:23 +0000 (17:01 +0200)]
qed: reduce maximum stack frame size
[ Upstream commit
7c116e02a4a7575c8c62bfd2106e3e3ec8fb99dc ]
clang warns about an overly large stack frame in one function
when it decides to inline all __qed_get_vport_*() functions into
__qed_get_vport_stats():
drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of 1128 bytes in function '_qed_get_vport_stats' [-Werror,-Wframe-larger-than=]
Use a noinline_for_stack annotation to prevent clang from inlining
these, which keeps the maximum stack usage at around half of that
in the worst case, similar to what we get with gcc.
Fixes:
86622ee75312 ("qed: Move statistics to L2 code")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Tue, 16 Jul 2019 14:42:18 +0000 (22:42 +0800)]
libertas_tf: Use correct channel range in lbtf_geo_init
[ Upstream commit
2ec4ad49b98e4a14147d04f914717135eca7c8b1 ]
It seems we should use 'range' instead of 'priv->range'
in lbtf_geo_init(), because 'range' is the corret one
related to current regioncode.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes:
691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Tue, 2 Jul 2019 09:18:35 +0000 (10:18 +0100)]
scsi: libfc: fix null pointer dereference on a null lport
[ Upstream commit
41a6bf6529edd10a6def42e3b2c34a7474bcc2f5 ]
Currently if lport is null then the null lport pointer is dereference when
printing out debug via the FC_LPORT_DB macro. Fix this by using the more
generic FC_LIBFC_DBG debug macro instead that does not use lport.
Addresses-Coverity: ("Dereference after null check")
Fixes:
7414705ea4ae ("libfc: Add runtime debugging with debug_logging module parameter")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wen Yang [Sat, 6 Jul 2019 04:23:41 +0000 (12:23 +0800)]
net: pasemi: fix an use-after-free in pasemi_mac_phy_init()
[ Upstream commit
faf5577f2498cea23011b5c785ef853ded22700b ]
The phy_dn variable is still being used in of_phy_connect() after the
of_node_put() call, which may result in use-after-free.
Fixes:
1dd2d06c0459 ("net: Rework pasemi_mac driver to use of_mdio infrastructure")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
projects / platform / kernel / linux-amlogic.git / log