Store the ELD correctly, not just enough copies of the first byte
to pad out the given ELD size.
Signed-off-by: Alastair Bridgewater <alastair.bridgewater@gmail.com>
Fixes: 120b0c39c7 ("drm/nv50-/disp: audit and version SOR_HDA_ELD method")
Cc: stable@vger.kernel.org # v3.17+
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The proper fix would have been to select LEDS_CLASS but this can lead
to a circular dependency, as found out by Arnd.
This patch implements Arnd's suggestion instead, at the cost of some
auto-magic for a fringe feature.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Intel's 0-DAY
Fixes: 8d021d71b3 ("drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logo")
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The workaround appears to cause regressions on these boards, and from
inspection of RM traces, NVIDIA don't appear to do it on them either.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Roy Spliet <nouveau@spliet.org>
Commit a389fcfd2c ("Drivers: hv: vmbus: Fix signaling logic in
hv_need_to_signal_on_read()")
added the proper mb(), but removed the test "prev_write_sz < pending_sz"
when making the signal decision.
As a result, the guest can signal the host unnecessarily,
and then the host can throttle the guest because the host
thinks the guest is buggy or malicious; finally the user
running stress test can perceive intermittent freeze of
the guest.
This patch brings back the test, and properly handles the
in-place consumption APIs used by NetVSC (see get_next_pkt_raw(),
put_pkt_raw() and commit_rd_index()).
Fixes: a389fcfd2c ("Drivers: hv: vmbus: Fix signaling logic in
hv_need_to_signal_on_read()")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reported-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Tested-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These tests are reversed. A warning should be displayed if an error is
returned, not on success.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull sparc fixes from David Miller:
"Several small bug fixes and tidies, along with a fix for non-resumable
memory errors triggered by userspace"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Handle PIO & MEM non-resumable errors.
sparc64: Zero pages on allocation for mondo and error queues.
sparc: Fixed typo in sstate.c. Replaced panicing with panicking
sparc: use symbolic names for tsb indexing
Liam R. Howlett says:
====================
sparc64: Recover from userspace non-resumable PIO & MEM errors
A non-resumable error from userspace is able to cause a kernel panic or trap
loop due to the setup and handling of the queued traps once in the kernel.
This patch series addresses both of these issues.
The queues are fixed by simply zeroing the memory before use.
PIO errors from userspace will result in a SIGBUS being sent to the user
process.
The MEM errors form userspace will result in a SIGKILL and also cause the
offending pages to be claimed so they are no longer used in future tasks.
SIGKILL is used to ensure that the process does not try to coredump and result
in an attempt to read the memory again from within kernel space. Although
there is a HV call to scrub the memory (mem_scrub), there is no easy way to
guarantee that the real memory address(es) are not used by other tasks.
Clearing the error with mem_scrub would zero the memory and cause the other
processes to proceed with bad data.
The handling of other non-resumable errors remain unchanged and will cause a
panic.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
User processes trying to access an invalid memory address via PIO will
receive a SIGBUS signal instead of causing a panic. Memory errors will
receive a SIGKILL since a SIGBUS may result in a coredump which may
attempt to repeat the faulting access.
Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Error queues use a non-zero first word to detect if the queues are full.
Using pages that have not been zeroed may result in false positive
overflow events. These queues are set up once during boot so zeroing
all mondo and error queue pages is safe.
Note that the false positive overflow does not always occur because the
page allocation for these queues is so early in the boot cycle that
higher number CPUs get fresh pages. It is only when traps are serviced
with lower number CPUs who were given already used pages that this issue
is exposed.
Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When matching on the ICMPv6 code ICMPV6_CODE rather than
ICMPV4_CODE attributes should be used.
This corrects what appears to be a typo.
Sample usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ipv6 parent ffff: flower \
indev eth0 ip_proto icmpv6 type 128 code 0 action drop
Without this change the code parameter above is effectively ignored.
Fixes: 7b684884fb ("net/sched: cls_flower: Support matching on ICMP type and code")
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEES2FAuYbJvAGobdVQPTuqJaypJWoFAliPEGcTHG1rbEBwZW5n
dXRyb25peC5kZQAKCRA9O6olrKklakWHB/971KHqyYL5Rhbo8rOl+XKIpTLSFCJi
tgaN1mOUaBl2UIlevzW/9kNP7DkT+0axaEdFwsfZCm3opLwCaYI9TtxbDLmMx8VW
p7/djLDDcE9hgH1J6PnHL6w+Mlnr6NcdmVlU7lm8YyiCcALQp6EdYXVh1T1/xD0+
ytoqO2A8pgvR1VfcD7Q4M3qE0L9JQRrFhDenStn8fql6fpb2RqFT2iogQF6hta1Y
YNZx0pK24gpCDTWqR06BBuHHDLpS6nGmnMl5Qvft1FBmSsvKpp4qAMN2IVyYA402
SdEHJHlo9SmqNZmQg2QQg5Hn0KJ4iY7PxLJGc2yPvZowa9ewBRRW2xYG
=CiTr
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-4.10-20170130' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2017-01-30
this is a pull request of one patch.
The patch is by Oliver Hartkopp and fixes the hrtimer/tasklet termination in
bcm op removal.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
- Allow jz4740 to build as a module again by using kernel_halt()
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEl0I5XWmUIrwBfFMm2KKDO9oT4sIFAliPmqgACgkQ2KKDO9oT
4sLIIA/+ORkxQ7JbnNM0kwhsL+MUP46CkE7GrgoEGubS/LghKqZhyf2WNXaqJ48J
tT+Hzn1NhycBrjlhzJ0GEAcq9aWPDJe/56/ZPWABgH4Gfx64Ea1bfhVRgMzBXoTd
7KE2IkZNCSvaE6UGnurderl6qsJH80HK1AiYz0ZN0xNR/7rxjB2O4VoYNl3rBqhB
HQG5p6izvBDbhawmyDJcDi7MI3ylKI/ok8NIdXPBv0+DQ0gtBYmrM7JwS8RnbmWZ
LFtJQE9+M2P58LiEJOv4Ij9jgMt2LiYkDcX/U29Hraeqp14TSPiYbLRUs29WyBRY
jOmeM9n8FBxxdA4wqN3MAc32EMoHs642lWeDNVfLXiBuXVFAnuKQBagpDY0FDJyx
ndaG0F6xCTvkQrAbKOtIM0b4kYX0Cdh4OrPstsef0B4WxUUTKWko7dE673GTSqfS
3aQaXXLkcKY1TNNDtvmCTqvCE+rITwb1nRfQEyDvUnDsgjF2YXxPrAa78qq8qyBy
15w3Dc23WOglVdV5zfqskeEGWaXVZpZx9zcPBy2Ezj5/KfhE+UNs5ZzPBIzBrQqx
Sfuwpq6RJcJUP8Rj16869vK1b7C8oKbAX3QYSu6zUncX43n+TC+Vbz6bWrK+ckrM
2pb6GReyDg66Ztr7N0FqRI9aawmj1wn0s6V/oPx0ukV+iqyCCOY=
=dHxL
-----END PGP SIGNATURE-----
Merge tag 'rtc-4.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC fix from Alexandre Belloni:
"A single fix for this cycle. It is worth taking it for 4.10 so that
distributions will not have CONFIG_RTC_DRV_JZ4740 switching from m to
y in their config.
Summary:
- Allow jz4740 to build as a module again by using kernel_halt()"
* tag 'rtc-4.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
rtc: jz4740: make the driver buildable as a module again
IPv6 will mark data that is smaller that mtu - headersize as
CHECKSUM_PARTIAL, but if the data will completely fill the mtu,
the packet checksum will be computed in software instead.
Extend the conditional to include the data that fills the mtu
as well.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some Hypervisors detach VFs from VMs by instantly causing an FLR event
to be generated for a VF.
In the mlx4 case, this will cause that VF's comm channel to be disabled
before the VM has an opportunity to invoke the VF device's "shutdown"
method.
The result is that the VF driver on the VM will experience a command
timeout during the shutdown process when the Hypervisor does not deliver
a command-completion event to the VM.
To avoid FW command timeouts on the VM when the driver's shutdown method
is invoked, we detect the absence of the VF's comm channel at the very
start of the shutdown process. If the comm-channel has already been
disabled, we cause all FW commands during the device shutdown process to
immediately return success (and thus avoid all command timeouts).
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A couple of mlx5 core and ethernet driver fixes.
From Or, A couple of error return values and error handling fixes.
From Hadar, Support TC encapsulation offloads even when the mlx5e uplink
device is stacked under an upper device.
From Gal, Two patches to fix RSS hash modifications via ethtool.
From Moshe, Added a needed ets capability check.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYjmAjAAoJEEg/ir3gV/o+oMUH+QF2kdg9//kvkwWGv7FR4fBT
6oFH9vsIpG+kGDlXGVX8wekcUCssNx/eZ7IrOrEfBnGsbuXntIjiUfT2RxasBU0Q
K8/1szQbjbdrOiT+lB2NOyxk4fr+GNYT+k0srNS36Qr6i5sMiLDvNo1ivu7RtK+2
KRsg8ClPWalc/lxxQJSDVpyQeI6S68jYveK8H5xNR8i7UeFFcgYv313BaobL+Nbn
PSvLHSeJQX2Uqo1Whg12/xQgP6Q8s9OTRMI+30Gcsv1YaC2ET6dTqWPg5x+Yl1+P
vRcCzvjQf6oD+zhmCZJBS9CchI6gFf1x03cfxIjFwfzioBBM7ux8szjIyTW9tHY=
=bqC6
-----END PGP SIGNATURE-----
Merge tag 'mlx5-fixes-2017-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-fixes-2017-01-27
A couple of mlx5 core and ethernet driver fixes.
From Or, A couple of error return values and error handling fixes.
From Hadar, Support TC encapsulation offloads even when the mlx5e uplink
device is stacked under an upper device.
From Gal, Two patches to fix RSS hash modifications via ethtool.
From Moshe, Added a needed ets capability check.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Most important here are fixes to two iwlwifi crashes, but there's also
a firmware naming fix for iwlwifi and a revert of an older bcma patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYjf7cAAoJEG4XJFUm622bNQUH/2bdxU1PBaZY/CjTOOla4/Ll
P3zEc7vz1UCDx0ML2FCFhoZdXstqg8qtPuYsY/iC6a6GhHijy6o2jcEku8GwCdBl
qdWVPl8DAiAGq7aeaMz1TGbnp4XvODIhBwa3xXzewJ/xBYtoFpQRSOkj6k0TqS04
CE3cTcEijt6JEhHit3EVGSvO9+NTjtAoHMVU3LfrZiW72G0q/LrzAvREx6XXKMlA
08Y+XTGin8ZW25QWnWypyuzomBChFcnnAUP2ONr3nRqAz14IT50aKtTJkCPhLxuZ
i890uWSdTFjYKWJYwut8p0mHa5j+DWAr9pm9xrHMsgorXtdtfpYdXhLYQqkp2Yw=
=7lre
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2017-01-29' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for 4.10
Most important here are fixes to two iwlwifi crashes, but there's also
a firmware naming fix for iwlwifi and a revert of an older bcma patch.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
In spite of switching to paged allocation of Rx buffers, the driver still
called dma_unmap_single() in the Rx queues tear-down path.
The DMA region unmapping code in free_skb_rx_queue() basically predates
the introduction of paged allocation to the driver. While being refactored,
it apparently hasn't reflected the change in the DMA API usage by its
counterpart gfar_new_page().
As a result, setting an interface to the DOWN state now yields the following:
# ip link set eth2 down
fsl-gianfar ffe24000.ethernet: DMA-API: device driver frees DMA memory with wrong function [device address=0x000000001ecd0000] [size=40]
------------[ cut here ]------------
WARNING: CPU: 1 PID: 189 at lib/dma-debug.c:1123 check_unmap+0x8e0/0xa28
CPU: 1 PID: 189 Comm: ip Tainted: G O 4.9.5 #1
task: dee73400 task.stack: dede2000
NIP: c02101e8 LR: c02101e8 CTR: c0260d74
REGS: dede3bb0 TRAP: 0700 Tainted: G O (4.9.5)
MSR: 00021000 <CE,ME> CR: 28002222 XER: 00000000
GPR00: c02101e8 dede3c60 dee73400 000000b6 dfbd033c dfbd36c4 1f622000 dede2000
GPR08: 00000007 c05b1634 1f622000 00000000 22002484 100a9904 00000000 00000000
GPR16: 00000000 db4c849c 00000002 db4c8480 00000001 df142240 db4c84bc 00000000
GPR24: c0706148 c0700000 00029000 c07552e8 c07323b4 dede3cb8 c07605e0 db535540
NIP [c02101e8] check_unmap+0x8e0/0xa28
LR [c02101e8] check_unmap+0x8e0/0xa28
Call Trace:
[dede3c60] [c02101e8] check_unmap+0x8e0/0xa28 (unreliable)
[dede3cb0] [c02103b8] debug_dma_unmap_page+0x88/0x9c
[dede3d30] [c02dffbc] free_skb_resources+0x2c4/0x404
[dede3d80] [c02e39b4] gfar_close+0x24/0xc8
[dede3da0] [c0361550] __dev_close_many+0xa0/0xf8
[dede3dd0] [c03616f0] __dev_close+0x2c/0x4c
[dede3df0] [c036b1b8] __dev_change_flags+0xa0/0x174
[dede3e10] [c036b2ac] dev_change_flags+0x20/0x60
[dede3e30] [c03e130c] devinet_ioctl+0x540/0x824
[dede3e90] [c0347dcc] sock_ioctl+0x134/0x298
[dede3eb0] [c0111814] do_vfs_ioctl+0xac/0x854
[dede3f20] [c0111ffc] SyS_ioctl+0x40/0x74
[dede3f40] [c000f290] ret_from_syscall+0x0/0x3c
--- interrupt: c01 at 0xff45da0
LR = 0xff45cd0
Instruction dump:
811d001c 7c66482e 813d0020 9061000c 807f000c 5463103a 7cc6182e 3c60c052
386309ac 90c10008 4cc63182 4826b845 <0fe00000> 4bfffa60 3c80c052 388402c4
---[ end trace 695ae6d7ac1d0c47 ]---
Mapped at:
[<c02e22a8>] gfar_alloc_rx_buffs+0x178/0x248
[<c02e3ef0>] startup_gfar+0x368/0x570
[<c036aeb4>] __dev_open+0xdc/0x150
[<c036b1b8>] __dev_change_flags+0xa0/0x174
[<c036b2ac>] dev_change_flags+0x20/0x60
Even though the issue was discovered in 4.9 kernel, the code in question
is identical in the current net and net-next trees.
Fixes: 75354148ce ("gianfar: Add paged allocation and Rx S/G")
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch introduce support for 2500BaseT and 5000BaseT link modes.
These modes are included in the new IEEE 802.3bz standard.
Signed-off-by: Pavel Belous <pavel.s.belous@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
According to VLI64 Intel Atom E3800 Specification Update (#329901)
concurrent read accesses may result in returning 0xffffffff and write
accesses may be dropped silently.
To workaround all accesses must be protected by locks.
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Debounce value is set globally per community. Otherwise user will easily
get a kernel crash when they start using the feature:
BUG: unable to handle kernel paging request at ffffc900003be000
IP: byt_gpio_dbg_show+0xa9/0x430
Make it clear in byt_gpio_reg().
Note that this fix just prevents kernel to crash, but doesn't make any
difference to the existing logic. It means the last caller will win the
trade and debounce value will be configured accordingly. The actual
logic fix needs to be thought about and it's not as important as crash
fix. That's why the latter goes separately and right now.
Fixes: 658b476c74 ("pinctrl: baytrail: Add debounce configuration")
Cc: Cristina Ciocan <cristina.ciocan@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The commit 04ff5a095d ("pinctrl: baytrail: Rectify debounce support")
almost fixes the logic of debuonce but missed couple of things, i.e.
typo in mask when disabling debounce and lack of enabling it back.
This patch addresses above issues.
Reported-by: Jean Delvare <jdelvare@suse.de>
Fixes: 04ff5a095d ("pinctrl: baytrail: Rectify debounce support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit f3b0946d62 ("genirq/msi: Make sure PCI MSIs are
activated early"), we can end-up activating a PCI/MSI twice (once
at allocation time, and once at startup time).
This is normally of no consequences, except that there is some
HW out there that may misbehave if activate is used more than once
(the GICv3 ITS, for example, uses the activate callback
to issue the MAPVI command, and the architecture spec says that
"If there is an existing mapping for the EventID-DeviceID
combination, behavior is UNPREDICTABLE").
While this could be worked around in each individual driver, it may
make more sense to tackle the issue at the core level. In order to
avoid getting in that situation, let's have a per-interrupt flag
to remember if we have already activated that interrupt or not.
Fixes: f3b0946d62 ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-and-tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1484668848-24361-1-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Andres reported that MMAP2 records for anonymous memory always have
their protection field 0.
Turns out, someone daft put the prot/flags generation code in the file
branch, leaving them unset for anonymous memory.
Reported-by: Andres Freund <andres@anarazel.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Don Zickus <dzickus@redhat.com
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@kernel.org
Cc: anton@ozlabs.org
Cc: namhyung@kernel.org
Cc: stable@vger.kernel.org # v3.16+
Fixes: f972eb63b1 ("perf: Pass protection and flags bits through mmap2 interface")
Link: http://lkml.kernel.org/r/20170126221508.GF6536@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Dmitry reported a KASAN use-after-free on event->group_leader.
It turns out there's a hole in perf_remove_from_context() due to
event_function_call() not calling its function when the task
associated with the event is already dead.
In this case the event will have been detached from the task, but the
grouping will have been retained, such that group operations might
still work properly while there are live child events etc.
This does however mean that we can miss a perf_group_detach() call
when the group decomposes, this in turn can then lead to
use-after-free.
Fix it by explicitly doing the group detach if its still required.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # v4.5+
Cc: syzkaller <syzkaller@googlegroups.com>
Fixes: 63b6da39bb ("perf: Fix perf_event_exit_task() race")
Link: http://lkml.kernel.org/r/20170126153955.GD6515@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When removing a bcm tx operation either a hrtimer or a tasklet might run.
As the hrtimer triggers its associated tasklet and vice versa we need to
take care to mutually terminate both handlers.
Reported-by: Michael Josenhans <michael.josenhans@web.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Michael Josenhans <michael.josenhans@web.de>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
I was under the misconception that the sysfs dev stuff can be fully
set up, and then registered all in one step with device_add. That's
true for properties and property groups, but not for parents and child
devices. Those must be fully registered before you can register a
child.
Add a bit of tracking to make sure that asynchronous mst connector
hotplugging gets this right. For consistency we rely upon the implicit
barriers of the connector->mutex, which is taken anyway, to ensure
that at least either the connector or device registration call will
work out.
Mildly tested since I can't reliably reproduce this on my mst box
here.
Reported-by: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484237756-2720-1-git-send-email-daniel.vetter@ffwll.ch
If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.
v2: Also update the kerneldoc for @registered!
v3: Review from Chris:
- Improve kerneldoc for late_register/early_unregister callbacks.
- Use mutex_destroy.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218133545.2106-1-daniel.vetter@ffwll.ch
(cherry picked from commit e73ab00e9a)
Not every pin can be configured. Add missed check to prevent access
violation.
Fixes: 4e80c8f505 ("pinctrl: intel: Add Intel Merrifield pin controller support")
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 07fe64ba21 ("pinctrl: sunxi: Handle bias disable") actually
enforced enforced the disabling of the pull up/down resistors instead of
ignoring it like it was done before.
This was part of a wider rework to switch to the generic pinconf bindings,
and was meant to be merged together with DT patches that were switching to
it, and removing what was considered default values by both the binding and
the boards. This included no bias on a pin.
However, those DT patches were delayed to 4.11, which would be fine only
for a significant number boards having the bias setup wrong, which in turns
break the MMC on those boards (and possibly other devices too).
In order to avoid conflicts as much as possible, bring back the old
behaviour for 4.10, and we'll revert that commit once all the DT bits will
have landed.
Tested-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When setting a 2MB pte, radix__map_kernel_page() is using the address
ptep = (pte_t *)pudp;
Fix this conversion to use pmdp instead. Use pmdp_ptep() to do this
instead of casting the pointer.
Fixes: 2bfd65e45e ("powerpc/mm/radix: Add radix callbacks for early init routines")
Cc: stable@vger.kernel.org # v4.7+
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
init_ring(), refill_rx_ring() and start_tx() don't check
if mapping dma memory succeed.
The patch adds the checks and failure handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
As pr commit "net: phy: phy drivers should not set SUPPORTED_[Asym_]Pause"
this phy driver should not set these feature bits.
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Fixes: 9d162ed69f ("net: phy: micrel: add support for KSZ8795")
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Zhang Yanmin reported crashes [1] and provided a patch adding a
synchronize_rcu() call in can_rx_unregister()
The main problem seems that the sockets themselves are not RCU
protected.
If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.
Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
ease stable backports with the following fix instead.
[1]
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81495e25>] selinux_socket_sock_rcv_skb+0x65/0x2a0
Call Trace:
<IRQ>
[<ffffffff81485d8c>] security_sock_rcv_skb+0x4c/0x60
[<ffffffff81d55771>] sk_filter+0x41/0x210
[<ffffffff81d12913>] sock_queue_rcv_skb+0x53/0x3a0
[<ffffffff81f0a2b3>] raw_rcv+0x2a3/0x3c0
[<ffffffff81f06eab>] can_rcv_filter+0x12b/0x370
[<ffffffff81f07af9>] can_receive+0xd9/0x120
[<ffffffff81f07beb>] can_rcv+0xab/0x100
[<ffffffff81d362ac>] __netif_receive_skb_core+0xd8c/0x11f0
[<ffffffff81d36734>] __netif_receive_skb+0x24/0xb0
[<ffffffff81d37f67>] process_backlog+0x127/0x280
[<ffffffff81d36f7b>] net_rx_action+0x33b/0x4f0
[<ffffffff810c88d4>] __do_softirq+0x184/0x440
[<ffffffff81f9e86c>] do_softirq_own_stack+0x1c/0x30
<EOI>
[<ffffffff810c76fb>] do_softirq.part.18+0x3b/0x40
[<ffffffff810c8bed>] do_softirq+0x1d/0x20
[<ffffffff81d30085>] netif_rx_ni+0xe5/0x110
[<ffffffff8199cc87>] slcan_receive_buf+0x507/0x520
[<ffffffff8167ef7c>] flush_to_ldisc+0x21c/0x230
[<ffffffff810e3baf>] process_one_work+0x24f/0x670
[<ffffffff810e44ed>] worker_thread+0x9d/0x6f0
[<ffffffff810e4450>] ? rescuer_thread+0x480/0x480
[<ffffffff810ebafc>] kthread+0x12c/0x150
[<ffffffff81f9ccef>] ret_from_fork+0x3f/0x70
Reported-by: Zhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support for 32 bit GEM in
64 bit system. It checks capability at runtime
and uses appropriate buffer descriptor.
Signed-off-by: Rafal Ozieblo <rafalo@cadence.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
DW GMAC databook says the following about bits in "Register 15 (Interrupt
Mask Register)":
--------------------------->8-------------------------
When set, this bit __disables_the_assertion_of_the_interrupt_signal__
because of the setting of XXX bit in Register 14 (Interrupt
Status Register).
--------------------------->8-------------------------
In fact even if we mask one bit in the mask register it doesn't prevent
corresponding bit to appear in the status register, it only disables
interrupt generation for corresponding event.
But currently we expect a bit different behavior: status bits to be in
sync with their masks, i.e. if mask for bit A is set in the mask
register then bit A won't appear in the interrupt status register.
This was proven to be incorrect assumption, see discussion here [1].
That misunderstanding causes unexpected behaviour of the GMAC, for
example we were happy enough to just see bogus messages about link
state changes.
So from now on we'll be only checking bits that really may trigger an
interrupt.
[1] https://lkml.org/lkml/2016/11/3/413
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Cc: Phil Reid <preid@electromag.com.au>
Cc: David Miller <davem@davemloft.net>
Cc: Alexandre Torgue <alexandre.torgue@gmail.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I've seen this trigger twice now, where the i915_gem_object_to_ggtt()
call in intel_unpin_fb_obj() returns NULL, resulting in an oops
immediately afterwards as the (inlined) call to i915_vma_unpin_fence()
tries to dereference it.
It seems to be some race condition where the object is going away at
shutdown time, since both times happened when shutting down the X
server. The call chains were different:
- VT ioctl(KDSETMODE, KD_TEXT):
intel_cleanup_plane_fb+0x5b/0xa0 [i915]
drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper]
intel_atomic_commit_tail+0x749/0xfe0 [i915]
intel_atomic_commit+0x3cb/0x4f0 [i915]
drm_atomic_commit+0x4b/0x50 [drm]
restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper]
drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
intel_fbdev_set_par+0x18/0x70 [i915]
fb_set_var+0x236/0x460
fbcon_blank+0x30f/0x350
do_unblank_screen+0xd2/0x1a0
vt_ioctl+0x507/0x12a0
tty_ioctl+0x355/0xc30
do_vfs_ioctl+0xa3/0x5e0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x13/0x94
- i915 unpin_work workqueue:
intel_unpin_work_fn+0x58/0x140 [i915]
process_one_work+0x1f1/0x480
worker_thread+0x48/0x4d0
kthread+0x101/0x140
and this patch purely papers over the issue by adding a NULL pointer
check and a WARN_ON_ONCE() to avoid the oops that would then generally
make the machine unresponsive.
Other callers of i915_gem_object_to_ggtt() seem to also check for the
returned pointer being NULL and warn about it, so this clearly has
happened before in other places.
[ Reported it originally to the i915 developers on Jan 8, applying the
ugly workaround on my own now after triggering the problem for the
second time with no feedback.
This is likely to be the same bug reported as
https://bugs.freedesktop.org/show_bug.cgi?id=98829https://bugs.freedesktop.org/show_bug.cgi?id=99134
which has a patch for the underlying problem, but it hasn't gotten to
me, so I'm applying the workaround. ]
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On dcbnl callback getpgtccfgtx, the driver should check the ets
capability before ets query command is sent to firmware.
It is valid to return from this void function without changing in/out
parameters, as these parameters are initialized to
DCB_ATTR_VALUE_UNDEFINED.
Fixes: 3a6a931dfb ("net/mlx5e: Support DCBX CEE API")
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Modifying TIR hash should change selected fields bitmask in addition to
the function and key.
Formerly, Only on ethool mlx5e_set_rxfh "ethtoo -X" we would not set this
field resulting in zeroing of its value, which means no packet fields are
used for RX RSS hash calculation thus causing all traffic to arrive in
RQ[0].
On driver load out of the box we don't have this issue, since the TIR
hash is fully created from scratch.
Tested:
ethtool -X ethX hkey <new key>
ethtool -X ethX hfunc <new func>
ethtool -X ethX equal <new indirection table>
All cases are verified with TCP Multi-Stream traffic over IPv4 & IPv6.
Fixes: bdfc028de1 ("net/mlx5e: Fix ethtool RX hash func configuration change")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
We don't need to modify our TIRs unless the user requested a change in
the hash function/key, for example when changing indirection only.
Tested:
# Modify TIRs hash is needed
ethtool -X ethX hkey <new key>
ethtool -X ethX hfunc <new func>
# Modify TIRs hash is not needed
ethtool -X ethX equal <new indirection table>
All cases are verified with TCP Multi-Stream traffic over IPv4 & IPv6.
Fixes: bdfc028de1 ("net/mlx5e: Fix ethtool RX hash func configuration change")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
When tunneling is used, some virtualizations systems set the (mlx5e) uplink
device to be stacked under upper devices such as bridge or ovs internal
port, where the VTEP IP address used for the encapsulation is set on
that upper device.
In order to support such use-cases, we also deal with a setup where the
egress mirred device isn't representing a port on the HW e-switch to where
the ingress device belongs. We use eswitch service function which returns
the uplink and set it as the egress device of the tc encap rule.
Fixes: a54e20b4fc ("net/mlx5e: Add basic TC tunnel set action for SRIOV offloads")
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
We must re-enable RoCE on the e-switch management port (PF) only after destroying
the FDB in its switchdev/offloaded mode. Otherwise, when encapsulation is supported,
this re-enablement will fail.
Also, it's more natural and symmetric to disable RoCE on the PF before we create
the FDB under switchdev mode, so do that as well and revert if getting into error
during the mode change later.
Fixes: 9da34cd34e ('net/mlx5: Disable RoCE on the e-switch management [..]')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Make sure to return error when we failed retrieving the FDB steering
name space. Also, while around, correctly print the error when mode
change revert fails in the warning message.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reported-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
When we fail to retrieve a hardware steering name-space, the returned error
code should say that this operation is not supported. Align the various
places in the driver where this call is made to this convention.
Also, make sure to warn when we fail to retrieve a SW (ANCHOR) name-space.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
As ENOTSUPP is specific to NFS, change the return error value to
EOPNOTSUPP in various places in the mlx5 driver.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Suggested-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Pull two parisc fixes from Helge Deller:
"One fix to avoid usage of BITS_PER_LONG in user-space exported swab.h
header which breaks compiling qemu, and one trivial fix for printk
continuation in the parisc parport driver"
* 'parisc-4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Don't use BITS_PER_LONG in userspace-exported swab.h header
parisc, parport_gsc: Fixes for printk continuation lines
