- 20 Oct, 2016 40 commits
-
-
Yan, Zheng authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit af5e5eb5 upstream. Readdir cache uses page cache to save dentry pointers. When adding dentry pointers to middle of a page, we need to make sure the page already exists. Otherwise the beginning part of the page will be invalid pointers. Signed-off-by:
Yan, Zheng <zyan@redhat.com> Cc: Nikolay Borisov <kernel@kyup.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Emmanuel Grumbach authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit ff6e58e6 upstream. fw-dbg code return ret but that variable was either 0 or not initialised. Return 0 always. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: 6a951267 ("iwlwifi: mvm: send dbg config hcmds to fw if set in tlv") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Sara Sharon authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit d5d0689a upstream. This fixes a pretty ancient bug that hasn't manifested itself until now. The scratchbuf for command queue is allocated only for 32 slots but is accessed with the queue write pointer - which can be up to 256. Since the scratch buf size was 16 and there are up to 256 TFDs we never passed a page boundary when accessing the scratch buffer, but when attempting to increase the size of the scratch buffer a panic was quick to follow when trying to access the address resulted in a page boundary. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Fixes: 38c0f334 ("iwlwifi: use coherent DMA memory for command header") Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit c3ccf357 upstream. The conversion from a look-up table to a calculation for clock generator parameters forgot to take into account that BRDV x 1/1 is valid only if BRPS is x 1/1 or x 1/2, leading to undefined behavior (e.g. arbitrary clock rates). This limitation is documented for the MSIOF module in all supported SH/R-Mobile and R-Car Gen2/Gen3 ARM SoCs. Tested on r8a7791/koelsch and r8a7795/salvator-x. Fixes: 65d5665b ("spi: sh-msiof: Update calculation of frequency dividing") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Michael Walle authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit b53893aa upstream. According to the datasheet you should only write 1 to this bit. If it is not set, at least AIN3 will return bad values on newer silicon revisions. Fixes: d84ca5b3 ("hwmon: Add driver for ADT7411 voltage and temperature sensor") Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit a6c50912 upstream. nvmem_cell_read() is declared as void * if CONFIG_NVMEM is enabled, and as char * otherwise. This can result in a build warning if CONFIG_NVMEM is not enabled and a caller asigns the result to a type other than char * without using a typecast. Use a consistent declaration to avoid the problem. Fixes: e2a5402e ("nvmem: Add nvmem_device based consumer apis.") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Quentin Armitage authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 3777ed68 upstream. When using HEAD from https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/, the command: ipvsadm --start-daemon backup --mcast-interface eth0.60 \ --mcast-group ff02::1:81 fails with the error message: Argument list too long whereas both: ipvsadm --start-daemon master --mcast-interface eth0.60 \ --mcast-group ff02::1:81 and: ipvsadm --start-daemon backup --mcast-interface eth0.60 \ --mcast-group 224.0.0.81 are successful. The error message "Argument list too long" isn't helpful. The error occurs because an IPv6 address is given in backup mode. The error is in make_receive_sock() in net/netfilter/ipvs/ip_vs_sync.c, since it fails to set the interface on the address or the socket before calling inet6_bind() (via sock->ops->bind), where the test 'if (!sk->sk_bound_dev_if)' failed. Setting sock->sk->sk_bound_dev_if on the socket before calling inet6_bind() resolves the issue. Fixes: d3328817 ("ipvs: add more mcast parameters for the sync daemon") Signed-off-by:
Quentin Armitage <quentin@armitage.org.uk> Acked-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 2d6a4d64 upstream. The curly braces are missing here so we print stuff unintentionally. Fixes: 9da4714a ('slub: slabinfo update for cmpxchg handling') Link: http://lkml.kernel.org/r/20160715211243.GE19522@mwandaSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Christoph Lameter <cl@linux.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Laura Abbott <labbott@fedoraproject.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Robert Jarzmik authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit b3802db5 upstream. As reported by Dan in his report in [1], there is a potential NULL pointer derefence if these conditions are met : - there is no platform_data provided, ie. host->pdata = NULL Fix this by only using the platform data ro_invert when a gpio for read-only is provided by the platform data. This doesn't appear yet as every pxa board provides a platform_data, and calls pxa_set_mci_info() with a non NULL pointer. [1] [bug report] mmc: pxamci: fix card detect with slot-gpio API. The commit fd546ee6 ("mmc: pxamci: fix card detect with slot-gpio API") from Sep 26, 2015, leads to the following static checker warning: drivers/mmc/host/pxamci.c:809 pxamci_probe() warn: variable dereferenced before check 'host->pdata' (see line 798) Fixes: fd546ee6 ("mmc: pxamci: fix card detect with slot-gpio API") Reported-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Stefan Wahren authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 75324684 upstream. In case of a IRQ type mismatch in of_pmu_irq_cfg() the device node for interrupt affinity isn't freed. So fix this issue by calling of_node_put(). Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: fa8ad788 ("arm: perf: factor arm_pmu core out to drivers") Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 7440926e upstream. Documentation incorrectly refers to struct pinctrl_desc, where no such flag is available. Replace the name of the struct. Fixes: commit 8c4c2016 ("pinctrl: move strict option to pinmux_ops") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Masahiro Yamada authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 10ef8277 upstream. Without this, reading the "pins" in the debugfs causes kernel BUG. Fixes: 6e908892 ("pinctrl: UniPhier: add UniPhier pinctrl core support") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Heinrich Schuchardt authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit cd956722 upstream. In function i40e_debug_aq parameter desc is assumed to be possibly NULL. Do not dereference it before checking the value. Fixes: f905dd62 ("i40e/i40evf: add max buf len to aq debug print helper") Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Mark Rutland authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 2c81a647 upstream. The following commit: 66eb579e ("perf: allow for PMU-specific event filtering") added the pmu::filter_match() callback. This was intended to avoid HW constraints on events from resulting in extremely pessimistic scheduling. However, pmu::filter_match() is only called for the leader of each event group. When the leader is a SW event, we do not filter the groups, and may fail at pmu::add() time, and when this happens we'll give up on scheduling any event groups later in the list until they are rotated ahead of the failing group. This can result in extremely sub-optimal event scheduling behaviour, e.g. if running the following on a big.LITTLE platform: $ taskset -c 0 ./perf stat \ -e 'a57{context-switches,armv8_cortex_a57/config=0x11/}' \ -e 'a53{context-switches,armv8_cortex_a53/config=0x11/}' \ ls <not counted> context-switches (0.00%) <not counted> armv8_cortex_a57/config=0x11/ (0.00%) 24 context-switches (37.36%) 57589154 armv8_cortex_a53/config=0x11/ (37.36%) Here the 'a53' event group was always eligible to be scheduled, but the 'a57' group never eligible to be scheduled, as the task was always affine to a Cortex-A53 CPU. The SW (group leader) event in the 'a57' group was eligible, but the HW event failed at pmu::add() time, resulting in ctx_flexible_sched_in giving up on scheduling further groups with HW events. One way of avoiding this is to check pmu::filter_match() on siblings as well as the group leader. If any of these fail their pmu::filter_match() call, we must skip the entire group before attempting to add any events. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Fixes: 66eb579e ("perf: allow for PMU-specific event filtering") Link: http://lkml.kernel.org/r/1465917041-15339-1-git-send-email-mark.rutland@arm.com [ Small readability edits. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Johannes Berg authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 280a3efa upstream. My cleanup in "iwlwifi: prepare for higher API/CAPA bits" accidentally inverted a few tests - fix them. Fixes: 859d914c ("iwlwifi: prepare for higher API/CAPA bits") Reported-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Cristian Birsan authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 4c2ba0c6 upstream. Commit ac33cdb1 ("usb: musb: Remove ifdefs for musb_host_rx in musb_host.c part5") introduces a problem setting DMA host mode. The musb_advance_schedule() is called immediately after receiving an endpoint RX interrupt without waiting for the DMA transfer to complete. As a consequence when the dma complete interrupt arrives the in_qh member of hw_ep is already null an the musb_host_rx() exits on !urb error case. Fix the done condition that advances the musb schedule. Signed-off-by:
Cristian Birsan <cristian.birsan@microchip.com> Signed-off-by:
Joshua Henderson <joshua.henderson@microchip.com> Tested-by:
Ladislav Michl <ladis@linux-mips.org> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Adam Ford <aford173@gmail.com> Signed-off-by:
-
Cristian Birsan authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit bba40e69 upstream. Commit 754fe4a9 ("usb: musb: Remove ifdefs for TX DMA for musb_host.c") introduces a problem setting the desired channel mode for the Mentor DMA engine. There is a case where an address is incorrectly assigned to the DMA channel desired mode when it should instead be assigned the actual mode value. This results in the value of channel->desired_mode not being correct. Acked-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Roger Quadros authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit d248220f upstream. Since commit 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation"), dma_to_pfn() already returns the PFN with the physical memory start offset so we don't need to add it again. This fixes USB mass storage lock-up problem on systems that can't do DMA over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM can only do DMA over the first 2GB. [K2E-EVM]. What happens there is that without this patch SCSI layer sets a wrong bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2 is 0x87fffffff. This results in non DMA'ble pages being given to the USB controller and hence the lock-up. NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0. This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000 and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be 0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because USB devices are not correctly inheriting the dma_pfn_offset from the USB host controller. This will be fixed by a separate patch. Fixes: 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Olof Johansson <olof@lixom.net> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reported-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Robin Murphy authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit ba6dea4f upstream. Whilst MPIDR values themselves are less than 32 bits, it is still perfectly valid for a DT to have #address-cells > 1 in the CPUs node, resulting in the "reg" property having leading zero cell(s). In that situation, the big-endian nature of the data conspires with the current behaviour of only reading the first cell to cause the kernel to think all CPUs have ID 0, and become resoundingly unhappy as a consequence. Take the full property length into account when parsing CPUs so as to be correct under any circumstances. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 670bb4fd upstream. Add clock quirks for Jet parts. Reviewed-by:
Sonny Jiang <sonny.jiang@amd.com> Tested-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Ilia Mirkin authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 666ca3d8 upstream. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Andy Lutomirski authored
BugLink: http://bugs.launchpad.net/bugs/1631468 commit 05fb3c19 upstream. Otherwise arch_task_struct_size == 0 and we die. While we're at it, set X86_FEATURE_ALWAYS, too. Reported-by:
David Saggiorato <david@saggiorato.net> Tested-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> 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: aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86") Link: http://lkml.kernel.org/r/8de723afbf0811071185039f9088733188b606c9.1475103911.git.luto@kernel.orgSigned-off-by:
-
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:
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:
-
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:
-
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:
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:
Kevin Hilman <khilman@baylibre.com> Acked-by:
-
