- 10 Jun, 2016 40 commits
-
-
Florian Fainelli authored
commit cbbda6e7 upstream. BMIPS5000 have a PrID value of 0x5A00 and BMIPS5200 have a PrID value of 0x5B00, which, masked with 0x5A00, returns 0x5A00. Update all conditionals on the PrID to cover both variants since we are going to need this to enable BMIPS5200 SMP. The existing check, masking with 0xFF00 would not cover BMIPS5200 at all. Fixes: 68e6a783 ("MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)") Fixes: 6465460c ("MIPS: BMIPS: change compile time checks to runtime checks") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: john@phrozen.org Cc: cernekee@gmail.com Cc: jogo@openwrt.org Cc: jaedon.shin@gmail.com Cc: jfraser@broadcom.com Cc: pgynther@google.com Cc: dragan.stancevic@gmail.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12279/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Andy Gross authored
commit 2a0974aa upstream. This patch adds the CLK_SET_RATE_PARENT flag for the crypto core and ahb blocks. Without this flag, clk_set_rate can fail for certain frequency requests. Signed-off-by:
Andy Gross <andy.gross@linaro.org> Fixes: 3966fab8 ("clk: qcom: Add MSM8916 Global Clock Controller support") Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Dan Carpenter authored
commit f18ebc21 upstream. The problem with ornamental, do-nothing gotos is that they lead to "forgot to set the error code" bugs. We should be returning -EINVAL here but we don't. It leads to an uninitalized variable in counter_show(): drivers/acpi/sysfs.c:603 counter_show() error: uninitialized symbol 'status'. Fixes: 1c8fce27 (ACPI: introduce drivers/acpi/sysfs.c) Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Sai Gurrappadi authored
commit e43e94c1 upstream. Currently, the userspace governor only updates frequency on GOV_LIMITS if policy->cur falls outside policy->{min/max}. However, it is also necessary to update current frequency on GOV_LIMITS to match the user requested value if it can be achieved within the new policy->{max/min}. This was previously the behaviour in the governor until commit d1922f02 ("cpufreq: Simplify userspace governor") which incorrectly assumed that policy->cur == user requested frequency via scaling_setspeed. This won't be true if the user requested frequency falls outside policy->{min/max}. Ex: a temporary thermal cap throttled the user requested frequency. Fix this by storing the user requested frequency in a seperate variable. The governor will then try to achieve this request on every GOV_LIMITS change. Fixes: d1922f02 (cpufreq: Simplify userspace governor) Signed-off-by:
Sai Gurrappadi <sgurrappadi@nvidia.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Jiri Slaby authored
commit 6798df4c upstream. When csw->con_startup() fails in do_register_con_driver, we return no error (i.e. 0). This was changed back in 2006 by commit 3e795de7. Before that we used to return -ENODEV. So fix the return value to be -ENODEV in that case again. Fixes: 3e795de7 ("VT binding: Add binding/unbinding support for the VT console") Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
James Hogan authored
commit 096a8b6d upstream. The argument i of atomic_*_return() operations is given to inline asm with the "bd" constraint, which means "An Op2 register where Op1 is a data unit register and the instruction supports O2R", however Op1 is constrained by "da" which allows an address unit register to be used. Fix the constraint to use "br", meaning "An Op2 register and the instruction supports O2R", i.e. not requiring Op1 to be a data unit register. Fixes: d6dfe250 ("locking,arch,metag: Fold atomic_ops") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-metag@vger.kernel.org Signed-off-by:
-
Arnd Bergmann authored
commit 1f62ff34 upstream. dev_dbg_ratelimited() is a macro that ignores its first argument when DEBUG is not set, which can lead to unused variable warnings: ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cqe_sdq_handle': ethernet/mellanox/mlxsw/pci.c:646:18: warning: unused variable 'pdev' [-Wunused-variable] ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cqe_rdq_handle': ethernet/mellanox/mlxsw/pci.c:671:18: warning: unused variable 'pdev' [-Wunused-variable] The macro already ensures that all its other arguments are silently ignored by the compiler without triggering a warning, through the use of the no_printk() macro, but the dev argument is not passed into that. This changes the definition to use the same trick as no_printk() with an if(0) that leads the compiler to not evaluate the side-effects but still see that 'dev' might not be unused. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Suggested-by:
Andrew Lunn <andrew@lunn.ch> Fixes: 6f586e66 ("driver-core: Shut up dev_dbg_reatelimited() without DEBUG") Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit 309124e2 upstream. According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is defined. However, commit 153dcc54 ("[PATCH] mem driver: fix conditional on isa i/o support") accidentally changed an "||" into an "&&", disabling it completely on m68k. This logic was retained when introducing the DEVPORT symbol in commit 4f911d64 ("Make /dev/port conditional on config symbol"). Drop the bogus dependency on !M68K to fix this. Fixes: 153dcc54 ("[PATCH] mem driver: fix conditional on isa i/o support") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Al Stone <ahs3@redhat.com> Signed-off-by:
-
Nicolas Dichtel authored
commit 570d8e93 upstream. The type TASKSTATS_TYPE_NULL should always be ignored. When jumping to the next attribute, only the length of the current attribute should be added, not the length of all nested attributes. This last bug was not visible before commit 80df5542, because the kernel didn't put more than two nested attributes. Fixes: a3baf649 ("[PATCH] per-task-delay-accounting: documentation") Fixes: 80df5542 ("taskstats: use the libnl API to align nlattr on 64-bit") Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Aneesh Kumar K.V authored
commit 3b1dbfa1 upstream. The current code will set _PAGE_USER to the access flags for any fault address, because the ~ operation will be true for all address we take a fault on. But setting _PAGE_USER also means that the fault will be handled only if the page table have _PAGE_USER set. Hence there is no security hole with the current code. Now if it is an user space access, then the change in this patch really don't have an impact because we have (!ctx->kernel) set true and we take the if condition true. Now kernel context created fault on an address in the kernel range will result in a fault loop because we will not insert the hash pte due to access and pte permission mismatch. This patch fix the above issue. Fixes: f204e0b8 ("cxl: Driver code for powernv PCIe based cards for userspace access") Reviewed-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Arnd Bergmann authored
commit 3b9d78a4 upstream. DEBUG_HI3716_UART was supposed to be renamed to DEBUG_HIX5HD2_UART, but accidentally both got left in place, which results in a build error when CONFIG_DEBUG_UART_PHYS is not set as it should be. This removes the old symbol. Signed-off-by:
Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
-
Bjorn Helgaas authored
commit c20e1280 upstream. The alpha pci_mmap_resource() is used for both IORESOURCE_MEM and IORESOURCE_IO resources, but iomem_is_exclusive() is only applicable for IORESOURCE_MEM. Call iomem_is_exclusive() only for IORESOURCE_MEM resources, and do it earlier to match the generic version of pci_mmap_resource(). Fixes: 10a0ef39 ("PCI/alpha: pci sysfs resources") Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
-
Bjorn Helgaas authored
commit ca620723 upstream. iomem_is_exclusive() requires a CPU physical address, but on some arches we supplied a PCI bus address instead. On most arches, pci_resource_to_user(res) returns "res->start", which is a CPU physical address. But on microblaze, mips, powerpc, and sparc, it returns the PCI bus address corresponding to "res->start". The result is that pci_mmap_resource() may fail when it shouldn't (if the bus address happens to match an existing resource), or it may succeed when it should fail (if the resource is exclusive but the bus address doesn't match it). Call iomem_is_exclusive() with "res->start", which is always a CPU physical address, not the result of pci_resource_to_user(). Fixes: e8de1481 ("resource: allow MMIO exclusivity for device drivers") Suggested-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Emmanouil Maroudas authored
commit 993f88f1 upstream. Fix typo in edac_inc_ue_error() to increment ue_noinfo_count instead of ce_noinfo_count. Signed-off-by:
Emmanouil Maroudas <emmanouil.maroudas@gmail.com> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: linux-edac <linux-edac@vger.kernel.org> Fixes: 4275be63 ("edac: Change internal representation to work with layers") Link: http://lkml.kernel.org/r/1461425580-5898-1-git-send-email-emmanouil.maroudas@gmail.comSigned-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit 53d0fe68 upstream. Before: # perf test -v kallsyms <SNIP> Maps only in vmlinux: ffffffff81d5e000-ffffffff81ec3ac8 115e000 [kernel].init.text ffffffff81ec3ac8-ffffffffa0000000 12c3ac8 [kernel].exit.text ffffffffa0000000-ffffffffa000c000 0 [fjes] ffffffffa000c000-ffffffffa0017000 0 [video] ffffffffa0017000-ffffffffa001c000 0 [grace] <SNIP> ffffffffa0a7f000-ffffffffa0ba5000 0 [xfs] ffffffffa0ba5000-ffffffffffffffff 0 [veth] Maps in vmlinux with a different name in kallsyms: Maps only in kallsyms: ffff880000100000-ffff88001000b000 80000103000 [kernel.kallsyms] ffff88001000b000-ffff880100000000 8001000e000 [kernel.kallsyms] ffff880100000000-ffffc90000000000 80100003000 [kernel.kallsyms] <SNIP> ffffffffa0000000-ffffffffff600000 7fffa0003000 [kernel.kallsyms] ffffffffff600000-ffffffffffffffff 7fffff603000 [kernel.kallsyms] test child finished with -1 ---- end ---- vmlinux symtab matches kallsyms: FAILED! # After: # perf test -v 1 1: vmlinux symtab matches kallsyms : --- start --- test child forked, pid 7058 Looking at the vmlinux_path (8 entries long) Using /lib/modules/4.6.0-rc1+/build/vmlinux for symbols 0xffffffff81076870: diff end addr for aesni_gcm_dec v: 0xffffffff810791f2 k: 0xffffffff81076902 0xffffffff81079200: diff end addr for aesni_gcm_enc v: 0xffffffff8107bb03 k: 0xffffffff81079292 0xffffffff8107e8d0: diff end addr for aesni_gcm_enc_avx_gen2 v: 0xffffffff81083e76 k: 0xffffffff8107e943 0xffffffff81083e80: diff end addr for aesni_gcm_dec_avx_gen2 v: 0xffffffff81089611 k: 0xffffffff81083ef3 0xffffffff81089990: diff end addr for aesni_gcm_enc_avx_gen4 v: 0xffffffff8108e7c4 k: 0xffffffff81089a03 0xffffffff8108e7d0: diff end addr for aesni_gcm_dec_avx_gen4 v: 0xffffffff810937ef k: 0xffffffff8108e843 Maps only in vmlinux: ffffffff81d5e000-ffffffff81ec3ac8 115e000 [kernel].init.text ffffffff81ec3ac8-ffffffffa0000000 12c3ac8 [kernel].exit.text Maps in vmlinux with a different name in kallsyms: Maps only in kallsyms: test child finished with -1 ---- end ---- vmlinux symtab matches kallsyms: FAILED! # Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 8e0cf965 ("perf symbols: Add support for reading from /proc/kcore") Link: http://lkml.kernel.org/n/tip-n6vrwt9t89w8k769y349govx@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit 332a5b44 upstream. In the current implementation functionfs generates a EFAULT for async read operations if the read buffer size is larger than the URB data size. Since a application does not necessarily know how much data the host side is going to send it typically supplies a buffer larger than the actual data, which will then result in a EFAULT error. This behaviour was introduced while refactoring the code to use iov_iter interface in commit c993c39b ("gadget/function/f_fs.c: use put iov_iter into io_data"). The original code took the minimum over the URB size and the user buffer size and then attempted to copy that many bytes using copy_to_user(). If copy_to_user() could not copy all data a EFAULT error was generated. Restore the original behaviour by only generating a EFAULT error when the number of bytes copied is not the size of the URB and the target buffer has not been fully filled. Commit 342f39a6 ("usb: gadget: f_fs: fix check in read operation") already fixed the same problem for the synchronous read path. Fixes: c993c39b ("gadget/function/f_fs.c: use put iov_iter into io_data") Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Daniel Borkmann authored
commit 47e27d5e upstream. The original tokenized iid support implemented via f53adae4 ("net: ipv6: add tokenized interface identifier support") didn't allow for clearing a device token as it was intended that this addressing mode was the only one active for globally scoped IPv6 addresses. Later we relaxed that restriction via 617fe29d ("net: ipv6: only invalidate previously tokenized addresses"), and we should also allow for clearing tokens as there's no good reason why it shouldn't be allowed. Fixes: 617fe29d ("net: ipv6: only invalidate previously tokenized addresses") Reported-by:
Robin H. Johnson <robbat2@gentoo.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Dan Carpenter authored
commit 60587bd0 upstream. The "handled" variable could be uninitialized if the interrupt_service_routine() call back hasn't been implimented or if it has been implemented but doesn't initialize "handled" to zero at the start. For example, adv76xx_isr() only sets "handled" to true. Fixes: 44b153ca ('[media] m5mols: Add ISO sensitivity controls') Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Dan Carpenter authored
commit e4bccada upstream. If we are doing V4L2_FIELD_NONE then "ret" is used uninitialized. Fixes: 417d2e50 ('[media] media: platform: add VPFE capture driver support for AM437X') Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit 0fb50400 upstream. gcc-6 points out an obviously silly comparison in vpfe_get_app_input_index(): drivers/media/platform/am437x/am437x-vpfe.c: In function 'vpfe_get_app_input_index': drivers/media/platform/am437x/am437x-vpfe.c:1709:27: warning: self-comparison always evaluats to true [-Wtautological-compare] client->adapter->nr == client->adapter->nr) { ^~ This was introduced in a slighly incorrect conversion, and it's clear that the comparison was meant to compare the iterator to the current subdev instead, as we do in the line above. Fixes: d3723239 ("[media] media: am437x-vpfe: match the OF node/i2c addr instead of name") Signed-off-by:
-
Dan Carpenter authored
commit 22aab38e upstream. Instead to being true/false, the "handled" is true/uninitialized. Presumably this doesn't cause that many problems in real life because normally we handle the IRQ. Fixes: eea6b7cc ('mfd: Add lp8788 mfd driver') Signed-off-by:
Milo Kim <milo.kim@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Paolo Abeni authored
commit 3c9d6296 upstream. The skb_owned_by hook was added with the commit ca10b9e9 ("selinux: add a skb_owned_by() hook") and later removed when said commit was reverted. Later on, when switching to list of hooks, a field named 'skb_owned_by' was included into the security_hook_head struct, but without any users nor caller. This commit removes the said left-over field. Fixes: b1d9e6b0 ("LSM: Switch to lists of hooks") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Acked-by:
Paul Moore <pmoore@paul-moore.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Suman Anna authored
commit c20c8f75 upstream. The omap_hwmod _enable() function can return success without setting the hwmod state to _HWMOD_STATE_ENABLED for IPs with reset lines when all of the reset lines are asserted. The omap_hwmod _idle() function also performs a similar check, but after checking for the hwmod state first. This triggers the WARN when pm_runtime_get and pm_runtime_put are invoked on IPs with all reset lines asserted. Reverse the checks for hwmod state and reset lines status to fix this. Issue found during a unbind operation on a device with reset lines still asserted, example backtrace below ------------[ cut here ]------------ WARNING: CPU: 1 PID: 879 at arch/arm/mach-omap2/omap_hwmod.c:2207 _idle+0x1e4/0x240() omap_hwmod: mmu_dsp: idle state can only be entered from enabled state Modules linked in: CPU: 1 PID: 879 Comm: sh Not tainted 4.4.0-00008-ga989d951331a #3 Hardware name: Generic OMAP5 (Flattened Device Tree) [<c0018e60>] (unwind_backtrace) from [<c0014dc4>] (show_stack+0x10/0x14) [<c0014dc4>] (show_stack) from [<c037ac28>] (dump_stack+0x90/0xc0) [<c037ac28>] (dump_stack) from [<c003f420>] (warn_slowpath_common+0x78/0xb4) [<c003f420>] (warn_slowpath_common) from [<c003f48c>] (warn_slowpath_fmt+0x30/0x40) [<c003f48c>] (warn_slowpath_fmt) from [<c0028c20>] (_idle+0x1e4/0x240) [<c0028c20>] (_idle) from [<c0029080>] (omap_hwmod_idle+0x28/0x48) [<c0029080>] (omap_hwmod_idle) from [<c002a5a4>] (omap_device_idle+0x3c/0x90) [<c002a5a4>] (omap_device_idle) from [<c0427a90>] (__rpm_callback+0x2c/0x60) [<c0427a90>] (__rpm_callback) from [<c0427ae4>] (rpm_callback+0x20/0x80) [<c0427ae4>] (rpm_callback) from [<c0427f84>] (rpm_suspend+0x138/0x74c) [<c0427f84>] (rpm_suspend) from [<c0428b78>] (__pm_runtime_idle+0x78/0xa8) [<c0428b78>] (__pm_runtime_idle) from [<c041f514>] (__device_release_driver+0x64/0x100) [<c041f514>] (__device_release_driver) from [<c041f5d0>] (device_release_driver+0x20/0x2c) [<c041f5d0>] (device_release_driver) from [<c041d85c>] (unbind_store+0x78/0xf8) [<c041d85c>] (unbind_store) from [<c0206df8>] (kernfs_fop_write+0xc0/0x1c4) [<c0206df8>] (kernfs_fop_write) from [<c018a120>] (__vfs_write+0x20/0xdc) [<c018a120>] (__vfs_write) from [<c018a9cc>] (vfs_write+0x90/0x164) [<c018a9cc>] (vfs_write) from [<c018b1f0>] (SyS_write+0x44/0x9c) [<c018b1f0>] (SyS_write) from [<c0010420>] (ret_fast_syscall+0x0/0x1c) ---[ end trace a4182013c75a9f50 ]--- While at this, fix the sequence in _shutdown() as well, though there is no easy reproducible scenario. Fixes: 747834ab ("ARM: OMAP2+: hwmod: revise hardreset behavior") Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Dan Carpenter authored
commit b9223da4 upstream. We accidentally free "micro_ac_power" which is an error pointer and it leads to an oops. We intended to free "micro_batt_power". Fixes: a2c1d531 ('power_supply: ipaq_micro_battery: Check return values in probe') Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Alex Williamson authored
commit a0fe14d7 upstream. Remove new line in error logs, avoid duplicate and explicit pr_fmt. Suggested-by:
Joe Perches <joe@perches.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Fixes: 0ac2491f ('x86, dmar: move page fault handling code to dmar.c') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Alex Williamson authored
commit c43fce4e upstream. Fault rates can easily overwhelm the console and make the system unresponsive. Ratelimit to allow an opportunity for maintenance. Signed-off-by:
-
Luis de Bethencourt authored
commit 8cb359e3 upstream. The members buffer_group and attrs of iio_buffer_access_funcs have no descriptions for the documentation. Adding them. Fixes: 08e7e0ad ("iio: buffer: Allocate standard attributes in the core") Signed-off-by:
Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Geert Uytterhoeven authored
commit 834392a7 upstream. uart_write_console() never existed, not even when the "new uart_write_console function" was documented. Fixes: 67ab7f59 ("[SERIAL] Update serial driver documentation") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Heinrich Schuchardt authored
commit fc5c796e upstream. Commit 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") created the new file kirkwood-ds112.dts but did not add it to the Makefile. Fixes: 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Andrew F. Davis authored
commit 267c8586 upstream. Setting the flag 'cache_bypass' will bypass the cache not the hardware. Fix this comment here. Fixes: 0eef6b04 ("regmap: Fix doc comment") Signed-off-by:
Andrew F. Davis <afd@ti.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Mikulas Patocka authored
commit 037369b8 upstream. The HPFS filesystem used generic_show_options to produce string that is displayed in /proc/mounts. However, there is a problem that the options may disappear after remount. If we mount the filesystem with option1 and then remount it with option2, /proc/mounts should show both option1 and option2, however it only shows option2 because the whole option string is replaced with replace_mount_options in hpfs_remount_fs. To fix this bug, implement the hpfs_show_options function that prints options that are currently selected. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mikulas Patocka authored
commit 01d6e087 upstream. Commit c8f33d0b ("affs: kstrdup() memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: c8f33d0b ("affs: kstrdup() memory handling") Signed-off-by:
-
Mikulas Patocka authored
commit 44d51706 upstream. Commit ce657611 ("hpfs: kstrdup() out of memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: ce657611 ("hpfs: kstrdup() out of memory handling") Signed-off-by:
-
Harvey Hunt authored
commit aedcfbe0 upstream. On certain MIPS32 devices, the ftrace tracer "function_graph" uses __lshrdi3() during the capturing of trace data. ftrace then attempts to trace __lshrdi3() which leads to infinite recursion and a stack overflow. Fix this by marking __lshrdi3() as notrace. Mark the other compiler intrinsics as notrace in case the compiler decides to use them in the ftrace path. Signed-off-by:
Harvey Hunt <harvey.hunt@imgtec.com> Cc: <linux-mips@linux-mips.org> Cc: <linux-kernel@vger.kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/13354/Signed-off-by:
-
Manfred Schlaegl authored
commit f49cf3b8 upstream. Pwm config may sleep so defer it using a worker. On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0. Signed-off-by:
Manfred Schlaegl <manfred.schlaegl@gmx.at> Signed-off-by:
-
Cameron Gutman authored
commit 1ff5fa3c upstream. After initially connecting a wired Xbox 360 controller or sending it a command to change LEDs, a status/response packet is interpreted as controller input. This causes the state of buttons represented in byte 2 of the controller data packet to be incorrect until the next valid input packet. Wireless Xbox 360 controllers are not affected. Writing a new value to the LED device while holding the Start button and running jstest is sufficient to reproduce this bug. An event will come through with the Start button released. Xboxdrv also won't attempt to read controller input from a packet where byte 0 is non-zero. It also checks that byte 1 is 0x14, but that value differs between wired and wireless controllers and this code is shared by both. I think just checking byte 0 is enough to eliminate unwanted packets. The following are some examples of 3-byte status packets I saw: 01 03 02 02 03 00 03 03 03 08 03 00 Signed-off-by:
Cameron Gutman <aicommander@gmail.com> Signed-off-by:
Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by:
-
Gabriele Mazzotta authored
commit ff865123 upstream. Some BIOSes unconditionally send an ACPI notification to RBTN when the system is resuming from suspend. This makes dell-rbtn send an input event to userspace as if a function key was pressed. Prevent this by ignoring all the notifications received while the device is suspended. Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031Signed-off-by:
Gabriele Mazzotta <gabriele.mzt@gmail.com> Tested-by:
Alex Hung <alex.hung@canonical.com> Reviewed-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit 3017cd63 upstream. With netconsole (at least) the pr_err("... disablingn") call can recurse back into the dma-debug code, where it'll try to grab free_entries_lock again. Avoid the problem by doing the printk after dropping the lock. Link: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Mario Kleiner authored
commit 9d746ab6 upstream. When porting the hdmi deep color detection code from radeon-kms to amdgpu-kms apparently some kind of copy and paste error happened, attaching an else branch to the wrong if statement. The result is that hdmi deep color mode is always disabled, regardless of gpu and display capabilities and user wishes, as the code mistakenly thinks that the display doesn't provide the required max_tmds_clock limit and falls back to 8 bpc. This patch fixes deep color support, as tested on a R9 380 Tonga Pro + suitable display, and should be backported to all kernels with amdgpu-kms support. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Richard Weinberger authored
commit 1900149c upstream. Ezequiel reported that he's facing UBI going into read-only mode after power cut. It turned out that this behavior happens only when updating a static volume is interrupted and Fastmap is used. A possible trace can look like: ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012 0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841 ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6 ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0 Call Trace: [<ffffffff8140d841>] dump_stack+0x63/0x82 [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi] [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi] [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi] [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi] [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0 [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300 [<ffffffff8124afe0>] ? cdev_put+0x30/0x30 [<ffffffff81244d36>] vfs_open+0x56/0x60 [<ffffffff812545f4>] path_openat+0x4f4/0x1190 [<ffffffff81256621>] do_filp_open+0x91/0x100 [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190 [<ffffffff812450df>] do_sys_open+0x13f/0x210 [<ffffffff812451ce>] SyS_open+0x1e/0x20 [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4 UBI checks static volumes for data consistency and reads the whole volume upon first open. If the volume is found erroneous users of UBI cannot read from it, but another volume update is possible to fix it. The check is performed by running ubi_eba_read_leb() on every allocated LEB of the volume. For static volumes ubi_eba_read_leb() computes the checksum of all data stored in a LEB. To verify the computed checksum it has to read the LEB's volume header which stores the original checksum. If the volume header is not found UBI treats this as fatal internal error and switches to RO mode. If the UBI device was attached via a full scan the assumption is correct, the volume header has to be present as it had to be there while scanning to get known as mapped. If the attach operation happened via Fastmap the assumption is no longer correct. When attaching via Fastmap UBI learns the mapping table from Fastmap's snapshot of the system state and not via a full scan. It can happen that a LEB got unmapped after a Fastmap was written to the flash. Then UBI can learn the LEB still as mapped and accessing it returns only 0xFF bytes. As UBI is not a FTL it is allowed to have mappings to empty PEBs, it assumes that the layer above takes care of LEB accounting and referencing. UBIFS does so using the LEB property tree (LPT). For static volumes UBI blindly assumes that all LEBs are present and therefore special actions have to be taken. The described situation can happen when updating a static volume is interrupted, either by a user or a power cut. The volume update code first unmaps all LEBs of a volume and then writes LEB by LEB. If the sequence of operations is interrupted UBI detects this either by the absence of LEBs, no volume header present at scan time, or corrupted payload, detected via checksum. In the Fastmap case the former method won't trigger as no scan happened and UBI automatically thinks all LEBs are present. Only by reading data from a LEB it detects that the volume header is missing and incorrectly treats this as fatal error. To deal with the situation ubi_eba_read_leb() from now on checks whether we attached via Fastmap and handles the absence of a volume header like a data corruption error. This way interrupted static volume updates will correctly get detected also when Fastmap is used. Reported-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
