- 20 Oct, 2016 40 commits
-
-
Andy Lutomirski authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit e1bfc11c upstream. cr4_init_shadow() will panic on 486-like machines without CR4. Fix it using __read_cr4_safe(). Reported-by: david@saggiorato.net Signed-off-by:
Andy Lutomirski <luto@kernel.org> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 1e02ce4c ("x86: Store a per-cpu shadow copy of CR4") Link: http://lkml.kernel.org/r/43a20f81fb504013bf613913dc25574b45336a61.1475091074.git.luto@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Sergei Miroshnichenko authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 9abefcb1 upstream. A timer was used to restart after the bus-off state, leading to a relatively large can_restart() executed in an interrupt context, which in turn sets up pinctrl. When this happens during system boot, there is a high probability of grabbing the pinctrl_list_mutex, which is locked already by the probe() of other device, making the kernel suspect a deadlock condition [1]. To resolve this issue, the restart_timer is replaced by a delayed work. [1] https://github.com/victronenergy/venus/issues/24Signed-off-by:
Sergei Miroshnichenko <sergeimir@emcraft.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
zhong jiang authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 5b398e41 upstream. I hit the following hung task when runing a OOM LTP test case with 4.1 kernel. Call trace: [<ffffffc000086a88>] __switch_to+0x74/0x8c [<ffffffc000a1bae0>] __schedule+0x23c/0x7bc [<ffffffc000a1c09c>] schedule+0x3c/0x94 [<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350 [<ffffffc000a1e32c>] down_write+0x64/0x80 [<ffffffc00021f794>] __ksm_exit+0x90/0x19c [<ffffffc0000be650>] mmput+0x118/0x11c [<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74 [<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4 [<ffffffc0000d0f34>] get_signal+0x444/0x5e0 [<ffffffc000089fcc>] do_signal+0x1d8/0x450 [<ffffffc00008a35c>] do_notify_resume+0x70/0x78 The oom victim cannot terminate because it needs to take mmap_sem for write while the lock is held by ksmd for read which loops in the page allocator ksm_do_scan scan_get_next_rmap_item down_read get_next_rmap_item alloc_rmap_item #ksmd will loop permanently. There is no way forward because the oom victim cannot release any memory in 4.1 based kernel. Since 4.6 we have the oom reaper which would solve this problem because it would release the memory asynchronously. Nevertheless we can relax alloc_rmap_item requirements and use __GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan would just retry later after the lock got dropped. Such a patch would be also easy to backport to older stable kernels which do not have oom_reaper. While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed by the allocation failure. Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
zhong jiang <zhongjiang@huawei.com> Suggested-by:
Hugh Dickins <hughd@google.com> Suggested-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Karl Beldan authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit f6d7c1b5 upstream. This fixes subpage writes when using 4-bit HW ECC. There has been numerous reports about ECC errors with devices using this driver for a while. Also the 4-bit ECC has been reported as broken with subpages in [1] and with 16 bits NANDs in the driver and in mach* board files both in mainline and in the vendor BSPs. What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to try reinitializing the ECC engine: - R/W on whole pages properly generates/checks RS code - try writing the 1st subpage only of a blank page, the subpage is well written and the RS code properly generated, re-reading the same page the HW detects some ECC error, reading the same page again no ECC error is detected Note that the ECC engine is already reinitialized in the 1-bit case. Tested on my LCDK with UBI+UBIFS using subpages. This could potentially get rid of the issue workarounded in [1]. [1] 28c015a9 ("mtd: davinci-nand: disable subpage write for keystone-nand") Fixes: 6a4123e5 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage") Signed-off-by:
Karl Beldan <kbeldan@baylibre.com> Acked-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Joonwoo Park authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 28b89b9e upstream. A discrepancy between cpu_online_mask and cpuset's effective_cpus mask is inevitable during hotplug since cpuset defers updating of effective_cpus mask using a workqueue, during which time nothing prevents the system from more hotplug operations. For that reason guarantee_online_cpus() walks up the cpuset hierarchy until it finds an intersection under the assumption that top cpuset's effective_cpus mask intersects with cpu_online_mask even with such a race occurring. However a sequence of CPU hotplugs can open a time window, during which none of the effective CPUs in the top cpuset intersect with cpu_online_mask. For example when there are 4 possible CPUs 0-3 and only CPU0 is online: ======================== =========================== cpu_online_mask top_cpuset.effective_cpus ======================== =========================== echo 1 > cpu2/online. CPU hotplug notifier woke up hotplug work but not yet scheduled. [0,2] [0] echo 0 > cpu0/online. The workqueue is still runnable. [2] [0] ======================== =========================== Now there is no intersection between cpu_online_mask and top_cpuset.effective_cpus. Thus invoking sys_sched_setaffinity() at this moment can cause following: Unable to handle kernel NULL pointer dereference at virtual address 000000d0 ------------[ cut here ]------------ Kernel BUG at ffffffc0001389b0 [verbose debug info unavailable] Internal error: Oops - BUG: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 1420 Comm: taskset Tainted: G W 4.4.8+ #98 task: ffffffc06a5c4880 ti: ffffffc06e124000 task.ti: ffffffc06e124000 PC is at guarantee_online_cpus+0x2c/0x58 LR is at cpuset_cpus_allowed+0x4c/0x6c <snip> Process taskset (pid: 1420, stack limit = 0xffffffc06e124020) Call trace: [<ffffffc0001389b0>] guarantee_online_cpus+0x2c/0x58 [<ffffffc00013b208>] cpuset_cpus_allowed+0x4c/0x6c [<ffffffc0000d61f0>] sched_setaffinity+0xc0/0x1ac [<ffffffc0000d6374>] SyS_sched_setaffinity+0x98/0xac [<ffffffc000085cb0>] el0_svc_naked+0x24/0x28 The top cpuset's effective_cpus are guaranteed to be identical to cpu_online_mask eventually. Hence fall back to cpu_online_mask when there is no intersection between top cpuset's effective_cpus and cpu_online_mask. Signed-off-by:
Joonwoo Park <joonwoop@codeaurora.org> Acked-by:
Li Zefan <lizefan@huawei.com> Cc: Tejun Heo <tj@kernel.org> Cc: cgroups@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Marcelo Cerri authored
BugLink: https://bugs.launchpad.net/bugs/1629977 The driver does not handle endianness properly when loading the input data. Signed-off-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 74ff6cb3) Signed-off-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: http://bugs.launchpad.net/bugs/1630857 The stick device does not work after resume, add U1_SP_ABS_MODE flag can make the device work after resume. This has been discovered by pure guesswork, based on how the existing code uses U1_TP_ABS_MODE flag on both initialization and resume. I also tested the the patch on an ALPS touchpad without stick device, did not notice any side effect on suspend/resume, so I made the U1_SP_ABS_MODE flag mandatory. [jkosina@suse.cz: made changelog more verbose] Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> (cherry picked from commit 04fd4cb0) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Marcelo Cerri authored
BugLink: https://bugs.launchpad.net/bugs/1630970 This patch changes the p8_ghash driver to use ghash-generic as a fixed fallback implementation. This allows the correct value of descsize to be defined directly in its shash_alg structure and avoids problems with incorrect buffer sizes when its state is exported or imported. Reported-by:
Jan Stancek <jstancek@redhat.com> Fixes: cc333cd6 ("crypto: vmx - Adding GHASH routines for VMX module") Cc: stable@vger.kernel.org Signed-off-by:
-
Marcelo Cerri authored
BugLink: https://bugs.launchpad.net/bugs/1630970 Move common values and types used by ghash-generic to a new header file so drivers can directly use ghash-generic as a fallback implementation. Fixes: cc333cd6 ("crypto: vmx - Adding GHASH routines for VMX module") Cc: stable@vger.kernel.org Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 Kmemleak reports following false positive memory leaks for each sk buffers allocated by CPSW (__netdev_alloc_skb_ip_align()) in cpsw_ndo_open() and cpsw_rx_handler(): unreferenced object 0xea915000 (size 2048): comm "systemd-network", pid 713, jiffies 4294938323 (age 102.180s) hex dump (first 32 bytes): 00 58 91 ea ff ff ff ff ff ff ff ff ff ff ff ff .X.............. ff ff ff ff ff ff fd 0f 00 00 00 00 00 00 00 00 ................ backtrace: [<c0108680>] __kmalloc_track_caller+0x1a4/0x230 [<c0529eb4>] __alloc_skb+0x68/0x16c [<c052c884>] __netdev_alloc_skb+0x40/0x104 [<bf1ad29c>] cpsw_ndo_open+0x374/0x670 [ti_cpsw] [<c053c3d4>] __dev_open+0xb0/0x114 [<c053c690>] __dev_change_flags+0x9c/0x14c [<c053c760>] dev_change_flags+0x20/0x50 [<c054bdcc>] do_setlink+0x2cc/0x78c [<c054c358>] rtnl_setlink+0xcc/0x100 [<c054b34c>] rtnetlink_rcv_msg+0x184/0x224 [<c056467c>] netlink_rcv_skb+0xa8/0xc4 [<c054b1c0>] rtnetlink_rcv+0x2c/0x34 [<c0564018>] netlink_unicast+0x16c/0x1f8 [<c0564498>] netlink_sendmsg+0x334/0x348 [<c052015c>] sock_sendmsg+0x1c/0x2c [<c05213e0>] SyS_sendto+0xc0/0xe8 unreferenced object 0xec861780 (size 192): comm "softirq", pid 0, jiffies 4294938759 (age 109.540s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 b0 5a ed 00 00 00 00 00 00 00 00 ......Z......... backtrace: [<c0107830>] kmem_cache_alloc+0x190/0x208 [<c052c768>] __build_skb+0x30/0x98 [<c052c8fc>] __netdev_alloc_skb+0xb8/0x104 [<bf1abc54>] cpsw_rx_handler+0x68/0x1e4 [ti_cpsw] [<bf11aa30>] __cpdma_chan_free+0xa8/0xc4 [davinci_cpdma] [<bf11ab98>] __cpdma_chan_process+0x14c/0x16c [davinci_cpdma] [<bf11abfc>] cpdma_chan_process+0x44/0x5c [davinci_cpdma] [<bf1adc78>] cpsw_rx_poll+0x1c/0x9c [ti_cpsw] [<c0539180>] net_rx_action+0x1f0/0x2ec [<c003881c>] __do_softirq+0x134/0x258 [<c0038a00>] do_softirq+0x68/0x70 [<c0038adc>] __local_bh_enable_ip+0xd4/0xe8 [<c0640994>] _raw_spin_unlock_bh+0x30/0x34 [<c05f4e9c>] igmp6_group_added+0x4c/0x1bc [<c05f6600>] ipv6_dev_mc_inc+0x398/0x434 [<c05dba74>] addrconf_dad_work+0x224/0x39c This happens because CPSW allocates SK buffers and then passes pointers on them in CPDMA where they stored in internal CPPI RAM (SRAM) which belongs to DEV MMIO space. Kmemleak does not scan IO memory and so reports memory leaks. Hence, mark allocated sk buffers as false positive explicitly. Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 254a49d5) Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com>
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 The CPSW might be suspended by RPM if all ethX interfaces are down, but it still could be accesible through net_device_ops interfce. In this case net_device_ops operations requiring registers access will cause L3 errors and CPSW crash. Hence, fix it by adding RPM get/put calls in net_device_ops callbacks which need to access CPSW registers: .ndo_set_mac_address(), .ndo_vlan_rx_add_vid(), .ndo_vlan_rx_kill_vid(). Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 The CPSW might be suspended by RPM if all ethX interfaces are down, but it still could be accesible through ethtool interfce. In this case ethtool operations, requiring registers access, will cause L3 errors and CPSW crash. ethtool callbcaks which need to access CPSW registers now: .set_coalesce(), .get_ethtool_stats(), .set_pauseparam(), .get_regs() Hence, fix it by adding .begin()/.complete() ethtool callbacks, which will be called before/after each ethtool operation runs, and do CPSW RPM handling in these callbacks. That way CPSW will be active while handling ethtool requests. Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 PM runtime is properly handled in cpsw_ndo_open/stop(), as result it isn't required to duplicate these calls in .suspend()/.resume() callbacks. Moreover, it might cause unnecessary RPM resume of CPSW during System suspend in the case it's already suspended because all ethX interfaces are down already, before System suspend started. Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 Add missed check of return code from PM runtime get() calls. Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 The cpsw_ndo_open() could try to access CPSW registers before calling pm_runtime_get_sync(). This will trigger L3 error: WARNING: CPU: 0 PID: 21 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x220/0x34c() 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_FAST (Idle): Data Access in Supervisor mode during Functional access and CPSW will stop functioning. Hence, fix it by moving pm_runtime_get_sync() before the first access to CPSW registers in cpsw_ndo_open(). Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 The cpsw_suspend() could trigger L3 error and CPSW will stop functioning if System enters suspend when all ethX net-devices are down - in this case CPSW could be already suspended by PM runtime, but cpsw_suspend() will try to call soft_reset_slave() unconditionally and access CPSW registers. Hence, fix it by moving soft_reset_slave() from cpsw_suspend() to cpsw_slave_stop(). This way slave ports will be reset when CPSW is active and will be in proper state during Suspend. Signed-off-by:
-
Andrea Gelmini authored
BugLink: http://bugs.launchpad.net/bugs/1625177Signed-off-by:
Andrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by:
Tony Lindgren <tony@atomide.com> (cherry picked from commit f733e7c0) Signed-off-by:
-
Tony Lindgren authored
BugLink: http://bugs.launchpad.net/bugs/1625177 If a driver PM runtime is disabled via sysfs, and the module is unloaded, PM runtime can't do anything to disable the device. Let's let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER. Otherwise omap_device will produce and error on the following module reload. This can be easily tested with something like: Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Nishanth Menon <nm@ti.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Reported-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
Kevin Hilman <khilman@baylibre.com> Acked-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 Below call chain causes system crash when OMAP device is removed by calling of_platform_depopulate()/device_del(): device_del() - blocking_notifier_call_chain(&dev->bus->p->bus_notifier, BUS_NOTIFY_DEL_DEVICE, dev); - _omap_device_notifier_call() - omap_device_delete() - od->pdev->archdata.od = NULL; kfree(od->hwmods); kfree(od); - bus_remove_device() - device_release_driver() - __device_release_driver() - pm_runtime_get_sync() - _od_runtime_resume() - omap_hwmod_enable() <- OOPS od's delted already Backtrace: Unable to handle kernel NULL pointer dereference at virtual address 0000000d pgd = eb100000 [0000000d] *pgd=ad6e1831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 1273 Comm: modprobe Not tainted 4.4.15-rt19-00115-ge4d3cd3-dirty #68 Hardware name: Generic DRA74X (Flattened Device Tree) task: eb1ee800 ti: ec962000 task.ti: ec962000 PC is at omap_device_enable+0x10/0x90 LR is at _od_runtime_resume+0x10/0x24 [...] [<c00299dc>] (omap_device_enable) from [<c0029a6c>] (_od_runtime_resume+0x10/0x24) [<c0029a6c>] (_od_runtime_resume) from [<c04ad404>] (__rpm_callback+0x20/0x34) [<c04ad404>] (__rpm_callback) from [<c04ad438>] (rpm_callback+0x20/0x80) [<c04ad438>] (rpm_callback) from [<c04aee28>] (rpm_resume+0x48c/0x964) [<c04aee28>] (rpm_resume) from [<c04af360>] (__pm_runtime_resume+0x60/0x88) [<c04af360>] (__pm_runtime_resume) from [<c04a4974>] (__device_release_driver+0x30/0x100) [<c04a4974>] (__device_release_driver) from [<c04a4a60>] (device_release_driver+0x1c/0x28) [<c04a4a60>] (device_release_driver) from [<c04a38c0>] (bus_remove_device+0xec/0x144) [<c04a38c0>] (bus_remove_device) from [<c04a0764>] (device_del+0x10c/0x210) [<c04a0764>] (device_del) from [<c04a67b0>] (platform_device_del+0x18/0x84) [<c04a67b0>] (platform_device_del) from [<c04a6828>] (platform_device_unregister+0xc/0x20) [<c04a6828>] (platform_device_unregister) from [<c05adcfc>] (of_platform_device_destroy+0x8c/0x90) [<c05adcfc>] (of_platform_device_destroy) from [<c04a02f0>] (device_for_each_child+0x4c/0x78) [<c04a02f0>] (device_for_each_child) from [<c05adc5c>] (of_platform_depopulate+0x30/0x44) [<c05adc5c>] (of_platform_depopulate) from [<bf123920>] (cpsw_remove+0x68/0xf4 [ti_cpsw]) [<bf123920>] (cpsw_remove [ti_cpsw]) from [<c04a68d8>] (platform_drv_remove+0x24/0x3c) [<c04a68d8>] (platform_drv_remove) from [<c04a49c8>] (__device_release_driver+0x84/0x100) [<c04a49c8>] (__device_release_driver) from [<c04a4b20>] (driver_detach+0xac/0xb0) [<c04a4b20>] (driver_detach) from [<c04a3be8>] (bus_remove_driver+0x60/0xd4) [<c04a3be8>] (bus_remove_driver) from [<c00d9870>] (SyS_delete_module+0x184/0x20c) [<c00d9870>] (SyS_delete_module) from [<c0010540>] (ret_fast_syscall+0x0/0x1c) Code: e3500000 e92d4070 1590630c 01a06000 (e5d6300d) Hence, fix it by using BUS_NOTIFY_REMOVED_DEVICE event for OMAP device deletion which is sent when DD has finished processing of device deletion. Cc: Tony Lindgren <tony@atomide.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 Use of_platform_depopulate() in cpsw_remove() instead of of_device_unregister(), because CSPW child devices will not be recreated otherwise on next insmod. of_platform_depopulate() is correct way now as it will ensure that all steps done in of_platform_populate() are reverted, including cleaning up of OF_POPULATED flag. Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 The L3 error will be generated and system will crash during unloading of CPSW driver if CPSW is used as module and ethX devices are down. This happens because CPSW can be power off by PM runtime now when ethX devices are down. Hence, ensure that CPSW powered up by PM runtime before performing any deinitialization actions which require CPSW registers access. In case of PM runtime error just leave cpsw_remove() as we can't do anything anymore. Signed-off-by:
-
Grygorii Strashko authored
BugLink: http://bugs.launchpad.net/bugs/1625177 Fix deadlock in cpdma_ctlr_destroy() which is triggered now on cpsw module removal: cpsw_remove() - cpdma_ctlr_destroy() - spin_lock_irqsave(&ctlr->lock, flags) - cpdma_ctlr_stop() - spin_lock_irqsave(&ctlr->lock, flags); - cpdma_chan_destroy() - spin_lock_irqsave(&ctlr->lock, flags); The issue has not been observed before because CPDMA channels have been destroyed manually by CPSW until commit d941ebe8 ("net: ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1629204 autofs passes the uid and gid of the user requesting a mount to userspace, taking them from current->cred. ca6fe334 "fs: Call d_automount with the filesystems creds" causes a regression as current->cred is now the credentials of real root during automount and not the credentials of the user. Fix this by taking the ids from current->real_cred instead. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1629386Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 8a545f18 upstream. We can't pass error pointers to kfree() or it causes an oops. Fixes: 52b209f7 ('get rid of hostfs_read_inode()') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit f4cceb2a upstream. If kmap fails, it leads to memory corruption. Fixes: f64122c1 ('drm: add new QXL driver. (v1.4)') Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwandaSigned-off-by:
-
Sven Van Asbroeck authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 5381cfb6 upstream. The device's model download function returns the model data as an array of u32s, which is later compared to the reference model data. However, since the latter is an array of u16s, the comparison does not happen correctly, and model verification fails. This in turn breaks the POR initialization sequence. Fixes: 39e7213e ("max17042_battery: Support regmap to access device's registers") Reported-by:
Sven Van Asbroeck <TheSven73@googlemail.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 33e7664a upstream. Add missing platform_set_drvdata() in tps65217_charger_probe(), otherwise calling platform_get_drvdata() in remove returns NULL. This is detected by Coccinelle semantic patch. Fixes: 3636859b ("power_supply: Add support for tps65217-charger") Signed-off-by:
Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by:
-
James Morse authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 924d8696 upstream. rtree_next_node() walks the linked list of leaf nodes to find the next block of pages in the struct memory_bitmap. If it walks off the end of the list of nodes, it walks the list of memory zones to find the next region of memory. If it walks off the end of the list of zones, it returns false. This leaves the struct bm_position's node and zone pointers pointing at their respective struct list_heads in struct mem_zone_bm_rtree. memory_bm_find_bit() uses struct bm_position's node and zone pointers to avoid walking lists and trees if the next bit appears in the same node/zone. It handles these values being stale. Swap rtree_next_node()s 'step then test' to 'test-next then step', this means if we reach the end of memory we return false and leave the node and zone pointers as they were. This fixes a panic on resume using AMD Seattle with 64K pages: [ 6.868732] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 6.875753] Double checking all user space processes after OOM killer disable... (elapsed 0.000 seconds) [ 6.896453] PM: Using 3 thread(s) for decompression. [ 6.896453] PM: Loading and decompressing image data (5339 pages)... [ 7.318890] PM: Image loading progress: 0% [ 7.323395] Unable to handle kernel paging request at virtual address 00800040 [ 7.330611] pgd = ffff000008df0000 [ 7.334003] [00800040] *pgd=00000083fffe0003, *pud=00000083fffe0003, *pmd=00000083fffd0003, *pte=0000000000000000 [ 7.344266] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 7.349825] Modules linked in: [ 7.352871] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G W I 4.8.0-rc1 #4737 [ 7.360512] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD1002C 04/08/2016 [ 7.369109] task: ffff8003c0220000 task.stack: ffff8003c0280000 [ 7.375020] PC is at set_bit+0x18/0x30 [ 7.378758] LR is at memory_bm_set_bit+0x24/0x30 [ 7.383362] pc : [<ffff00000835bbc8>] lr : [<ffff0000080faf18>] pstate: 60000045 [ 7.390743] sp : ffff8003c0283b00 [ 7.473551] [ 7.475031] Process swapper/0 (pid: 1, stack limit = 0xffff8003c0280020) [ 7.481718] Stack: (0xffff8003c0283b00 to 0xffff8003c0284000) [ 7.800075] Call trace: [ 7.887097] [<ffff00000835bbc8>] set_bit+0x18/0x30 [ 7.891876] [<ffff0000080fb038>] duplicate_memory_bitmap.constprop.38+0x54/0x70 [ 7.899172] [<ffff0000080fcc40>] snapshot_write_next+0x22c/0x47c [ 7.905166] [<ffff0000080fe1b4>] load_image_lzo+0x754/0xa88 [ 7.910725] [<ffff0000080ff0a8>] swsusp_read+0x144/0x230 [ 7.916025] [<ffff0000080fa338>] load_image_and_restore+0x58/0x90 [ 7.922105] [<ffff0000080fa660>] software_resume+0x2f0/0x338 [ 7.927752] [<ffff000008083350>] do_one_initcall+0x38/0x11c [ 7.933314] [<ffff000008b40cc0>] kernel_init_freeable+0x14c/0x1ec [ 7.939395] [<ffff0000087ce564>] kernel_init+0x10/0xfc [ 7.944520] [<ffff000008082e90>] ret_from_fork+0x10/0x40 [ 7.949820] Code: d2800022 8b400c21 f9800031 9ac32043 (c85f7c22) [ 7.955909] ---[ end trace 0024a5986e6ff323 ]--- [ 7.960529] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Here struct mem_zone_bm_rtree's start_pfn has been returned instead of struct rtree_node's addr as the node/zone pointers are corrupt after we walked off the end of the lists during mark_unsafe_pages(). This behaviour was exposed by commit 6dbecfd3 ("PM / hibernate: Simplify mark_unsafe_pages()"), which caused mark_unsafe_pages() to call duplicate_memory_bitmap(), which uses memory_bm_find_bit() after walking off the end of the memory bitmap. Fixes: 3a20cb17 (PM / Hibernate: Implement position keeping in radix tree) Signed-off-by:
James Morse <james.morse@arm.com> [ rjw: Subject ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Thomas Garnier authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 62822e2e upstream. Restore the processor state before calling any other functions to ensure per-CPU variables can be used with KASLR memory randomization. Tracing functions use per-CPU variables (GS based on x86) and one was called just before restoring the processor state fully. It resulted in a double fault when both the tracing & the exception handler functions tried to use a per-CPU variable. Fixes: bb3632c6 (PM / sleep: trace events for suspend/resume) Reported-and-tested-by:
Jiri Kosina <jikos@kernel.org> Tested-by:
Rafael J. Wysocki <rafael@kernel.org> Tested-by:
Thomas Garnier <thgarnie@google.com> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Matt Redfearn authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 951c39cd upstream. If the paravirt machine is compiles without CONFIG_SMP, the following linker error occurs arch/mips/kernel/head.o: In function `kernel_entry': (.ref.text+0x10): undefined reference to `smp_bootstrap' due to the kernel entry macro always including SMP startup code. Wrap this code in CONFIG_SMP to fix the error. Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14212/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Huacai Chen authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 3cbc6fc9 upstream. Commit 842dfc11 ("MIPS: Fix build with binutils 2.24.51+") missing a ".set pop" in macro fpu_restore_16even, so add it. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Acked-by:
Manuel Lauss <manuel.lauss@gmail.com> Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14210/Signed-off-by:
-
Marcin Nowakowski authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit b244614a upstream. cpu_has_fpu macro uses smp_processor_id() and is currently executed with preemption enabled, that triggers the warning at runtime. It is assumed throughout the kernel that if any CPU has an FPU, then all CPUs would have an FPU as well, so it is safe to perform the check with preemption enabled - change the code to use raw_ variant of the check to avoid the warning. Signed-off-by:
Marcin Nowakowski <marcin.nowakowski@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14125/Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit b03c1e3b upstream. Commit c1a0e9bc ("MIPS: Allow compact branch policy to be changed") added Kconfig entries allowing for the compact branch policy used by the compiler for MIPSr6 kernels to be specified. This can be useful for debugging, particularly in systems where compact branches have recently been introduced. Unfortunately mainline gcc 5.x supports MIPSr6 but not the -mcompact-branches compiler flag, leading to MIPSr6 kernels failing to build with gcc 5.x with errors such as: mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal' make[2]: *** [kernel/bounds.s] Error 1 Fixing this by hiding the Kconfig entry behind another seems to be more hassle than it's worth, as MIPSr6 & compact branches have been around for a while now and if policy does need to be set for debug it can be done easily enough with KCFLAGS. Therefore remove the compact branch policy Kconfig entries & their handling in the Makefile. This reverts commit c1a0e9bc ("MIPS: Allow compact branch policy to be changed"). Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: c1a0e9bc ("MIPS: Allow compact branch policy to be changed") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14241/Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 554af0c3 upstream. The page structures associated with the vDSO pages in the kernel image are calculated using virt_to_page(), which uses __pa() under the hood to find the pfn associated with the virtual address. The vDSO data pointers however point to kernel symbols, so __pa_symbol() should really be used instead. Since there is no equivalent to virt_to_page() which uses __pa_symbol(), fix init_vdso_image() to work directly with pfns, calculated with __phys_to_pfn(__pa_symbol(...)). This issue broke the Malta Enhanced Virtual Addressing (EVA) configuration which has a non-default implementation of __pa_symbol(). This is because it uses a physical alias so that the kernel executes from KSeg0 (VA 0x80000000 -> PA 0x00000000), while RAM is provided to the kernel in the KUSeg range (VA 0x00000000 -> PA 0x80000000) which uses the same underlying RAM. Since there are no page structures associated with the low physical address region, some arbitrary kernel memory would be interpreted as a page structure for the vDSO pages and badness ensues. Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14229/Signed-off-by:
-
Matt Redfearn authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 8f46cca1 upstream. This patch fixes the possibility of a deadlock when bringing up secondary CPUs. The deadlock occurs because the set_cpu_online() is called before synchronise_count_slave(). This can cause a deadlock if the boot CPU, having scheduled another thread, attempts to send an IPI to the secondary CPU, which it sees has been marked online. The secondary is blocked in synchronise_count_slave() waiting for the boot CPU to enter synchronise_count_master(), but the boot cpu is blocked in smp_call_function_many() waiting for the secondary to respond to it's IPI request. Fix this by marking the CPU online in cpu_callin_map and synchronising counters before declaring the CPU online and calculating the maps for IPIs. Signed-off-by:
Justin Chen <justinpopo6@gmail.com> Tested-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 7e956304 upstream. In the mipsr2_decoder() function, used to emulate pre-MIPSr6 instructions that were removed in MIPSr6, the init_fpu() function is called if a removed pre-MIPSr6 floating point instruction is the first floating point instruction used by the task. However, init_fpu() performs varous actions that rely upon not being migrated. For example in the most basic case it sets the coprocessor 0 Status.CU1 bit to enable the FPU & then loads FP register context into the FPU registers. If the task were to migrate during this time, it may end up attempting to load FP register context on a different CPU where it hasn't set the CU1 bit, leading to errors such as: do_cpu invoked from kernel context![#2]: CPU: 2 PID: 7338 Comm: fp-prctl Tainted: G D 4.7.0-00424-g49b0c82 #2 task: 838e4000 ti: 88d38000 task.ti: 88d38000 $ 0 : 00000000 00000001 ffffffff 88d3fef8 $ 4 : 838e4000 88d38004 00000000 00000001 $ 8 : 3400fc01 801f8020 808e9100 24000000 $12 : dbffffff 807b69d8 807b0000 00000000 $16 : 00000000 80786150 00400fc4 809c0398 $20 : 809c0338 0040273c 88d3ff28 808e9d30 $24 : 808e9d30 00400fb4 $28 : 88d38000 88d3fe88 00000000 8011a2ac Hi : 0040273c Lo : 88d3ff28 epc : 80114178 _restore_fp+0x10/0xa0 ra : 8011a2ac mipsr2_decoder+0xd5c/0x1660 Status: 1400fc03 KERNEL EXL IE Cause : 1080002c (ExcCode 0b) PrId : 0001a920 (MIPS I6400) Modules linked in: Process fp-prctl (pid: 7338, threadinfo=88d38000, task=838e4000, tls=766527d0) Stack : 00000000 00000000 00000000 88d3fe98 00000000 00000000 809c0398 809c0338 808e9100 00000000 88d3ff28 00400fc4 00400fc4 0040273c 7fb69e18 004a0000 004a0000 004a0000 7664add0 8010de18 00000000 00000000 88d3fef8 88d3ff28 808e9100 00000000 766527d0 8010e534 000c0000 85755000 8181d580 00000000 00000000 00000000 004a0000 00000000 766527d0 7fb69e18 004a0000 80105c20 ... Call Trace: [<80114178>] _restore_fp+0x10/0xa0 [<8011a2ac>] mipsr2_decoder+0xd5c/0x1660 [<8010de18>] do_ri+0x90/0x6b8 [<80105c20>] ret_from_exception+0x0/0x10 Fix this by disabling preemption around the call to init_fpu(), ensuring that it starts & completes on one CPU. Signed-off-by:
-
Sudeep Holla authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 331dcf42 upstream. If the i2c device is already runtime suspended, if qup_i2c_suspend is executed during suspend-to-idle or suspend-to-ram it will result in the following splat: WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90 Modules linked in: CPU: 3 PID: 1593 Comm: bash Tainted: G W 4.8.0-rc3 #14 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) PC is at clk_core_unprepare+0x80/0x90 LR is at clk_unprepare+0x28/0x40 pc : [<ffff0000086eecf0>] lr : [<ffff0000086f0c58>] pstate: 60000145 Call trace: clk_core_unprepare+0x80/0x90 qup_i2c_disable_clocks+0x2c/0x68 qup_i2c_suspend+0x10/0x20 platform_pm_suspend+0x24/0x68 ... This patch fixes the issue by executing qup_i2c_pm_suspend_runtime conditionally in qup_i2c_suspend. Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Reviewed-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Yadi.hu authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 371a0153 upstream. the eg20t driver call request_irq() function before the pch_base_address, base address of i2c controller's register, is assigned an effective value. there is one possible scenario that an interrupt which isn't inside eg20t arrives immediately after request_irq() is executed when i2c controller shares an interrupt number with others. since the interrupt handler pch_i2c_handler() has already active as shared action, it will be called and read its own register to determine if this interrupt is from itself. At that moment, since base address of i2c registers is not remapped in kernel space yet,so the INT handler will access an illegal address and then a error occurs. Signed-off-by:
Yadi.hu <yadi.hu@windriver.com> Signed-off-by:
-
Jeff Mahoney authored
BugLink: http://bugs.launchpad.net/bugs/1629386 commit 325c50e3 upstream. If the subvol/snapshot create/destroy ioctls are passed a regular file with execute permissions set, we'll eventually Oops while trying to do inode->i_op->lookup via lookup_one_len. This patch ensures that the file descriptor refers to a directory. Fixes: cb8e7090 (Btrfs: Fix subvolume creation locking rules) Fixes: 76dda93c (Btrfs: add snapshot/subvolume destroy ioctl) Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
