aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-11-01Merge branch 'for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace Pull signal bugfix from Eric Biederman: "When making the generic support for SIGEMT conditional on the presence of SIGEMT I made a typo that causes it to fail to activate. It was noticed comparatively quickly but the bug report just made it to me today" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: signal: Fix name of SIGEMT in #if defined() check
2017-11-01MAINTAINERS: Update Pistachio platform maintainersJames Hartley1-3/+2
Neither of the current maintainers works for Imagination any more. Removed both imgtec email addresses and added back mine for occasional reviews, also changed from Maintained to Odd Fixes to reflect the time that I will be able to spend on it. Signed-off-by: James Hartley <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/17475/ Signed-off-by: James Hogan <[email protected]>
2017-11-01MIPS: smp-cmp: Use right include for task_structJason A. Donenfeld1-1/+1
When task_struct was moved, this MIPS code was neglected. Evidently nobody is using it anymore. This fixes this build error: In file included from ./arch/mips/include/asm/thread_info.h:15:0, from ./include/linux/thread_info.h:37, from ./include/asm-generic/current.h:4, from ./arch/mips/include/generated/asm/current.h:1, from ./include/linux/sched.h:11, from arch/mips/kernel/smp-cmp.c:22: arch/mips/kernel/smp-cmp.c: In function ‘cmp_boot_secondary’: ./arch/mips/include/asm/processor.h:384:41: error: implicit declaration of function ‘task_stack_page’ [-Werror=implicit-function-declaration] #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \ ^ arch/mips/kernel/smp-cmp.c:84:21: note: in expansion of macro ‘__KSTK_TOS’ unsigned long sp = __KSTK_TOS(idle); ^~~~~~~~~~ Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs from <linux/sched.h> to <linux/sched/task_stack.h>") Signed-off-by: Jason A. Donenfeld <[email protected]> Cc: <[email protected]> # 4.11+ Patchwork: https://patchwork.linux-mips.org/patch/17522/ Signed-off-by: James Hogan <[email protected]>
2017-11-01signal: Fix name of SIGEMT in #if defined() checkAndrew Clayton1-1/+1
Commit cc731525f26a ("signal: Remove kernel interal si_code magic") added a check for SIGMET and NSIGEMT being defined. That SIGMET should in fact be SIGEMT, with SIGEMT being defined in arch/{alpha,mips,sparc}/include/uapi/asm/signal.h This was actually pointed out by BenHutchings in a lwn.net comment here https://lwn.net/Comments/734608/ Fixes: cc731525f26a ("signal: Remove kernel interal si_code magic") Signed-off-by: Andrew Clayton <[email protected]> Signed-off-by: "Eric W. Biederman" <[email protected]>
2017-11-01Merge branch 'for-linus' of git://git.kernel.dk/linux-blockLinus Torvalds4-4/+21
Pull block fixes from Jens Axboe: "A few fixes that should go into this series: - Regression fix for ide-cd, ensuring that a request is fully initialized. From Hongxu. - Ditto fix for virtio_blk, from Bart. - NVMe fix from Keith, ensuring that we set the right block size on revalidation. If the block size changed, we'd be in trouble without it. - NVMe rdma fix from Sagi, fixing a potential hang while the controller is being removed" * 'for-linus' of git://git.kernel.dk/linux-block: ide:ide-cd: fix kernel panic resulting from missing scsi_req_init nvme: Fix setting logical block format when revalidating virtio_blk: Fix an SG_IO regression nvme-rdma: fix possible hang when issuing commands during ctrl removal
2017-11-01MIPS: Update Goldfish RTC driver maintainer email addressAleksandar Markovic2-1/+2
Change all relevant instances of [email protected] email address to [email protected]. Signed-off-by: Miodrag Dinic <[email protected]> Signed-off-by: Aleksandar Markovic <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/17515/ [[email protected]: Fix .mailmap direction] Signed-off-by: James Hogan <[email protected]>
2017-11-01MIPS: Update RINT emulation maintainer email addressAleksandar Markovic2-1/+2
Change all relevant instances of [email protected] email address to [email protected]. Signed-off-by: Miodrag Dinic <[email protected]> Signed-off-by: Aleksandar Markovic <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/17514/ Signed-off-by: James Hogan <[email protected]>
2017-11-01MIPS: CPS: Fix use of current_cpu_data in preemptible codeMatt Redfearn1-1/+1
Commit 1ec9dd80bedc ("MIPS: CPS: Detect CPUs in secondary clusters") added a check in cps_boot_secondary() that the secondary being booted is in the same cluster as the CPU running this code. This check is performed using current_cpu_data without disabling preemption. As such when CONFIG_PREEMPT=y, a BUG is triggered: [ 57.991693] BUG: using smp_processor_id() in preemptible [00000000] code: hotplug/1749 <snip> [ 58.063077] Call Trace: [ 58.065842] [<8040cdb4>] show_stack+0x84/0x114 [ 58.070830] [<80b11b38>] dump_stack+0xf8/0x140 [ 58.075796] [<8079b12c>] check_preemption_disabled+0xec/0x118 [ 58.082204] [<80415110>] cps_boot_secondary+0x84/0x44c [ 58.087935] [<80413a14>] __cpu_up+0x34/0x98 [ 58.092624] [<80434240>] bringup_cpu+0x38/0x114 [ 58.097680] [<80434af0>] cpuhp_invoke_callback+0x168/0x8f0 [ 58.103801] [<804362d0>] _cpu_up+0x154/0x1c8 [ 58.108565] [<804363dc>] do_cpu_up+0x98/0xa8 [ 58.113333] [<808261f8>] device_online+0x84/0xc0 [ 58.118481] [<80826294>] online_store+0x60/0x98 [ 58.123562] [<8062261c>] kernfs_fop_write+0x158/0x1d4 [ 58.129196] [<805a2ae4>] __vfs_write+0x4c/0x168 [ 58.134247] [<805a2dc8>] vfs_write+0xe0/0x190 [ 58.139095] [<805a2fe0>] SyS_write+0x68/0xc4 [ 58.143854] [<80415d58>] syscall_common+0x34/0x58 In reality we don't currently support running the kernel on CPUs not in cluster 0, so the answer to cpu_cluster(&current_cpu_data) will always be 0, even if this task being preempted and continues running on a different CPU. Regardless, the BUG should not be triggered, so fix this by switching to raw_current_cpu_data. When multicluster support lands upstream this check will need removing or changing anyway. Fixes: 1ec9dd80bedc ("MIPS: CPS: Detect CPUs in secondary clusters") Signed-off-by: Matt Redfearn <[email protected]> Reviewed-by: Paul Burton <[email protected]> CC: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/17563/ Signed-off-by: James Hogan <[email protected]>
2017-11-01x86/mcelog: Get rid of RCU remnantsBorislav Petkov1-94/+27
Jeremy reported a suspicious RCU usage warning in mcelog. /dev/mcelog is called in process context now as part of the notifier chain and doesn't need any of the fancy RCU and lockless accesses which it did in atomic context. Axe it all in favor of a simple mutex synchronization which cures the problem reported. Fixes: 5de97c9f6d85 ("x86/mce: Factor out and deprecate the /dev/mcelog driver") Reported-by: Jeremy Cline <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-and-tested-by: Tony Luck <[email protected]> Cc: Andi Kleen <[email protected]> Cc: [email protected] Cc: Laura Abbott <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Link: https://bugzilla.redhat.com/show_bug.cgi?id=1498969
2017-11-01watchdog/hardlockup/perf: Use atomics to track in-use cpu counterDon Zickus1-3/+5
Guenter reported: There is still a problem. When running echo 6 > /proc/sys/kernel/watchdog_thresh echo 5 > /proc/sys/kernel/watchdog_thresh repeatedly, the message NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. stops after a while (after ~10-30 iterations, with fluctuations). Maybe watchdog_cpus needs to be atomic ? That's correct as this again is affected by the asynchronous nature of the smpboot thread unpark mechanism. CPU 0 CPU1 CPU2 write(watchdog_thresh, 6) stop() park() update() start() unpark() thread->unpark() cnt++; write(watchdog_thresh, 5) thread->unpark() stop() park() thread->park() cnt--; cnt++; update() start() unpark() That's not a functional problem, it just affects the informational message. Convert watchdog_cpus to atomic_t to prevent the problem Reported-and-tested-by: Guenter Roeck <[email protected]> Signed-off-by: Don Zickus <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2017-11-01watchdog/harclockup/perf: Revert a33d44843d45 ("watchdog/hardlockup/perf: ↵Thomas Gleixner1-2/+5
Simplify deferred event destroy") Guenter reported a crash in the watchdog/perf code, which is caused by cleanup() and enable() running concurrently. The reason for this is: The watchdog functions are serialized via the watchdog_mutex and cpu hotplug locking, but the enable of the perf based watchdog happens in context of the unpark callback of the smpboot thread. But that unpark function is not synchronous inside the locking. The unparking of the thread just wakes it up and leaves so there is no guarantee when the thread is executing. If it starts running _before_ the cleanup happened then it will create a event and overwrite the dead event pointer. The new event is then cleaned up because the event is marked dead. lock(watchdog_mutex); lockup_detector_reconfigure(); cpus_read_lock(); stop(); park() update(); start(); unpark() cpus_read_unlock(); thread runs() overwrite dead event ptr cleanup(); free new event, which is active inside perf.... unlock(watchdog_mutex); The park side is safe as that actually waits for the thread to reach parked state. Commit a33d44843d45 removed the protection against this kind of scenario under the stupid assumption that the hotplug serialization and the watchdog_mutex cover everything. Bring it back. Reverts: a33d44843d45 ("watchdog/hardlockup/perf: Simplify deferred event destroy") Reported-and-tested-by: Guenter Roeck <[email protected]> Signed-off-by: Thomas Feels-stupid Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Don Zickus <[email protected]> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710312145190.1942@nanos
2017-11-01ARM: 8716/1: pass endianness info to sparseLuc Van Oostenryck1-0/+2
ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined or not to correctly select or define endian-specific macros, structures or pieces of code. These macros are predefined by the compiler but sparse knows nothing about them and thus may pre-process files differently from what gcc would. Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse, depending on the endianness of the kernel, like defined by GCC. Note: In most case it won't change anything since most ARMs use little-endian (but an allyesconfig would use big-endian!). To: Russell King <[email protected]> Cc: [email protected] Signed-off-by: Luc Van Oostenryck <[email protected]> Signed-off-by: Russell King <[email protected]>
2017-11-01drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issueSinclair Yeh1-1/+1
This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work around mode set failure in 2D VMs") With Wayland desktop and atomic mode set, during the mode setting process there is a moment when two framebuffer sized surfaces are being pinned. This was not an issue with Xorg. Since this only happens during a mode change, there should be no performance impact by increasing allowable mem_size. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Cc: [email protected]
2017-11-01drm/vmwgfx: constify vmw_fence_opsArvind Yadav1-1/+1
vmw_fence_ops are not supposed to change at runtime. Functions "dma_fence_init" working with const vmw_fence_ops provided by <linux/dma-fence.h>. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]>
2017-11-01drm/i915: Check incoming alignment for unfenced buffers (on i915gm)Chris Wilson1-0/+4
In case the object has changed tiling between calls to execbuf, we need to check if the existing offset inside the GTT matches the new tiling constraint. We even need to do this for "unfenced" tiled objects, where the 3D commands use an implied fence and so the object still needs to match the physical fence restrictions on alignment (only required for gen2 and early gen3). In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array"), the idea was to remove the second guessing and only set the NEEDS_MAP flag when required. However, the entire check for an unusable offset for fencing was removed and not just the secondary check. I.e. /* avoid costly ping-pong once a batch bo ended up non-mappable */ if (entry->flags & __EXEC_OBJECT_NEEDS_MAP && !i915_vma_is_map_and_fenceable(vma)) return !only_mappable_for_reloc(entry->flags); was entirely removed as the ping-pong between execbuf passes was fixed, but its primary purpose in forcing unaligned unfenced access to be rebound was forgotten. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502 Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> (cherry picked from commit 1d033beb20d6d5885587a02a393b6598d766a382) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-11-01Merge tag 'asoc-fix-v4.14-rc7' of ↵Takashi Iwai707-4365/+7146
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.14 A bunch of fixes here, mostly device specific ones (the biggest one being the revert of the hotword support for rt5514), with a couple of core fixes for potential issues with corrupted or otherwise invalid topology files.
2017-11-01Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds26-86/+182
Pull networking fixes from David Miller: 1) Fix refcounting in xfrm_bundle_lookup() when using a dummy bundle, from Steffen Klassert. 2) Fix crypto header handling in rx data frames in ath10k driver, from Vasanthakumar Thiagarajan. 3) Fix use after free of qdisc when we defer tcp_chain_flush() to a workqueue. From Cong Wang. 4) Fix double free in lapbether driver, from Pan Bian. 5) Sanitize TUNSETSNDBUF values, from Craig Gallek. 6) Fix refcounting when addrconf_permanent_addr() calls ipv6_del_addr(). From Eric Dumazet. 7) Fix MTU probing bug in TCP that goes back to 2007, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: tcp: fix tcp_mtu_probe() vs highest_sack ipv6: addrconf: increment ifp refcount before ipv6_del_addr() tun/tap: sanitize TUNSETSNDBUF input mlxsw: i2c: Fix buffer increment counter for write transaction mlxsw: reg: Add high and low temperature thresholds MAINTAINERS: Remove Yotam from mlxfw MAINTAINERS: Update Yotam's E-mail net: hns: set correct return value net: lapbether: fix double free bpf: remove SK_REDIRECT from UAPI net: phy: marvell: Only configure RGMII delays when using RGMII xfrm: Fix GSO for IPsec with GRE tunnel. tc-testing: fix arg to ip command: -s -> -n net_sched: remove tcf_block_put_deferred() l2tp: hold tunnel in pppol2tp_connect() Revert "ath10k: fix napi_poll budget overflow" ath10k: rebuild crypto header in rx data frames wcn36xx: Remove unnecessary rcu_read_unlock in wcn36xx_bss_info_changed xfrm: Clear sk_dst_cache when applying per-socket policy. xfrm: Fix xfrm_dst_cache memleak
2017-11-01x86/mm: fix use-after-free of vma during userfaultfd faultVlastimil Babka1-1/+10
Syzkaller with KASAN has reported a use-after-free of vma->vm_flags in __do_page_fault() with the following reproducer: mmap(&(0x7f0000000000/0xfff000)=nil, 0xfff000, 0x3, 0x32, 0xffffffffffffffff, 0x0) mmap(&(0x7f0000011000/0x3000)=nil, 0x3000, 0x1, 0x32, 0xffffffffffffffff, 0x0) r0 = userfaultfd(0x0) ioctl$UFFDIO_API(r0, 0xc018aa3f, &(0x7f0000002000-0x18)={0xaa, 0x0, 0x0}) ioctl$UFFDIO_REGISTER(r0, 0xc020aa00, &(0x7f0000019000)={{&(0x7f0000012000/0x2000)=nil, 0x2000}, 0x1, 0x0}) r1 = gettid() syz_open_dev$evdev(&(0x7f0000013000-0x12)="2f6465762f696e7075742f6576656e742300", 0x0, 0x0) tkill(r1, 0x7) The vma should be pinned by mmap_sem, but handle_userfault() might (in a return to userspace scenario) release it and then acquire again, so when we return to __do_page_fault() (with other result than VM_FAULT_RETRY), the vma might be gone. Specifically, per Andrea the scenario is "A return to userland to repeat the page fault later with a VM_FAULT_NOPAGE retval (potentially after handling any pending signal during the return to userland). The return to userland is identified whenever FAULT_FLAG_USER|FAULT_FLAG_KILLABLE are both set in vmf->flags" However, since commit a3c4fb7c9c2e ("x86/mm: Fix fault error path using unsafe vma pointer") there is a vma_pkey() read of vma->vm_flags after that point, which can thus become use-after-free. Fix this by moving the read before calling handle_mm_fault(). Reported-by: syzbot <bot+6a5269ce759a7bb12754ed9622076dc93f65a1f6@syzkaller.appspotmail.com> Reported-by: Dmitry Vyukov <[email protected]> Suggested-by: Kirill A. Shutemov <[email protected]> Fixes: 3c4fb7c9c2e ("x86/mm: Fix fault error path using unsafe vma pointer") Reviewed-by: Andrea Arcangeli <[email protected]> Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-11-01Merge tag 'smb3-file-name-too-long-fix' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds1-2/+3
Pull cifs fix from Steve French: "smb3 file name too long fix" * tag 'smb3-file-name-too-long-fix' of git://git.samba.org/sfrench/cifs-2.6: cifs: check MaxPathNameComponentLength != 0 before using it
2017-11-01ide:ide-cd: fix kernel panic resulting from missing scsi_req_initHongxu Jia1-0/+1
Since we split the scsi_request out of struct request, while the standard prep_rq_fn builds 10 byte cmds, it missed to invoke scsi_req_init() to initialize certain fields of a scsi_request structure (.__cmd[], .cmd, .cmd_len and .sense_len but no other members of struct scsi_request). An example panic on virtual machines (qemu/virtualbox) to boot from IDE cdrom: ... [ 8.754381] Call Trace: [ 8.755419] blk_peek_request+0x182/0x2e0 [ 8.755863] blk_fetch_request+0x1c/0x40 [ 8.756148] ? ktime_get+0x40/0xa0 [ 8.756385] do_ide_request+0x37d/0x660 [ 8.756704] ? cfq_group_service_tree_add+0x98/0xc0 [ 8.757011] ? cfq_service_tree_add+0x1e5/0x2c0 [ 8.757313] ? ktime_get+0x40/0xa0 [ 8.757544] __blk_run_queue+0x3d/0x60 [ 8.757837] queue_unplugged+0x2f/0xc0 [ 8.758088] blk_flush_plug_list+0x1f4/0x240 [ 8.758362] blk_finish_plug+0x2c/0x40 ... [ 8.770906] RIP: ide_cdrom_prep_fn+0x63/0x180 RSP: ffff92aec018bae8 [ 8.772329] ---[ end trace 6408481e551a85c9 ]--- ... Fixes: 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Hongxu Jia <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2017-11-01mmc: dw_mmc: Fix the DTO timeout calculationDouglas Anderson1-1/+6
Just like the CTO timeout calculation introduced recently, the DTO timeout calculation was incorrect. 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: This was likely not terribly important until commit 16a34574c6ca ("mmc: dw_mmc: remove the quirks flags") landed because "DIV" is documented on Rockchip SoCs (the ones that used to define the quirk) to always be 0 or 1. ...and, in fact, it's documented to only be 1 with EMMC in 8-bit DDR52 mode. Thus before the quirk was applied to everyone it was mostly OK to ignore the DIV value. I haven't personally observed any problems that are fixed by this patch but I also haven't tested this anywhere with a DIV other an 0. AKA: this problem was found simply by code inspection and I have no failing test cases that are fixed by it. Presumably this could fix real bugs for someone out there, though. Fixes: 16a34574c6ca ("mmc: dw_mmc: remove the quirks flags") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Shawn Lin <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2017-11-01Merge remote-tracking branches 'asoc/fix/topology', 'asoc/fix/adau17x1', ↵Mark Brown10-73/+53
'asoc/fix/rt5514', 'asoc/fix/rt5616', 'asoc/fix/rt5659' and 'asoc/fix/rt5663' into tmp
2017-11-01tcp: fix tcp_mtu_probe() vs highest_sackEric Dumazet2-4/+5
Based on SNMP values provided by Roman, Yuchung made the observation that some crashes in tcp_sacktag_walk() might be caused by MTU probing. Looking at tcp_mtu_probe(), I found that when a new skb was placed in front of the write queue, we were not updating tcp highest sack. If one skb is freed because all its content was copied to the new skb (for MTU probing), then tp->highest_sack could point to a now freed skb. Bad things would then happen, including infinite loops. This patch renames tcp_highest_sack_combine() and uses it from tcp_mtu_probe() to fix the bug. Note that I also removed one test against tp->sacked_out, since we want to replace tp->highest_sack regardless of whatever condition, since keeping a stale pointer to freed skb is a recipe for disaster. Fixes: a47e5a988a57 ("[TCP]: Convert highest_sack to sk_buff to allow direct access") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Alexei Starovoitov <[email protected]> Reported-by: Roman Gushchin <[email protected]> Reported-by: Oleksandr Natalenko <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Acked-by: Neal Cardwell <[email protected]> Acked-by: Yuchung Cheng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01ipv6: addrconf: increment ifp refcount before ipv6_del_addr()Eric Dumazet1-0/+1
In the (unlikely) event fixup_permanent_addr() returns a failure, addrconf_permanent_addr() calls ipv6_del_addr() without the mandatory call to in6_ifa_hold(), leading to a refcount error, spotted by syzkaller : WARNING: CPU: 1 PID: 3142 at lib/refcount.c:227 refcount_dec+0x4c/0x50 lib/refcount.c:227 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 3142 Comm: ip Not tainted 4.14.0-rc4-next-20171009+ #33 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:52 panic+0x1e4/0x41c kernel/panic.c:181 __warn+0x1c4/0x1e0 kernel/panic.c:544 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178 do_trap_no_signal arch/x86/kernel/traps.c:212 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:261 do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905 RIP: 0010:refcount_dec+0x4c/0x50 lib/refcount.c:227 RSP: 0018:ffff8801ca49e680 EFLAGS: 00010286 RAX: 000000000000002c RBX: ffff8801d07cfcdc RCX: 0000000000000000 RDX: 000000000000002c RSI: 1ffff10039493c90 RDI: ffffed0039493cc4 RBP: ffff8801ca49e688 R08: ffff8801ca49dd70 R09: 0000000000000000 R10: ffff8801ca49df58 R11: 0000000000000000 R12: 1ffff10039493cd9 R13: ffff8801ca49e6e8 R14: ffff8801ca49e7e8 R15: ffff8801d07cfcdc __in6_ifa_put include/net/addrconf.h:369 [inline] ipv6_del_addr+0x42b/0xb60 net/ipv6/addrconf.c:1208 addrconf_permanent_addr net/ipv6/addrconf.c:3327 [inline] addrconf_notify+0x1c66/0x2190 net/ipv6/addrconf.c:3393 notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x32/0x60 net/core/dev.c:1697 call_netdevice_notifiers net/core/dev.c:1715 [inline] __dev_notify_flags+0x15d/0x430 net/core/dev.c:6843 dev_change_flags+0xf5/0x140 net/core/dev.c:6879 do_setlink+0xa1b/0x38e0 net/core/rtnetlink.c:2113 rtnl_newlink+0xf0d/0x1a40 net/core/rtnetlink.c:2661 rtnetlink_rcv_msg+0x733/0x1090 net/core/rtnetlink.c:4301 netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2408 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4313 netlink_unicast_kernel net/netlink/af_netlink.c:1273 [inline] netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1299 netlink_sendmsg+0xa4a/0xe70 net/netlink/af_netlink.c:1862 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 ___sys_sendmsg+0x75b/0x8a0 net/socket.c:2049 __sys_sendmsg+0xe5/0x210 net/socket.c:2083 SYSC_sendmsg net/socket.c:2094 [inline] SyS_sendmsg+0x2d/0x50 net/socket.c:2090 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x7fa9174d3320 RSP: 002b:00007ffe302ae9e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007ffe302b2ae0 RCX: 00007fa9174d3320 RDX: 0000000000000000 RSI: 00007ffe302aea20 RDI: 0000000000000016 RBP: 0000000000000082 R08: 0000000000000000 R09: 000000000000000f R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe302b32a0 R13: 0000000000000000 R14: 00007ffe302b2ab8 R15: 00007ffe302b32b8 Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") Signed-off-by: Eric Dumazet <[email protected]> Cc: David Ahern <[email protected]> Acked-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01tun/tap: sanitize TUNSETSNDBUF inputCraig Gallek2-0/+6
Syzkaller found several variants of the lockup below by setting negative values with the TUNSETSNDBUF ioctl. This patch adds a sanity check to both the tun and tap versions of this ioctl. watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389] Modules linked in: irq event stamp: 329692056 hardirqs last enabled at (329692055): [<ffffffff824b8381>] _raw_spin_unlock_irqrestore+0x31/0x75 hardirqs last disabled at (329692056): [<ffffffff824b9e58>] apic_timer_interrupt+0x98/0xb0 softirqs last enabled at (35659740): [<ffffffff824bc958>] __do_softirq+0x328/0x48c softirqs last disabled at (35659731): [<ffffffff811c796c>] irq_exit+0xbc/0xd0 CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff880009452140 task.stack: ffff880006a20000 RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80 RSP: 0018:ffff880006a27c50 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10 RAX: ffff880009ac68d0 RBX: ffff880006a27ce0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff880006a27ce0 RDI: ffff880009ac6900 RBP: ffff880006a27c60 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 000000000063ff00 R12: ffff880009ac6900 R13: ffff880006a27cf8 R14: 0000000000000001 R15: ffff880006a27cf8 FS: 00007f4be4838700(0000) GS:ffff88000cc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020101000 CR3: 0000000009616000 CR4: 00000000000006f0 Call Trace: prepare_to_wait+0x26/0xc0 sock_alloc_send_pskb+0x14e/0x270 ? remove_wait_queue+0x60/0x60 tun_get_user+0x2cc/0x19d0 ? __tun_get+0x60/0x1b0 tun_chr_write_iter+0x57/0x86 __vfs_write+0x156/0x1e0 vfs_write+0xf7/0x230 SyS_write+0x57/0xd0 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x7f4be4356df9 RSP: 002b:00007ffc18101c08 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4be4356df9 RDX: 0000000000000046 RSI: 0000000020101000 RDI: 0000000000000005 RBP: 00007ffc18101c40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000293 R12: 0000559c75f64780 R13: 00007ffc18101d30 R14: 0000000000000000 R15: 0000000000000000 Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device") Fixes: 20d29d7a916a ("net: macvtap driver") Signed-off-by: Craig Gallek <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01mlxsw: i2c: Fix buffer increment counter for write transactionVadim Pasternak1-1/+1
It fixes a problem for the last chunk where 'chunk_size' is smaller than MLXSW_I2C_BLK_MAX and data is copied to the wrong offset, overriding previous data. Fixes: 6882b0aee180 ("mlxsw: Introduce support for I2C bus") Signed-off-by: Vadim Pasternak <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-01netfilter: nf_reject_ipv4: Fix use-after-free in send_resetTejaswi Tanikella1-0/+2
niph is not updated after pskb_expand_head changes the skb head. It still points to the freed data, which is then used to update tot_len and checksum. This could cause use-after-free poison crash. Update niph, if ip_route_me_harder does not fail. This only affects the interaction with REJECT targets and br_netfilter. Signed-off-by: Tejaswi Tanikella <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-11-01Merge branch 'master' of ↵David S. Miller3-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2017-11-01 1) Fix a memleak when a packet matches a policy without a matching state. 2) Reset the socket cached dst_entry when inserting a socket policy, otherwise the policy might be ignored. From Jonathan Basseri. 3) Fix GSO for a IPsec, GRE tunnel combination. We reset the encapsulation field at the skb too erly, as a result GRE does not segment GSO packets. Fix this by resetting the the encapsulation field right before the transformation where the inner headers get invalid. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <[email protected]>
2017-11-01futex: Fix more put_pi_state() vs. exit_pi_state_list() racesPeter Zijlstra1-3/+20
Dmitry (through syzbot) reported being able to trigger the WARN in get_pi_state() and a use-after-free on: raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock); Both are due to this race: exit_pi_state_list() put_pi_state() lock(&curr->pi_lock) while() { pi_state = list_first_entry(head); hb = hash_futex(&pi_state->key); unlock(&curr->pi_lock); dec_and_test(&pi_state->refcount); lock(&hb->lock) lock(&pi_state->pi_mutex.wait_lock) // uaf if pi_state free'd lock(&curr->pi_lock); .... unlock(&curr->pi_lock); get_pi_state(); // WARN; refcount==0 The problem is we take the reference count too late, and don't allow it being 0. Fix it by using inc_not_zero() and simply retrying the loop when we fail to get a refcount. In that case put_pi_state() should remove the entry from the list. Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: Gratian Crisan <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: syzbot <bot+2af19c9e1ffe4d4ee1d16c56ae7580feaee75765@syzkaller.appspotmail.com> Cc: [email protected] Cc: <[email protected]> Fixes: c74aef2d06a9 ("futex: Fix pi_state->owner serialization") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-11-01powerpc/kprobes: Dereference function pointers only if the address does not ↵Naveen N. Rao1-1/+6
belong to kernel text This makes the changes introduced in commit 83e840c770f2c5 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") to be specific to the kprobe subsystem. We previously changed ppc_function_entry() to always check the provided address to confirm if it needed to be dereferenced. This is actually only an issue for kprobe blacklisted asm labels (through use of _ASM_NOKPROBE_SYMBOL) and can cause other issues with ftrace. Also, the additional checks are not really necessary for our other uses. As such, move this check to the kprobes subsystem. Fixes: 83e840c770f2 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") Cc: [email protected] # v4.13+ Signed-off-by: Naveen N. Rao <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-11-01Revert "powerpc64/elfv1: Only dereference function descriptor for non-text ↵Naveen N. Rao1-9/+1
symbols" This reverts commit 83e840c770f2c5 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols"). Chandan reported that on newer kernels, trying to enable function_graph tracer on ppc64 (BE) locks up the system with the following trace: Unable to handle kernel paging request for data at address 0x600000002fa30010 Faulting instruction address: 0xc0000000001f1300 Thread overran stack, or stack corrupted Oops: Kernel access of bad area, sig: 11 [#1] BE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries Modules linked in: CPU: 1 PID: 6586 Comm: bash Not tainted 4.14.0-rc3-00162-g6e51f1f-dirty #20 task: c000000625c07200 task.stack: c000000625c07310 NIP: c0000000001f1300 LR: c000000000121cac CTR: c000000000061af8 REGS: c000000625c088c0 TRAP: 0380 Not tainted (4.14.0-rc3-00162-g6e51f1f-dirty) MSR: 8000000000001032 <SF,ME,IR,DR,RI> CR: 28002848 XER: 00000000 CFAR: c0000000001f1320 SOFTE: 0 ... NIP [c0000000001f1300] .__is_insn_slot_addr+0x30/0x90 LR [c000000000121cac] .kernel_text_address+0x18c/0x1c0 Call Trace: [c000000625c08b40] [c0000000001bd040] .is_module_text_address+0x20/0x40 (unreliable) [c000000625c08bc0] [c000000000121cac] .kernel_text_address+0x18c/0x1c0 [c000000625c08c50] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c08cf0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c08d60] [c000000000121b40] .kernel_text_address+0x20/0x1c0 [c000000625c08df0] [c000000000061960] .prepare_ftrace_return+0x50/0x130 ... [c000000625c0ab30] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c0abd0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c0ac40] [c000000000121b40] .kernel_text_address+0x20/0x1c0 [c000000625c0acd0] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c0ad70] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c0ade0] [c000000000121b40] .kernel_text_address+0x20/0x1c0 This is because ftrace is using ppc_function_entry() for obtaining the address of return_to_handler() in prepare_ftrace_return(). The call to kernel_text_address() itself gets traced and we end up in a recursive loop. Fixes: 83e840c770f2 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") Cc: [email protected] # v4.13+ Reported-by: Chandan Rajendra <[email protected]> Signed-off-by: Naveen N. Rao <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-11-01mlxsw: reg: Add high and low temperature thresholdsIdo Schimmel1-0/+25
The ASIC has the ability to generate events whenever a sensor indicates the temperature goes above or below its high or low thresholds, respectively. In new firmware versions the firmware enforces a minimum of 5 degrees Celsius difference between both thresholds. Make the driver conform to this requirement. Note that this is required even when the events are disabled, as in certain systems interrupts are generated via GPIO based on these thresholds. Fixes: 85926f877040 ("mlxsw: reg: Add definition of temperature management registers") Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
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"
Powered by cgit, Gruvboxed by Blaster4385.