aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-11-01MAINTAINERS: Remove Yotam from mlxfwYuval Mintz1-1/+1
Provide a mailing list for maintenance of the module instead. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01MAINTAINERS: Update Yotam's E-mailYotam Gigi4-5/+5
For the time being I will be available in my private mail. Update both the MAINTAINERS file and the individual modules MODULE_AUTHOR directive with the new address. Signed-off-by: Yotam Gigi <[email protected]> Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01net: hns: set correct return valuePan Bian1-2/+2
The function of_parse_phandle() returns a NULL pointer if it cannot resolve a phandle property to a device_node pointer. In function hns_nic_dev_probe(), its return value is passed to PTR_ERR to extract the error code. However, in this case, the extracted error code will always be zero, which is unexpected. Signed-off-by: Pan Bian <[email protected]> Reviewed-by: Tobias Klauser <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01net: lapbether: fix double freePan Bian1-1/+0
The function netdev_priv() returns the private data of the device. The memory to store the private data is allocated in alloc_netdev() and is released in netdev_free(). Calling kfree() on the return value of netdev_priv() after netdev_free() results in a double free bug. Signed-off-by: Pan Bian <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01bpf: remove SK_REDIRECT from UAPIJohn Fastabend3-7/+13
Now that SK_REDIRECT is no longer a valid return code. Remove it from the UAPI completely. Then do a namespace remapping internal to sockmap so SK_REDIRECT is no longer externally visible. Patchs primary change is to do a namechange from SK_REDIRECT to __SK_REDIRECT Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: John Fastabend <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01net: phy: marvell: Only configure RGMII delays when using RGMIIAndrew Lunn1-3/+5
The fix 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo") uncovered another bug in the Marvell PHY driver, which broke the Marvell OpenRD platform. It relies on the bootloader configuring the RGMII delays and does not specify a phy-mode in its device tree. The PHY driver should only configure RGMII delays if the phy mode indicates it is using RGMII. Without anything in device tree, the mv643xx Ethernet driver defaults to GMII. Fixes: 5987feb38aa5 ("net: phy: marvell: logical vs bitwise OR typo") Signed-off-by: Andrew Lunn <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01Merge tag 'wireless-drivers-for-davem-2017-10-31' of ↵David S. Miller3-28/+98
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.14 The most important here is the security vulnerabitility fix for ath10k. ath10k * fix security vulnerability with missing PN check on certain hardware * revert ath10k napi fix as it caused regressions on QCA6174 wcn36xx * remove unnecessary rcu_read_unlock() from error path ==================== Signed-off-by: David S. Miller <[email protected]>
2017-11-01MIPS: SMP: Fix deadlock & online raceMatt Redfearn1-6/+16
Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online") and thus has reinstated the possibility of deadlock. The commit was based on testing of kernel v4.4, where the CPU hotplug core code issued a BUG() if the starting CPU is not marked online when the boot CPU returns from __cpu_up. The commit fixes this race (in v4.4), but re-introduces the deadlock situation. As noted in the commit message, upstream differs in this area. Commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up") adds a completion event in the CPU hotplug core code, making this race impossible. However, people were unhappy with relying on the core code to do the right thing. To address the issues both commits were trying to fix, add a second completion event in the MIPS smp hotplug path. It removes the possibility of a race, since the MIPS smp hotplug code now synchronises both the boot and secondary CPUs before they return to the hotplug core code. It also addresses the deadlock by ensuring that the secondary CPU is not marked online before it's counters are synchronised. This fix should also be backported to fix the race condition introduced by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"), through really that race only existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up"). Signed-off-by: Matt Redfearn <[email protected]> Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") CC: Matija Glavinic Pecotic <[email protected]> Cc: <[email protected]> # v4.1+: 8f46cca1e6c0: "MIPS: SMP: Fix possibility of deadlock when bringing CPUs online" Cc: <[email protected]> # v4.1+: a00eeede507c: "MIPS: SMP: Use a completion event to signal CPU up" Cc: <[email protected]> # v4.1+: 6f542ebeaee0: "MIPS: Fix race on setting and getting cpu_online_mask" Cc: <[email protected]> # v4.1+ Patchwork: https://patchwork.linux-mips.org/patch/17376/ Signed-off-by: James Hogan <[email protected]>
2017-11-01MIPS: bpf: Fix a typo in build_one_insn()Wei Yongjun1-1/+1
Fix a typo in build_one_insn(). Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.") Signed-off-by: Wei Yongjun <[email protected]> Cc: <[email protected]> # 4.13+ Patchwork: https://patchwork.linux-mips.org/patch/17491/ Signed-off-by: James Hogan <[email protected]>
2017-11-01MIPS: microMIPS: Fix incorrect mask in insn_table_MMGustavo A. R. Silva1-1/+1
It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS". This issue was detected with the help of Coccinelle. Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction") Reported-by: Julia Lawall <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: James Hogan <[email protected]> Cc: <[email protected]> # 3.16+ Patchwork: https://patchwork.linux-mips.org/patch/17551/ Signed-off-by: James Hogan <[email protected]>
2017-11-01Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-fixesDave Airlie1-3/+3
single nouveau regression fix. * 'linux-4.14' of git://github.com/skeggsb/linux: drm/nouveau/kms/nv50: use the correct state for base channel notifier setup
2017-10-31MIPS: Fix CM region target definitionsPaul Burton1-2/+2
The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Fixes: 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") Signed-off-by: Paul Burton <[email protected]> Reported-by: Matt Redfearn <[email protected]> Reviewed-by: James Hogan <[email protected]> Cc: Matt Redfearn <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: [email protected] Cc: <[email protected]> # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17562/ Signed-off-by: James Hogan <[email protected]>
2017-10-31MIPS: generic: Fix compilation error from include asm/mips-cpc.hMatt Redfearn2-2/+2
Commit e83f7e02af50c ("MIPS: CPS: Have asm/mips-cps.h include CM & CPC headers") adds a #error to arch/mips/include/asm/mips-cpc.h if it is included directly. While this commit replaced almost all direct includes of mips-cm.h and mips-cpc.h, 2 remain. With some defconfigs, mips-cps.h is indirectly included before mips-cpc.h, but in others this results in compilation errors: In file included from arch/mips/generic/init.c:23:0: ./arch/mips/include/asm/mips-cpc.h:12:3: error: #error Please include asm/mips-cps.h rather than asm/mips-cpc.h # error Please include asm/mips-cps.h rather than asm/mips-cpc.h In file included from arch/mips/kernel/smp.c:23:0: ./arch/mips/include/asm/mips-cpc.h:12:3: error: #error Please include asm/mips-cps.h rather than asm/mips-cpc.h # error Please include asm/mips-cps.h rather than asm/mips-cpc.h In both cases, fix this by including mips-cps.h instead. Fixes: e83f7e02af50c ("MIPS: CPS: Have asm/mips-cps.h include CM & CPC headers") Signed-off-by: Matt Redfearn <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/17492/ Signed-off-by: James Hogan <[email protected]>
2017-10-31MIPS: Fix exception entry when CONFIG_EVA enabledMatt Redfearn1-4/+4
Commit 9fef68686317b ("MIPS: Make SAVE_SOME more standard") made several changes to the order in which registers are saved in the SAVE_SOME macro, used by exception handlers to save the processor state. In particular, it removed the move k1, sp in the delay slot of the branch testing if the processor is already in kernel mode. This is replaced later in the macro by a move k0, sp When CONFIG_EVA is disabled, this instruction actually appears in the delay slot of the branch. However, when CONFIG_EVA is enabled, instead the RPS workaround of MFC0 k0, CP0_ENTRYHI appears in the delay slot. This results in k0 not containing the stack pointer, but some unrelated value, which is then saved to the kernel stack. On exit from the exception, this bogus value is restored to the stack pointer, resulting in an OOPS. Fix this by moving the save of SP in k0 explicitly in the delay slot of the branch, outside of the CONFIG_EVA section, restoring the expected instruction ordering when CONFIG_EVA is active. Fixes: 9fef68686317b ("MIPS: Make SAVE_SOME more standard") Signed-off-by: Matt Redfearn <[email protected]> Reported-by: Vladimir Kondratiev <[email protected]> Reviewed-by: Corey Minyard <[email protected]> Reviewed-by: James Hogan <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/17471/ Signed-off-by: James Hogan <[email protected]>
2017-11-01irqchip/irq-mvebu-gicp: Add missing spin_lock initAntoine Tenart1-0/+1
A spin lock is used in the irq-mvebu-gicp driver, but it is never initialized. This patch adds the missing spin_lock_init() call in the driver's probe function. Fixes: a68a63cb4dfc ("irqchip/irq-mvebu-gicp: Add new driver for Marvell GICP") Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: [email protected] Acked-by: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2017-11-01drm/nouveau/kms/nv50: use the correct state for base channel notifier setupBen Skeggs1-3/+3
Fixes: 857263 ("drm/nouveau: Handle drm_atomic_helper_swap_state failure") Signed-off-by: Ben Skeggs <[email protected]> Tested-by: Lyude Paul <[email protected]> Reviewed by: Lyude Paul <[email protected]>
2017-10-31MIPS: generic: Fix NI 169445 its buildJames Hogan1-1/+1
Since commit 04a85e087ad6 ("MIPS: generic: Move NI 169445 FIT image source to its own file"), a generic 32r2el_defconfig kernel fails to build with the following build error: ITB arch/mips/boot/vmlinux.gz.itb Error: arch/mips/boot/vmlinux.gz.its:111.1-2 syntax error FATAL ERROR: Unable to parse input tree mkimage Can't read arch/mips/boot/vmlinux.gz.itb.tmp: Invalid argument Fix arch/mips/generic/board-ni169445.its.S to include the necessary "/" node path before the first open brace. The original issue in arch/mips/generic/vmlinux.its.S was fixed directly in the original commit 7aacf86b75bc ("MIPS: NI 169445 board support") after https://patchwork.linux-mips.org/patch/16941/ was submitted, but the separate its.S file wasn't correctly fixed when resolving the conflict in commit 04a85e087ad6 ("MIPS: generic: Move NI 169445 FIT image source to its own file"). Fixes: 04a85e087ad6 ("MIPS: generic: Move NI 169445 FIT image source to its own file") Signed-off-by: James Hogan <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Paul Burton <[email protected]> Cc: Nathan Sullivan <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/17561/ Signed-off-by: James Hogan <[email protected]>
2017-10-31Merge tag 'pm-reverts-4.14' of ↵Linus Torvalds8-65/+36
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management commit reverts from Rafael Wysocki: "Since Geert reports additional problems with my PM QoS fix from the last week that have not been addressed by the most recent fixup on top of it, they both should better be reverted now and let's fix the original issue properly in 4.15. This reverts two recent PM QoS commits one of which introduced multiple problems and the other one fixed some, but not all of them (Rafael Wysocki)" * tag 'pm-reverts-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "PM / QoS: Fix device resume latency PM QoS" Revert "PM / QoS: Fix default runtime_pm device resume latency"
2017-10-31Update MIPS email addressesPaul Burton46-49/+52
MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those who: - Have 10 or more patches in mainline authored using an @imgtec.com email address, or any patches dated within the past year. - Are still with Imagination but leaving as part of the MIPS business unit, as determined from an internal email address list. - Haven't already updated their email address (ie. JamesH) or expressed a desire to be excluded (ie. Maciej). - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt & myself. New addresses are of the form [email protected], and all verified against an internal email address list. An entry is added to .mailmap for each person such that get_maintainer.pl will report the new addresses rather than @imgtec.com addresses which will soon be dead. Instances of the affected addresses throughout the tree are then mechanically replaced with the new @mips.com address. Signed-off-by: Paul Burton <[email protected]> Cc: Deng-Cheng Zhu <[email protected]> Cc: Deng-Cheng Zhu <[email protected]> Acked-by: Dengcheng Zhu <[email protected]> Cc: Matt Redfearn <[email protected]> Cc: Matt Redfearn <[email protected]> Acked-by: Matt Redfearn <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/17540/ Signed-off-by: James Hogan <[email protected]>
2017-10-31tile: pass machine size to sparseLuc Van Oostenryck1-0/+2
By default, sparse assumes a 64bit machine when compiled on x86-64 and 32bit when compiled on anything else. This can of course create all sort of problems, like issuing false warnings like: 'constant ... is so big it is unsigned long long' or 'shift too big (32) for type unsigned long' when the architecture is 64bit while sparse was compiled on a 32bit machine, or worse, to not emit legitimate warnings in the reverse situation. Fix this by passing to sparse the appropriate -m32/-m64 flag. To: Chris Metcalf <[email protected]> Signed-off-by: Luc Van Oostenryck <[email protected]> Signed-off-by: Chris Metcalf <[email protected]>
2017-10-31selftests: lib.mk: print individual test results to console by defaultShuah Khan1-1/+5
Change run_tests to print individual test results to console by default. Introduce "summary" option to print individual test results to a file /tmp/test_name and just print the summary to the console. This change is necessary to support use-cases where test machines get rebooted once tests are run and the console log should contain the full results. In the following example, individual test results with "summary=1" option are written to /tmp/kcmp_test make --silent TARGETS=kcmp kselftest TAP version 13 selftests: kcmp_test ======================================== pid1: 30126 pid2: 30127 FD: 2 FILES: 2 VM: 1 FS: 2 SIGHAND: 2 IO: 0 SYSVSEM: 0 INV: -1 PASS: 0 returned as expected PASS: 0 returned as expected FAIL: 0 expected but -1 returned (Invalid argument) Pass 2 Fail 1 Xfail 0 Xpass 0 Skip 0 Error 0 1..3 Bail out! Pass 2 Fail 1 Xfail 0 Xpass 0 Skip 0 Error 0 1..3 Pass 0 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0 1..0 ok 1..1 selftests: kcmp_test [PASS] make --silent TARGETS=kcmp summary=1 kselftest TAP version 13 selftests: kcmp_test ======================================== ok 1..1 selftests: kcmp_test [PASS] Signed-off-by: Shuah Khan <[email protected]>
2017-10-31RDMA/nldev: Enforce device index check for port callbackLeon Romanovsky1-1/+3
IB device index is nldev's handler and it should be checked always. Fixes: c3f66f7b0052 ("RDMA/netlink: Implement nldev port doit callback") Signed-off-by: Leon Romanovsky <[email protected]> Acked-by: Doug Ledford <[email protected]> [ Applying directly, since Doug fried his SSD's and is rebuilding - Linus ] Signed-off-by: Linus Torvalds <[email protected]>
2017-10-31Revert "PM / QoS: Fix device resume latency PM QoS"Rafael J. Wysocki8-63/+35
This reverts commit 0cc2b4e5a020 (PM / QoS: Fix device resume latency PM QoS) as it introduced regressions on multiple systems and the fix-up in commit 2a9a86d5c813 (PM / QoS: Fix default runtime_pm device resume latency) does not address all of them. The original problem that commit 0cc2b4e5a020 was attempting to fix will be addressed later. Fixes: 0cc2b4e5a020 (PM / QoS: Fix device resume latency PM QoS) Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-10-31Revert "PM / QoS: Fix default runtime_pm device resume latency"Rafael J. Wysocki1-2/+1
This reverts commit 2a9a86d5c813 (PM / QoS: Fix default runtime_pm device resume latency) as the commit it depends on is going to be reverted. Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-10-31Merge ath-current from ath.gitKalle Valo3-28/+98
ath.git fixes for 4.14. Major changes: ath10k * fix security vulnerability with missing PN check on certain hardware * revert ath10k napi fix as it caused regressions on QCA6174 wcn36xx * remove unnecessary rcu_read_unlock() from error path
2017-10-31scsi: qla2xxx: Fix oops in qla2x00_probe_one error pathDouglas Miller1-0/+1
On error, kthread_create() returns an errno-encoded pointer, not NULL. The routine qla2x00_probe_one() detects the error case and jumps to probe_failed, but has already assigned the return value from kthread_create() to ha->dpc_thread. Then probe_failed checks to see if ha->dpc_thread is not NULL before doing cleanup on it. Since in the error case this is also not NULL, it ends up trying to access an invalid task pointer. Solution is to assign NULL to ha->dpc_thread in the error path to avoid kthread cleanup in that case. Signed-off-by: Douglas Miller <[email protected]> Acked-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2017-10-31xfrm: Fix GSO for IPsec with GRE tunnel.Steffen Klassert1-1/+3
We reset the encapsulation field of the skb too early in xfrm_output. As a result, the GRE GSO handler does not segment the packets. This leads to a performance drop down. We fix this by resetting the encapsulation field right before we do the transformation, when the inner headers become invalid. Fixes: f1bd7d659ef0 ("xfrm: Add encapsulation header offsets while SKB is not encrypted") Reported-by: Vicente De Luca <[email protected]> Signed-off-by: Steffen Klassert <[email protected]>
2017-10-31ALSA: seq: Fix nested rwsem annotation for lockdep splatTakashi Iwai1-1/+1
syzkaller reported the lockdep splat due to the possible deadlock of grp->list_mutex of each sequencer client object. Actually this is rather a false-positive report due to the missing nested lock annotations. The sequencer client may deliver the event directly to another client which takes another own lock. For addressing this issue, this patch replaces the simple down_read() with down_read_nested(). As a lock subclass, the already existing "hop" can be re-used, which indicates the depth of the call. Reference: http://lkml.kernel.org/r/[email protected] Reported-by: syzbot <bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com> Reported-by: Dmitry Vyukov <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2017-10-31ALSA: timer: Add missing mutex lock for compat ioctlsTakashi Iwai1-2/+15
The races among ioctl and other operations were protected by the commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and later fixes, but one code path was forgotten in the scenario: the 32bit compat ioctl. As syzkaller recently spotted, a very similar use-after-free may happen with the combination of compat ioctls. The fix is simply to apply the same ioctl_lock to the compat_ioctl callback, too. Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls") Reference: http://lkml.kernel.org/r/[email protected] Reported-by: syzbot <bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2017-10-31tc-testing: fix arg to ip command: -s -> -nBrenda J. Butler1-2/+2
Fixes: 31c2611b66e0 ("selftests: Introduce a new test case to tc testsuite") Fixes: 76b903ee198d ("selftests: Introduce tc testsuite") Signed-off-by: Brenda J. Butler <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-31net_sched: remove tcf_block_put_deferred()Cong Wang1-29/+8
In commit 7aa0045dadb6 ("net_sched: introduce a workqueue for RCU callbacks of tc filter") I defer tcf_chain_flush() to a workqueue, this causes a use-after-free because qdisc is already destroyed after we queue this work. The tcf_block_put_deferred() is no longer necessary after we get RTNL for each tc filter destroy work, no others could jump in at this point. Same for tcf_chain_hold(), we are fully serialized now. This also reduces one indirection therefore makes the code more readable. Note this brings back a rcu_barrier(), however comparing to the code prior to commit 7aa0045dadb6 we still reduced one rcu_barrier(). For net-next, we can consider to refcnt tcf block to avoid it. Fixes: 7aa0045dadb6 ("net_sched: introduce a workqueue for RCU callbacks of tc filter") Cc: Daniel Borkmann <[email protected]> Cc: Jiri Pirko <[email protected]> Cc: John Fastabend <[email protected]> Cc: Jamal Hadi Salim <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Eric Dumazet <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-31l2tp: hold tunnel in pppol2tp_connect()Guillaume Nault1-1/+6
Use l2tp_tunnel_get() in pppol2tp_connect() to ensure the tunnel isn't going to disappear while processing the rest of the function. Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-30Merge tag 'pm-urgent-4.14' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "This fixes new breakage introduced by the most recent PM QoS fix in which, embarrassingly enough, I forgot to update dev_pm_qos_raw_read_value() to return the right default for devices with no PM QoS constraints at all which prevents runtime PM from suspending those devices (fix from Tero Kristo)" * tag 'pm-urgent-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM / QoS: Fix default runtime_pm device resume latency
2017-10-30drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)Chris Wilson1-0/+2
Kasan spotted [IGT] gem_tiled_pread_pwrite: exiting, ret=0 ================================================================== BUG: KASAN: use-after-free in __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] Read of size 8 at addr ffff8801359da310 by task kworker/3:2/182 CPU: 3 PID: 182 Comm: kworker/3:2 Tainted: G U 4.14.0-rc6-CI-Custom_3340+ #1 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 Workqueue: events __i915_gem_free_work [i915] Call Trace: dump_stack+0x68/0xa0 print_address_description+0x78/0x290 ? __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] kasan_report+0x23d/0x350 __asan_report_load8_noabort+0x19/0x20 __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] ? i915_gem_object_truncate+0x100/0x100 [i915] ? lock_acquire+0x380/0x380 __i915_gem_object_put_pages+0x30d/0x530 [i915] __i915_gem_free_objects+0x551/0xbd0 [i915] ? lock_acquire+0x13e/0x380 __i915_gem_free_work+0x4e/0x70 [i915] process_one_work+0x6f6/0x1590 ? pwq_dec_nr_in_flight+0x2b0/0x2b0 worker_thread+0xe6/0xe90 ? pci_mmcfg_check_reserved+0x110/0x110 kthread+0x309/0x410 ? process_one_work+0x1590/0x1590 ? kthread_create_on_node+0xb0/0xb0 ret_from_fork+0x27/0x40 Allocated by task 1801: save_stack_trace+0x1b/0x20 kasan_kmalloc+0xee/0x190 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xdc/0x2e0 radix_tree_node_alloc.constprop.12+0x48/0x330 __radix_tree_create+0x274/0x480 __radix_tree_insert+0xa2/0x610 i915_gem_object_get_sg+0x224/0x670 [i915] i915_gem_object_get_page+0xb5/0x1c0 [i915] i915_gem_pread_ioctl+0x822/0xf60 [i915] drm_ioctl_kernel+0x13f/0x1c0 drm_ioctl+0x6cf/0x980 do_vfs_ioctl+0x184/0xf30 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1c/0xb1 Freed by task 37: save_stack_trace+0x1b/0x20 kasan_slab_free+0xaf/0x190 kmem_cache_free+0xbf/0x340 radix_tree_node_rcu_free+0x79/0x90 rcu_process_callbacks+0x46d/0xf40 __do_softirq+0x21c/0x8d3 The buggy address belongs to the object at ffff8801359da0f0 which belongs to the cache radix_tree_node of size 576 The buggy address is located 544 bytes inside of 576-byte region [ffff8801359da0f0, ffff8801359da330) The buggy address belongs to the page: page:ffffea0004d67600 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x8000000000008100(slab|head) raw: 8000000000008100 0000000000000000 0000000000000000 0000000100110011 raw: ffffea0004b52920 ffffea0004b38020 ffff88015b416a80 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801359da200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801359da280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8801359da300: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc ^ ffff8801359da380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801359da400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint which looks like the slab containing the radixtree iter was freed as we traversed the tree, taking the rcu read lock across the loop should prevent that (deferring all the frees until the end). Reported-by: Tomi Sarvela <[email protected]> Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> (cherry picked from commit 547da76b5777859f98bb78e6b57f19463f803c04) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)Chris Wilson1-0/+2
Kasan spotted [IGT] gem_tiled_pread_pwrite: exiting, ret=0 ================================================================== BUG: KASAN: use-after-free in __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] Read of size 8 at addr ffff8801359da310 by task kworker/3:2/182 CPU: 3 PID: 182 Comm: kworker/3:2 Tainted: G U 4.14.0-rc6-CI-Custom_3340+ #1 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 Workqueue: events __i915_gem_free_work [i915] Call Trace: dump_stack+0x68/0xa0 print_address_description+0x78/0x290 ? __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] kasan_report+0x23d/0x350 __asan_report_load8_noabort+0x19/0x20 __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] ? i915_gem_object_truncate+0x100/0x100 [i915] ? lock_acquire+0x380/0x380 __i915_gem_object_put_pages+0x30d/0x530 [i915] __i915_gem_free_objects+0x551/0xbd0 [i915] ? lock_acquire+0x13e/0x380 __i915_gem_free_work+0x4e/0x70 [i915] process_one_work+0x6f6/0x1590 ? pwq_dec_nr_in_flight+0x2b0/0x2b0 worker_thread+0xe6/0xe90 ? pci_mmcfg_check_reserved+0x110/0x110 kthread+0x309/0x410 ? process_one_work+0x1590/0x1590 ? kthread_create_on_node+0xb0/0xb0 ret_from_fork+0x27/0x40 Allocated by task 1801: save_stack_trace+0x1b/0x20 kasan_kmalloc+0xee/0x190 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xdc/0x2e0 radix_tree_node_alloc.constprop.12+0x48/0x330 __radix_tree_create+0x274/0x480 __radix_tree_insert+0xa2/0x610 i915_gem_object_get_sg+0x224/0x670 [i915] i915_gem_object_get_page+0xb5/0x1c0 [i915] i915_gem_pread_ioctl+0x822/0xf60 [i915] drm_ioctl_kernel+0x13f/0x1c0 drm_ioctl+0x6cf/0x980 do_vfs_ioctl+0x184/0xf30 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1c/0xb1 Freed by task 37: save_stack_trace+0x1b/0x20 kasan_slab_free+0xaf/0x190 kmem_cache_free+0xbf/0x340 radix_tree_node_rcu_free+0x79/0x90 rcu_process_callbacks+0x46d/0xf40 __do_softirq+0x21c/0x8d3 The buggy address belongs to the object at ffff8801359da0f0 which belongs to the cache radix_tree_node of size 576 The buggy address is located 544 bytes inside of 576-byte region [ffff8801359da0f0, ffff8801359da330) The buggy address belongs to the page: page:ffffea0004d67600 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x8000000000008100(slab|head) raw: 8000000000008100 0000000000000000 0000000000000000 0000000100110011 raw: ffffea0004b52920 ffffea0004b38020 ffff88015b416a80 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801359da200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801359da280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8801359da300: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc ^ ffff8801359da380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801359da400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint which looks like the slab containing the radixtree iter was freed as we traversed the tree, taking the rcu read lock across the loop should prevent that (deferring all the frees until the end). Reported-by: Tomi Sarvela <[email protected]> Fixes: 96d776345277 ("drm/i915: Use a radixtree for random access to the object's backing storage") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> (cherry picked from commit bea6e987c1ff358224e7bef7084be7650f5d1c38) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915/edp: read edp display control registers unconditionallyJani Nikula1-3/+10
Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in DP_EDP_CONFIGURATION_CAP should be set if the eDP display control registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we check the bit before reading the registers, and DP_EDP_DPCD_REV is the only way to detect eDP revision. Turns out there are (likely buggy) displays that require eDP 1.4+ features, such as supported link rates and link rate select, but do not have the bit set. Read the display control registers unconditionally. They are supposed to read zero anyway if they are not supported, so there should be no harm in this. This fixes the referenced bug by enabling the eDP version check, and thus reading of the supported link rates. The panel in question has 0 in DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the supported link rates method we default to RBR which is insufficient for the panel native mode. As a curiosity, the panel also has a bogus value of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14 (which is 0x03). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400 Reported-and-tested-by: Nicolas P. <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0501a3b0eb01ac2209ef6fce76153e5d6b07034e) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915: Do not rely on wm preservation for ILK watermarksMaarten Lankhorst2-31/+21
The original intent was to preserve watermarks as much as possible in intel_pipe_wm.raw_wm, and put the validated ones in intel_pipe_wm.wm. It seems this approach is insufficient and we don't always preserve the raw watermarks, so just use the atomic iterator we're already using to get a const pointer to all bound planes on the crtc. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 Signed-off-by: Maarten Lankhorst <[email protected]> Cc: [email protected] #v4.8+ Acked-by: Ville Syrjälä <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 28283f4f359cd7cfa9e65457bb98c507a2cd0cd0) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915: Cancel the modeset retry work during modeset cleanupManasi Navare1-1/+18
During modeset cleanup on driver unload we may have a pending hotplug work. This needs to be canceled early during the teardown so that it does not fire after we have freed the connector. We do this after drm_kms_helper_poll_fini(dev) since this might trigger modeset retry work due to link retrain and before intel_fbdev_fini() since this work requires the lock from fbdev. If this is not done we may see something like: DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) ------------[ cut here ]------------ WARNING: CPU: 4 PID: 5010 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x4e/0x60 Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem ax88179_178 +a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid +[last unloaded: snd_hda_intel] CPU: 4 PID: 5010 Comm: drv_module_relo Tainted: G U 4.14.0-rc3-CI-CI_DRM_3186+ #1 Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017 task: ffff8803c827aa40 task.stack: ffffc90000520000 RIP: 0010:mutex_destroy+0x4e/0x60 RSP: 0018:ffffc90000523d58 EFLAGS: 00010292 RAX: 000000000000002a RBX: ffff88044fbef648 RCX: 0000000000000000 RDX: 0000000080000001 RSI: 0000000000000001 RDI: ffffffff810f0cf0 RBP: ffffc90000523d60 R08: 0000000000000001 R09: 0000000000000001 R10: 000000000f21cb81 R11: 0000000000000000 R12: ffff88044f71efc8 R13: ffffffffa02b3d20 R14: ffffffffa02b3d90 R15: ffff880459b29308 FS: 00007f5df4d6e8c0(0000) GS:ffff88045d300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055ec51f00a18 CR3: 0000000451782006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: drm_fb_helper_fini+0xd9/0x130 intel_fbdev_destroy+0x12/0x60 [i915] intel_fbdev_fini+0x28/0x30 [i915] intel_modeset_cleanup+0x45/0xa0 [i915] i915_driver_unload+0x92/0x180 [i915] i915_pci_remove+0x19/0x30 [i915] i915_driver_unload+0x92/0x180 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x39/0xb0 device_release_driver_internal+0x15d/0x220 driver_detach+0x40/0x80 bus_remove_driver+0x58/0xd0 driver_unregister+0x2c/0x40 pci_unregister_driver+0x36/0xb0 i915_exit+0x1a/0x8b [i915] SyS_delete_module+0x18c/0x1e0 entry_SYSCALL_64_fastpath+0x1c/0xb1 RIP: 0033:0x7f5df3286287 RSP: 002b:00007fff8e107cc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: ffffffff81493a03 RCX: 00007f5df3286287 RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000564c7be02e48 RBP: ffffc90000523f88 R08: 0000000000000000 R09: 0000000000000080 R10: 00007f5df4d6e8c0 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff8e107eb0 R14: 0000000000000000 R15: 0000000000000000 Or a GPF like: general protection fault: 0000 [#1] PREEMPT SMP Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem ax88179_178 +a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid +[last unloaded: snd_hda_intel] CPU: 0 PID: 82 Comm: kworker/0:1 Tainted: G U W 4.14.0-rc3-CI-CI_DRM_3186+ #1 Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017 Workqueue: events intel_dp_modeset_retry_work_fn [i915] task: ffff88045a5caa40 task.stack: ffffc90000378000 RIP: 0010:drm_setup_crtcs+0x143/0xbf0 RSP: 0018:ffffc9000037bd20 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000780 RDI: 00000000ffffffff RBP: ffffc9000037bdb8 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000780 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88044fbef4e8 R14: 0000000000000780 R15: 0000000000000438 FS: 0000000000000000(0000) GS:ffff88045d200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055ec51ee5168 CR3: 000000044c89d003 CR4: 00000000003606f0 Call Trace: drm_fb_helper_hotplug_event.part.18+0x7e/0xc0 drm_fb_helper_hotplug_event+0x1a/0x20 intel_fbdev_output_poll_changed+0x1a/0x20 [i915] drm_kms_helper_hotplug_event+0x27/0x30 intel_dp_modeset_retry_work_fn+0x77/0x80 [i915] process_one_work+0x233/0x660 worker_thread+0x206/0x3b0 kthread+0x152/0x190 ? process_one_work+0x660/0x660 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x27/0x40 Code: 06 00 00 45 8b 45 20 31 db 45 31 e4 45 85 c0 0f 8e 91 06 00 00 44 8b 75 94 44 8b 7d 90 49 8b 45 28 49 63 d4 44 89 f6 41 83 c4 01 <48> 8b 04 d0 44 +89 fa 48 8b 38 48 8b 87 a8 01 00 00 ff 50 20 01 RIP: drm_setup_crtcs+0x143/0xbf0 RSP: ffffc9000037bd20 ---[ end trace 08901ff1a77d30c7 ]--- v2: * Rename it to intel_hpd_poll_fini() and call drm_kms_helper_fini() inside it as the first step before cancel work (Chris Wilson) * Add GPF trace in commit message and make the function static (Maarten Lankhorst) Suggested-by: Maarten Lankhorst <[email protected]> Suggested-by: Chris Wilson <[email protected]> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link training failure") Cc: Chris Wilson <[email protected]> Cc: Tony Cheng <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjala <[email protected]> Cc: Manasi Navare <[email protected]> Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> (cherry picked from commit 886c6b8692ba5f71b578097524b3b082e2e02119) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30Mark 'ioremap_page_range()' as possibly sleepingLinus Torvalds1-0/+1
It turns out that some drivers seem to think it's ok to remap page ranges from within interrupts and even NMI's. That is definitely not the case, since the page table build-up is simply not interrupt-safe. This showed up in the zero-day robot that reported it for the ACPI APEI GHES ("Generic Hardware Error Source") driver. Normally it had been hidden by the fact that no page table operations had been needed because the vmalloc area had been set up by other things. Apparently due to a recent change to the GHEI driver: commit 77b246b32b2c ("acpi: apei: check for pending errors when probing GHES entries") 0day actually caught a case during bootup whenthe ioremap called down to page allocation. But that recent change only showed the symptom, it wasn't the root cause of the problem. Hopefully it is limited to just that one driver. If you need to access random physical memory, you either need to ioremap in process context, or you need to use the FIXMAP facility to set one particular fixmap entry to the required mapping - that can be done safely. Cc: Borislav Petkov <[email protected]> Cc: Len Brown <[email protected]> Cc: Tony Luck <[email protected]> Cc: Fengguang Wu <[email protected]> Cc: Tyler Baicar <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-10-30Merge tag 'mmc-v4.14-rc4-2' of ↵Linus Torvalds2-7/+23
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: "A couple of MMC host fixes intended for v4.14-rc8: - renesas_sdhi: fix kernel panic - tmio: fix swiotlb buffer is full" * tag 'mmc-v4.14-rc4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c mmc: tmio: fix swiotlb buffer is full
2017-10-30Merge branch 'linus' of ↵Linus Torvalds2-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "This fixes an objtool regression" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: x86/chacha20 - satisfy stack validation 2.0
2017-10-30Merge tag 'mvebu-fixes-4.14-3' of git://git.infradead.org/linux-mvebu into fixesArnd Bergmann3-6/+6
Pull "mvebu fixes for 4.14 (part 3)" from Gregory CLEMENT: Fixing an old stability issue on Cortex A9 based mvebu SoC * tag 'mvebu-fixes-4.14-3' of git://git.infradead.org/linux-mvebu: ARM: dts: mvebu: pl310-cache disable double-linefill
2017-10-30nvme: Fix setting logical block format when revalidatingKeith Busch1-0/+1
Revalidating the disk needs to set the logical block format and capacity, otherwise it can't figure out if the users modified anything about the namespace. Fixes: cdbff4f26bd9 ("nvme: remove nvme_revalidate_ns") Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2017-10-30mmc: dw_mmc: Add locking to the CTO timerDouglas Anderson1-10/+81
This attempts to instill a bit of paranoia to the code dealing with the CTO timer. It's believed that this will make the CTO timer more robust in the case that we're having very long interrupt latencies. Note that I originally thought that perhaps this patch was being overly paranoid and wasn't really needed, but then while I was running mmc_test on an rk3399 board I saw one instance of the message: dwmmc_rockchip fe320000.dwmmc: Unexpected interrupt latency I had debug prints in the CTO timer code and I found that it was running CMD 13 at the time. ...so even though this patch seems like it might be overly paranoid, maybe it really isn't? Presumably the bad interrupt latency experienced was due to the fact that I had serial console enabled as serial console is typically where I place blame when I see absurdly large interrupt latencies. In this particular case there was an (unrelated) printout to the serial console just before I saw the "Unexpected interrupt latency" printout. ...and actually, I managed to even reproduce the problems by running "iw mlan0 scan > /dev/null" while mmc_test was running. That not only does a bunch of PCIe traffic but it also (on my system) outputs some SELinux log spam. Fixes: 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command transfer over scheme") Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2017-10-30mmc: dw_mmc: Fix the CTO timeout calculationDouglas Anderson1-1/+5
In the commit 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command transfer over scheme") we tried to calculate the expected hardware command timeout value. Unfortunately that calculation isn't quite correct in all cases. It used "bus_hz" but, as far as I can tell, it's supposed to use the card clock. Let's account for the div value, which is documented as 2x the value stored in the register, or 1 if the register is 0. NOTE: It's not expected that this will actually fix anything important since the 10 ms margin added by the function will pretty much dwarf any calculations. The card clock should be 100 kHz at minimum and: 1000 ms/s * (255 * 2) / 100000 Hz. Gives us 5.1 ms. ...so really the point of this patch is just to make the code more "correct" in case anyone ever tries to remove the 10 ms buffer. Fixes: 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command transfer over scheme") Tested-by: Emil Renner Berthing <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2017-10-30mmc: dw_mmc: cancel the CTO timer after a voltage switchDouglas Anderson1-1/+2
When running with the commit 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command transfer over scheme") I found this message in the log: Unexpected command timeout, state 7 It turns out that we weren't properly cancelling the new CTO timer in the case that a voltage switch was done. Let's promote the cancel into the dw_mci_cmd_interrupt() function to fix this. Fixes: 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command transfer over scheme") Tested-by: Emil Renner Berthing <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2017-10-30perf/cgroup: Fix perf cgroup hierarchy supportTejun Heo1-2/+4
The following commit: 864c2357ca89 ("perf/core: Do not set cpuctx->cgrp for unscheduled cgroups") made list_update_cgroup_event() skip setting cpuctx->cgrp if no cgroup event targets %current's cgroup. This breaks perf_event's hierarchical support because events which target one of the ancestors get ignored. Fix it by using cgroup_is_descendant() test instead of equality. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: David Carrillo-Cisneros <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] # v4.9+ Fixes: 864c2357ca89 ("perf/core: Do not set cpuctx->cgrp for unscheduled cgroups") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-10-30PM / QoS: Fix default runtime_pm device resume latencyTero Kristo1-1/+2
The recent change to the PM QoS framework to introduce a proper no constraint value overlooked to handle the devices which don't implement PM QoS OPS. Runtime PM is one of the more severely impacted subsystems, failing every attempt to runtime suspend a device. This leads into some nasty second level issues like probe failures and increased power consumption among other things. Fix this by adding a proper return value for devices that don't implement PM QoS. Fixes: 0cc2b4e5a020 (PM / QoS: Fix device resume latency PM QoS) Signed-off-by: Tero Kristo <[email protected]> Cc: All applicable <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2017-10-30Merge tag 'uniphier-fixes-v4.14' of ↵Arnd Bergmann4-11/+22
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier into fixes Pull "UniPhier ARM SoC fixes for v4.14" from Masahiro Yamada: - Add necessary clock to EHCI node * tag 'uniphier-fixes-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier: arm64: dts: uniphier: add STDMAC clock to EHCI nodes ARM: dts: uniphier: add STDMAC clock to EHCI nodes
2017-10-30Revert "ath10k: fix napi_poll budget overflow"Kalle Valo1-11/+6
Thorsten reported on <[email protected]> that commit c9353bf483d3 made ath10k unstable with QCA6174 on his Dell XPS13 (9360) with an error message: ath10k_pci 0000:3a:00.0: failed to extract amsdu: -11 It only seemed to happen with certain APs, not all, but when it happened the only way to get ath10k working was to switch the wifi off and on with a hotkey. As this commit made things even worse (a warning vs breaking the whole connection) let's revert the commit for now and while the issue is being fixed. Link: http://lists.infradead.org/pipermail/ath10k/2017-October/010227.html Reported-by: Thorsten Leemhuis <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.