commit 83fdace666f72dbfc4a7681a04e3689b61dae3b9 Author: Sasha Levin Date: Mon Feb 15 15:46:24 2016 -0500 Linux 4.1.18 Signed-off-by: Sasha Levin commit 0479b826457382c39d369acc95347621a347414e Author: David Howells Date: Fri Sep 25 16:31:46 2015 +0100 X.509: Don't strip leading 00's from key ID when constructing key description [ Upstream commit e7c87bef7de2417b219d4dbfe8d33a0098a8df54 ] Don't strip leading zeros from the crypto key ID when using it to construct the struct key description as the signature in kernels up to and including 4.2 matched this aspect of the key. This means that 1 in 256 keys won't actually match if their key ID begins with 00. The key ID is stored in the module signature as binary and so must be converted to text in order to invoke request_key() - but it isn't stripped at this point. Something like this is likely to be observed in dmesg when the key is loaded: [ 1.572423] Loaded X.509 cert 'Build time autogenerated kernel key: 62a7c3d2da278be024da4af8652c071f3fea33' followed by this when we try and use it: [ 1.646153] Request for unknown module key 'Build time autogenerated kernel key: 0062a7c3d2da278be024da4af8652c071f3fea33' err -11 The 'Loaded' line should show an extra '00' on the front of the hex string. This problem should not affect 4.3-rc1 and onwards because there the key should be matched on one of its auxiliary identities rather than the key struct's description string. Reported-by: Arjan van de Ven Reported-by: Andy Whitcroft Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 42362e1f5a73d36fcaf3eb4950dfc17f633ea0d3 Author: Konstantin Khlebnikov Date: Fri Feb 5 15:37:01 2016 -0800 radix-tree: fix oops after radix_tree_iter_retry [ Upstream commit 732042821cfa106b3c20b9780e4c60fee9d68900 ] Helper radix_tree_iter_retry() resets next_index to the current index. In following radix_tree_next_slot current chunk size becomes zero. This isn't checked and it tries to dereference null pointer in slot. Tagged iterator is fine because retry happens only at slot 0 where tag bitmask in iter->tags is filled with single bit. Fixes: 46437f9a554f ("radix-tree: fix race in gang lookup") Signed-off-by: Konstantin Khlebnikov Cc: Matthew Wilcox Cc: Hugh Dickins Cc: Ohad Ben-Cohen Cc: Jeremiah Mahler Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4b5eaa857d64ea737c3bed1eb9b3dd201dd2cecf Author: Konstantin Khlebnikov Date: Fri Feb 5 15:36:50 2016 -0800 mm: replace vma_lock_anon_vma with anon_vma_lock_read/write [ Upstream commit 12352d3cae2cebe18805a91fab34b534d7444231 ] Sequence vma_lock_anon_vma() - vma_unlock_anon_vma() isn't safe if anon_vma appeared between lock and unlock. We have to check anon_vma first or call anon_vma_prepare() to be sure that it's here. There are only few users of these legacy helpers. Let's get rid of them. This patch fixes anon_vma lock imbalance in validate_mm(). Write lock isn't required here, read lock is enough. And reorders expand_downwards/expand_upwards: security_mmap_addr() and wrapping-around check don't have to be under anon vma lock. Link: https://lkml.kernel.org/r/CACT4Y+Y908EjM2z=706dv4rV6dWtxTLK9nFg9_7DhRMLppBo2g@mail.gmail.com Signed-off-by: Konstantin Khlebnikov Reported-by: Dmitry Vyukov Acked-by: Kirill A. Shutemov Cc: Andrea Arcangeli Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ff5ecd2953a635bf70101dac550fcb01ced863e9 Author: xuejiufei Date: Fri Feb 5 15:36:47 2016 -0800 ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup [ Upstream commit c95a51807b730e4681e2ecbdfd669ca52601959e ] When recovery master down, dlm_do_local_recovery_cleanup() only remove the $RECOVERY lock owned by dead node, but do not clear the refmap bit. Which will make umount thread falling in dead loop migrating $RECOVERY to the dead node. Signed-off-by: xuejiufei Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8a4ebc74857af2377d9b3f756714ded686e01b66 Author: Eric Dumazet Date: Fri Feb 5 15:36:16 2016 -0800 dump_stack: avoid potential deadlocks [ Upstream commit d7ce36924344ace0dbdc855b1206cacc46b36d45 ] Some servers experienced fatal deadlocks because of a combination of bugs, leading to multiple cpus calling dump_stack(). The checksumming bug was fixed in commit 34ae6a1aa054 ("ipv6: update skb->csum when CE mark is propagated"). The second problem is a faulty locking in dump_stack() CPU1 runs in process context and calls dump_stack(), grabs dump_lock. CPU2 receives a TCP packet under softirq, grabs socket spinlock, and call dump_stack() from netdev_rx_csum_fault(). dump_stack() spins on atomic_cmpxchg(&dump_lock, -1, 2), since dump_lock is owned by CPU1 While dumping its stack, CPU1 is interrupted by a softirq, and happens to process a packet for the TCP socket locked by CPU2. CPU1 spins forever in spin_lock() : deadlock Stack trace on CPU1 looked like : NMI backtrace for cpu 1 RIP: _raw_spin_lock+0x25/0x30 ... Call Trace: tcp_v6_rcv+0x243/0x620 ip6_input_finish+0x11f/0x330 ip6_input+0x38/0x40 ip6_rcv_finish+0x3c/0x90 ipv6_rcv+0x2a9/0x500 process_backlog+0x461/0xaa0 net_rx_action+0x147/0x430 __do_softirq+0x167/0x2d0 call_softirq+0x1c/0x30 do_softirq+0x3f/0x80 irq_exit+0x6e/0xc0 smp_call_function_single_interrupt+0x35/0x40 call_function_single_interrupt+0x6a/0x70 printk+0x4d/0x4f printk_address+0x31/0x33 print_trace_address+0x33/0x3c print_context_stack+0x7f/0x119 dump_trace+0x26b/0x28e show_trace_log_lvl+0x4f/0x5c show_stack_log_lvl+0x104/0x113 show_stack+0x42/0x44 dump_stack+0x46/0x58 netdev_rx_csum_fault+0x38/0x3c __skb_checksum_complete_head+0x6e/0x80 __skb_checksum_complete+0x11/0x20 tcp_rcv_established+0x2bd5/0x2fd0 tcp_v6_do_rcv+0x13c/0x620 sk_backlog_rcv+0x15/0x30 release_sock+0xd2/0x150 tcp_recvmsg+0x1c1/0xfc0 inet_recvmsg+0x7d/0x90 sock_recvmsg+0xaf/0xe0 ___sys_recvmsg+0x111/0x3b0 SyS_recvmsg+0x5c/0xb0 system_call_fastpath+0x16/0x1b Fixes: b58d977432c8 ("dump_stack: serialize the output from dump_stack()") Signed-off-by: Eric Dumazet Cc: Alex Thorlton Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9e3ba11cb727f20a2aa74e90f1858c7c49ed8e64 Author: Daniel Vetter Date: Thu Jul 9 23:44:31 2015 +0200 drm/i915: Take all modeset locks for DP MST hotplug [ Upstream commit 8bb4da1df54a20d68c34427356e34315ba122c0f ] While auditing various users of the connector/encoder lists I realized that the atomic code is a very prolific user of them. And it only ever grabs the mode_config->connection_mutex, but not the mode_config->mutex like all the other code walking encoder/connector lists. The problem is that we can't grab the mode_config.mutex late in atomic code since that would lead to locking inversions. And we don't want to grab it unconditionally like the legacy set_config modeset path since that would render all the fine-grained locking moot. Instead just grab more locks in the dp mst hotplug code. Note that drm_connector_init (which is the one adding the connector to these lists) already uses drm_modeset_lock_all. The other reason for grabbing all locks is that the dpms off in the unplug function amounts to a modeset, so better to take all required locks for that. Reviewed-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit fde3cda03b3f681ecf3d92a56f045104174493e3 Author: Daniel Vetter Date: Thu Jul 9 23:44:32 2015 +0200 drm/radeon: Take all modeset locks for DP MST hotplug [ Upstream commit 2ee6bcdcfa4d8b56b20bc6308cd5f9bced5b5324 ] Similar with the i915 take all modeset locks for mst hotplug. This is needed to make sure radeon holds both mode_config.mutex and mode_config.connection_mutex when updating the connector_list, which is the new (interim) locking regime we want for that. Reviewed-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit 06f4d7cebea5027bd8773df0557c6bbaaf2c77a2 Author: Dave Airlie Date: Wed Sep 16 10:37:28 2015 +1000 drm/dp/mst: fixup handling hotplug on port removal. [ Upstream commit df4839fdc9b3c922586b945f062f38cbbda022bb ] output ports should always have a connector, unless in the rare case connector allocation fails in the driver. In this case we only need to teardown the pdt, and free the struct, and there is no need to send a hotplug msg. In the case were we add the port to the destroy list we need to send a hotplug if we destroy any connectors, so userspace knows to reprobe stuff. this patch also handles port->connector allocation failing which should be a rare event, but makes the code consistent. Reviewed-by: Daniel Vetter Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 7d1dc93a85c3593f35985b78ab5325085c2fa2e6 Author: Maarten Lankhorst Date: Tue Aug 11 09:54:29 2015 +0200 drm/dp/mst: Remove port after removing connector. [ Upstream commit 4772ff03df8094fd99d28de5fcf5df3a3e9c68bb ] The port is removed synchronously, but the connector delayed. This causes a use after free which can cause a kernel BUG with slug_debug=FPZU. This is fixed by freeing the port after the connector. This fixes a regression introduced with 6b8eeca65b18ae77e175cc2b6571731f0ee413bf "drm/dp/mst: close deadlock in connector destruction." Cc: stable@vger.kernel.org Cc: Dave Airlie Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 95b098789dd20a09885c288fe8db200c26490c18 Author: Harry Wentland Date: Fri Jan 22 17:07:26 2016 -0500 drm/dp/mst: Calculate MST PBN with 31.32 fixed point [ Upstream commit a9ebb3e46c7ef6112c0da466ef0954673ad36832 ] Our PBN value overflows the 20 bits integer part of the 20.12 fixed point. We need to use 31.32 fixed point to avoid this. This happens with display clocks larger than 293122 (at 24 bpp), which we see with the Sharp (and similar) 4k tiled displays. Signed-off-by: Harry Wentland Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit bd31f0f4dfa04f1afe2ac88b32a745dad80718e2 Author: Harry Wentland Date: Fri Jan 22 17:07:25 2016 -0500 drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil [ Upstream commit 64566b5e767f9bc3161055ca1b443a51afb52aad ] drm_fixp_from_fraction allows us to create a fixed point directly from a fraction, rather than creating fixed point values and dividing later. This avoids overflow of our 64 bit value for large numbers. drm_fixp2int_ceil allows us to return the ceiling of our fixed point value. [airlied: squash Jordan's fix] 32-bit-build-fix: Jordan Lazare Signed-off-by: Harry Wentland Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 81c5fe348992a0896473724c556b6632b8acd4a7 Author: Insu Yun Date: Mon Feb 1 11:08:29 2016 -0500 drm: fix missing reference counting decrease [ Upstream commit dabe19540af9e563d526113bb102e1b9b9fa73f9 ] In drm_dp_mst_allocate_vcpi, it returns true in two paths, but in one path, there is no reference couting decrease. Signed-off-by: Insu Yun Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit df2aeb317e3e6d1da2de045748064df63bc11944 Author: Linus Walleij Date: Mon Feb 1 14:18:57 2016 +0100 ARM: nomadik: fix up SD/MMC DT settings [ Upstream commit 418d5516568b3fdbc4e7b53677dd78aed8514565 ] The DTSI file for the Nomadik does not properly specify how the PL180 levelshifter is connected: the Nomadik actually needs all the five st,sig-dir-* flags set to properly control all lines out. Further this board supports full power cycling of the card, and since this variant has no hardware clock gating, it needs a ridiculously low frequency setting to keep up with the ever overflowing FIFO. The pin configuration set-up is a bit of a mystery, because of course these pins are a mix of inputs and outputs. However the reference implementation sets all pins to "output" with unspecified initial value, so let's do that here as well. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Acked-by: Ulf Hansson Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit aec01beb5eed22fed5291dc73f9b5f70c4d34218 Author: Mauro Carvalho Chehab Date: Thu Feb 4 15:59:43 2016 -0200 [media] saa7134-alsa: Only frees registered sound cards [ Upstream commit ac75fe5d8fe4a0bf063be18fb29684405279e79e ] That prevents this bug: [ 2382.269496] BUG: unable to handle kernel NULL pointer dereference at 0000000000000540 [ 2382.270013] IP: [] snd_card_free+0x36/0x70 [snd] [ 2382.270013] PGD 0 [ 2382.270013] Oops: 0002 [#1] SMP [ 2382.270013] Modules linked in: saa7134_alsa(-) tda1004x saa7134_dvb videobuf2_dvb dvb_core tda827x tda8290 tuner saa7134 tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc tun bridge stp llc ebtables ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack it87 hwmon_vid snd_hda_codec_idt snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq pcspkr i2c_i801 snd_seq_device snd_pcm snd_timer lpc_ich snd mfd_core soundcore binfmt_misc i915 video i2c_algo_bit drm_kms_helper drm r8169 ata_generic serio_raw pata_acpi mii i2c_core [last unloaded: videobuf2_memops] [ 2382.270013] CPU: 0 PID: 4899 Comm: rmmod Not tainted 4.5.0-rc1+ #4 [ 2382.270013] Hardware name: PCCHIPS P17G/P17G, BIOS 080012 05/14/2008 [ 2382.270013] task: ffff880039c38000 ti: ffff88003c764000 task.ti: ffff88003c764000 [ 2382.270013] RIP: 0010:[] [] snd_card_free+0x36/0x70 [snd] [ 2382.270013] RSP: 0018:ffff88003c767ea0 EFLAGS: 00010286 [ 2382.270013] RAX: ffff88003c767eb8 RBX: 0000000000000000 RCX: 0000000000006260 [ 2382.270013] RDX: ffffffffa020a060 RSI: ffffffffa0206de1 RDI: ffff88003c767eb0 [ 2382.270013] RBP: ffff88003c767ed8 R08: 0000000000019960 R09: ffffffff811a5412 [ 2382.270013] R10: ffffea0000d7c200 R11: 0000000000000000 R12: ffff88003c767ea8 [ 2382.270013] R13: 00007ffe760617f7 R14: 0000000000000000 R15: 0000557625d7f1e0 [ 2382.270013] FS: 00007f80bb1c0700(0000) GS:ffff88003f400000(0000) knlGS:0000000000000000 [ 2382.270013] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 2382.270013] CR2: 0000000000000540 CR3: 000000003c00f000 CR4: 00000000000006f0 [ 2382.270013] Stack: [ 2382.270013] 000000003c767ed8 ffffffff00000000 ffff880000000000 ffff88003c767eb8 [ 2382.270013] ffff88003c767eb8 ffffffffa049a890 00007ffe76060060 ffff88003c767ef0 [ 2382.270013] ffffffffa049889d ffffffffa049a500 ffff88003c767f48 ffffffff8111079c [ 2382.270013] Call Trace: [ 2382.270013] [] saa7134_alsa_exit+0x1d/0x780 [saa7134_alsa] [ 2382.270013] [] SyS_delete_module+0x19c/0x1f0 [ 2382.270013] [] entry_SYSCALL_64_fastpath+0x12/0x71 [ 2382.270013] Code: 20 a0 48 c7 c6 e1 6d 20 a0 48 89 e5 41 54 53 4c 8d 65 d0 48 89 fb 48 83 ec 28 c7 45 d0 00 00 00 00 49 8d 7c 24 08 e8 7a 55 ed e0 <4c> 89 a3 40 05 00 00 48 89 df e8 eb fd ff ff 85 c0 75 1a 48 8d [ 2382.270013] RIP [] snd_card_free+0x36/0x70 [snd] [ 2382.270013] RSP [ 2382.270013] CR2: 0000000000000540 Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 451e9d9111a2c83d46cdd48d5eea2fa8e8d72d9a Author: Takashi Iwai Date: Thu Feb 4 17:06:13 2016 +0100 ALSA: timer: Fix leftover link at closing [ Upstream commit 094fd3be87b0f102589e2d5c3fa5d06b7e20496d ] In ALSA timer core, the active timer instance is managed in active_list linked list. Each element is added / removed dynamically at timer start, stop and in timer interrupt. The problem is that snd_timer_interrupt() has a thinko and leaves the element in active_list when it's the last opened element. This eventually leads to list corruption or use-after-free error. This hasn't been revealed because we used to delete the list forcibly in snd_timer_stop() in the past. However, the recent fix avoids the double-stop behavior (in commit [f784beb75ce8: ALSA: timer: Fix link corruption due to double start or stop]), and this leak hits reality. This patch fixes the link management in snd_timer_interrupt(). Now it simply unlinks no matter which stream is. BugLink: http://lkml.kernel.org/r/CACT4Y+Yy2aukHP-EDp8-ziNqNNmb-NTf=jDWXMP7jB8HDa2vng@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b35f45f2ebf224e06836ced6ccebb05ec700a6a9 Author: Mauro Carvalho Chehab Date: Wed Feb 3 17:33:48 2016 -0200 [media] tda1004x: only update the frontend properties if locked [ Upstream commit e8beb02343e7582980c6705816cd957cf4f74c7a ] The tda1004x was updating the properties cache before locking. If the device is not locked, the data at the registers are just random values with no real meaning. This caused the driver to fail with libdvbv5, as such library calls GET_PROPERTY from time to time, in order to return the DVB stats. Tested with a saa7134 card 78: ASUSTeK P7131 Dual, vendor PCI ID: 1043:4862 Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8552bea30320cc866c7fb5d9a687c3e6d15fb5c1 Author: Mathias Nyman Date: Tue Jan 26 17:50:12 2016 +0200 xhci: Fix list corruption in urb dequeue at host removal [ Upstream commit 5c82171167adb8e4ac77b91a42cd49fb211a81a0 ] xhci driver frees data for all devices, both usb2 and and usb3 the first time usb_remove_hcd() is called, including td_list and and xhci_ring structures. When usb_remove_hcd() is called a second time for the second xhci bus it will try to dequeue all pending urbs, and touches td_list which is already freed for that endpoint. Cc: Reported-by: Joe Lawrence Tested-by: Joe Lawrence Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4c54b01e7221db1d14ef2506ac0b81f9ff69e26f Author: Lu Baolu Date: Tue Jan 26 17:50:08 2016 +0200 usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms [ Upstream commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 ] Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well. Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c6fd1e6a4ffcfaf6fd6409e8fc3ada2e0cbd247d Author: Lu Baolu Date: Tue Jan 26 17:50:07 2016 +0200 usb: xhci: set SSIC port unused only if xhci_suspend succeeds [ Upstream commit 92149c930cce1865d0d4aca2ab07c2b4b197b418 ] XHCI_SSIC_PORT_UNUSED quirk was applied to the xHCI host controllers in some Intel SoC chips. With this quirk applied, SSIC port is set to "unused" prior to xhci_suspend(). This may cause problem if host fails to suspend. In this case, the port is set to unused without host further entering D3, and the port will not be usable anymore. Cc: stable@vger.kernel.org Signed-off-by: Zhuang Jin Can Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1f8ad5557c9910b9853830ef202d092aa43806c9 Author: Lu Baolu Date: Tue Jan 26 17:50:06 2016 +0200 usb: xhci: add a quirk bit for ssic port unused [ Upstream commit 7e70cbffe236721051bbaff965e477df06dcb190 ] Two workarounds introduced by commit b8cb91e058cd ("xhci: Workaround for PME stuck issues in Intel xhci") and commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI") share a single quirk bit XHCI_PME_STUCK_QUIRK. These two workarounds actually are different and might happen on different hardwares. Need to separate them by adding a quirk bit for the later. Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 69b8883209004c05eac885e53f67f37d6b0f8e11 Author: Lu Baolu Date: Tue Jan 26 17:50:05 2016 +0200 usb: xhci: handle both SSIC ports in PME stuck quirk [ Upstream commit fa89537783cb442263fa5a14df6c7693eaf32f11 ] Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI") adds a workaround for a limitation of PME storm caused by SSIC port in some Intel SoCs. This commit only handled one SSIC port, while there are actually two SSIC ports in the chips. This patch handles both SSIC ports. Without this fix, users still see PME storm. Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Zhuang Jin Can Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1c0232f6415b1c1c89f71fd3d98e2b497eaf988b Author: Mathias Nyman Date: Fri Oct 9 13:30:08 2015 +0300 xhci: create one unified function to calculate TRB TD remainder. [ Upstream commit c840d6ce772d47c777070ca4bbbfbf21d8d727a3 ] xhci versions 1.0 and later report the untransferred data remaining in a TD a bit differently than older hosts. We used to have separate functions for these, and needed to check host version before calling the right function. Now Mediatek host has an additional quirk on how it uses the TD Size field for remaining data. To prevent yet another function for calculating remainder we instead want to make one quirk friendly unified function. Tested-by: Chunfeng Yun Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 23159bb315f95c245ccfa9a248f8ecb786dbdc1e Author: Lu, Baolu Date: Fri Oct 9 13:30:10 2015 +0300 usb: xhci: Makefile: move xhci-pci and xhci-plat-hcd after xhci-hcd [ Upstream commit 8451a34ff6c7c756e9e0f0094a3ba856c9734e5d ] Module xhci-pci and xhci-plat-hcd depend on xhci-hcd. Module xhci-hcd should be put at a place before xhci-pci and xhci-plat-hcd. Otherwise, xhci_hcd_init() might be executed after other functions in xhci-hcd if they are all selected to be built in. Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fa91182ea7c3ea6476cf24ced5cb9878216d5f9e Author: Tomer Barletz Date: Mon Sep 21 17:46:11 2015 +0300 xhci: Move xhci_pme_quirk() behind #ifdef CONFIG_PM [ Upstream commit 2b7627b73e81e5d23d5ae1490fe8e690af86e053 ] xhci_pme_quirk() is only used when CONFIG_PM is defined. Compiling a kernel without PM complains about this function [reworded commit message -Mathias] Cc: Signed-off-by: Tomer Barletz Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5d3a10799e1199acef123e57a014b491a12044d4 Author: Mathias Nyman Date: Tue Jul 21 17:20:25 2015 +0300 xhci: call BIOS workaround to enable runtime suspend on Intel Braswell [ Upstream commit c3c5819a350952439c3198aa46581f9e4c46557f ] Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled xhci from going to D3 state in runtime suspend. Driver needs to verify it can deal with the hw by calling an ACPI _DSM method to get D3 enabled. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bba8f524da11a915f37835925cc602eb64383b56 Author: Rajmohan Mani Date: Tue Jul 21 17:20:26 2015 +0300 xhci: Workaround to get D3 working in Intel xHCI [ Upstream commit abce329c27b315cfc01be1a305ee976ee13ed4cf ] The xHCI in Intel CherryView / Braswell Platform requires a driver workaround to get xHCI D3 working. Without this workaround, xHCI might not enter D3. Workaround is to configure SSIC PORT as "unused" before D3 entry and "used" after D3 exit. This is done through a vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset 0x883c), in xhci suspend / resume callbacks. Verified xHCI D3 works fine in CherryView / Braswell platform. Signed-off-by: Rajmohan Mani Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cd3c40afce6cd0209432e6690e60c2156a27c68d Author: Matthew Wilcox Date: Tue Feb 2 16:57:52 2016 -0800 radix-tree: fix race in gang lookup [ Upstream commit 46437f9a554fbe3e110580ca08ab703b59f2f95a ] If the indirect_ptr bit is set on a slot, that indicates we need to redo the lookup. Introduce a new function radix_tree_iter_retry() which forces the loop to retry the lookup by setting 'slot' to NULL and turning the iterator back to point at the problematic entry. This is a pretty rare problem to hit at the moment; the lookup has to race with a grow of the radix tree from a height of 0. The consequences of hitting this race are that gang lookup could return a pointer to a radix_tree_node instead of a pointer to whatever the user had inserted in the tree. Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator") Signed-off-by: Matthew Wilcox Cc: Hugh Dickins Cc: Ohad Ben-Cohen Cc: Konstantin Khlebnikov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 46aef54fb8feb8158bfe0237ecec754ce5003f41 Author: Kirill A. Shutemov Date: Tue Feb 2 16:57:35 2016 -0800 drivers/scsi/sg.c: mark VMA as VM_IO to prevent migration [ Upstream commit 461c7fa126794157484dca48e88effa4963e3af3 ] Reduced testcase: #include #include #include #include #define SIZE 0x2000 int main() { int fd; void *p; fd = open("/dev/sg0", O_RDWR); p = mmap(NULL, SIZE, PROT_EXEC, MAP_PRIVATE | MAP_LOCKED, fd, 0); mbind(p, SIZE, 0, NULL, 0, MPOL_MF_MOVE); return 0; } We shouldn't try to migrate pages in sg VMA as we don't have a way to update Sg_scatter_hold::pages accordingly from mm core. Let's mark the VMA as VM_IO to indicate to mm core that the VMA is not migratable. Signed-off-by: Kirill A. Shutemov Reported-by: Dmitry Vyukov Acked-by: Vlastimil Babka Cc: Doug Gilbert Cc: David Rientjes Cc: Naoya Horiguchi Cc: "Kirill A. Shutemov" Cc: Shiraz Hashim Cc: Hugh Dickins Cc: Sasha Levin Cc: syzkaller Cc: Kostya Serebryany Cc: Alexander Potapenko Cc: James Bottomley Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 44660dacb478f79d7fbc7cec0ef342414b563b6a Author: Takashi Iwai Date: Wed Feb 3 08:32:44 2016 +0100 ALSA: seq: Fix lockdep warnings due to double mutex locks [ Upstream commit 7f0973e973cd74aa40747c9d38844560cd184ee8 ] The port subscription code uses double mutex locks for source and destination ports, and this may become racy once when wrongly set up. It leads to lockdep warning splat, typically triggered by fuzzer like syzkaller, although the actual deadlock hasn't been seen, so far. This patch simplifies the handling by reducing to two single locks, so that no lockdep warning will be trigger any longer. By splitting to two actions, a still-in-progress element shall be added in one list while handling another. For ignoring this element, a new check is added in deliver_to_subscribers(). Along with it, the code to add/remove the subscribers list element was cleaned up and refactored. BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a2c892c31423bdef823c6f6b2d54c159be8f4e20 Author: Takashi Iwai Date: Wed Feb 3 14:41:22 2016 +0100 ALSA: rawmidi: Fix race at copying & updating the position [ Upstream commit 81f577542af15640cbcb6ef68baa4caa610cbbfc ] The rawmidi read and write functions manage runtime stream status such as runtime->appl_ptr and runtime->avail. These point where to copy the new data and how many bytes have been copied (or to be read). The problem is that rawmidi read/write call copy_from_user() or copy_to_user(), and the runtime spinlock is temporarily unlocked and relocked while copying user-space. Since the current code advances and updates the runtime status after the spin unlock/relock, the copy and the update may be asynchronous, and eventually runtime->avail might go to a negative value when many concurrent accesses are done. This may lead to memory corruption in the end. For fixing this race, in this patch, the status update code is performed in the same lock before the temporary unlock. Also, the spinlock is now taken more widely in snd_rawmidi_kernel_read1() for protecting more properly during the whole operation. BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8bd8e5389ea62cdefa03d383daccb6474fef93a6 Author: Takashi Iwai Date: Sun Jan 31 11:57:41 2016 +0100 ALSA: rawmidi: Make snd_rawmidi_transmit() race-free [ Upstream commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 ] A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by syzkaller fuzzer: WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136 [] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163 [< inline >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273 [] __vfs_write+0x113/0x480 fs/read_write.c:528 [] vfs_write+0x167/0x4a0 fs/read_write.c:577 [< inline >] SYSC_write fs/read_write.c:624 [] SyS_write+0x111/0x220 fs/read_write.c:616 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 Also a similar warning is found but in another path: Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133 [] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163 [] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185 [< inline >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302 [] __vfs_write+0x113/0x480 fs/read_write.c:528 [] vfs_write+0x167/0x4a0 fs/read_write.c:577 [< inline >] SYSC_write fs/read_write.c:624 [] SyS_write+0x111/0x220 fs/read_write.c:616 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 In the former case, the reason is that virmidi has an open code calling snd_rawmidi_transmit_ack() with the value calculated outside the spinlock. We may use snd_rawmidi_transmit() in a loop just for consuming the input data, but even there, there is a race between snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack(). Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack() separately without protection, so they are racy as well. The patch tries to address these issues by the following ways: - Introduce the unlocked versions of snd_rawmidi_transmit_peek() and snd_rawmidi_transmit_ack() to be called inside the explicit lock. - Rewrite snd_rawmidi_transmit() to be race-free (the former case). - Make the split calls (the latter case) protected in the rawmidi spin lock. BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d84572ebdb7320ab597f933d8f65df9a9c7f9537 Author: Takashi Iwai Date: Wed Feb 3 12:32:51 2016 +0100 ALSA: hda - Add fixup for Mac Mini 7,1 model [ Upstream commit 2154cc0e2d4ae15132d005d17e473327c70c9a06 ] Mac Mini 7,1 model with CS4208 codec reports the headphone jack detection wrongly in an inverted way. Moreover, the advertised pins for the audio input and SPDIF output have actually no jack detection. This patch addresses these issues. The inv_jack_detect flag is set for fixing the headphone jack detection, and the pin configs for audio input and SPDIF output are marked as non-detectable. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105161 Report-and-tested-by: moosotc@gmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2b374ca06b3bba78733da7968b82330fad7b60ce Author: Oded Gabbay Date: Sat Jan 30 07:59:33 2016 +0200 drm/radeon: mask out WC from BO on unsupported arches [ Upstream commit c5244987394648913ae1a03879c58058a2fc2cee ] Reviewed-by: Christian König Reviewed-by: Michel Dänzer Signed-off-by: Oded Gabbay Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5e92a4058e7035fde9a623b5ca36d862e7677ea6 Author: Michel Dänzer Date: Thu Nov 5 17:25:27 2015 +0900 drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC [ Upstream commit a28bbd5824d4a2af98de45b300ab8d8fb39739fc ] Write-combining is a CPU feature. From the GPU POV, these both simply mean no GPU<->CPU cache coherency. Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2322974c5d55e8be4be4b7cbf8cf996daf72b0bd Author: Dave Airlie Date: Sat Jan 30 07:59:32 2016 +0200 drm: add helper to check for wc memory support [ Upstream commit 4b0e4e4af6c6dc8354dcb72182d52c1bc55f12fc ] Reviewed-by: Christian König Reviewed-by: Michel Dänzer Signed-off-by: Dave Airlie Signed-off-by: Oded Gabbay Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b99c635faf56fa3cbd1cf61632418b06543dc145 Author: Takashi Iwai Date: Sat Jan 30 23:09:08 2016 +0100 ALSA: timer: Fix link corruption due to double start or stop [ Upstream commit f784beb75ce82f4136f8a0960d3ee872f7109e09 ] Although ALSA timer code got hardening for races, it still causes use-after-free error. This is however rather a corrupted linked list, not actually the concurrent accesses. Namely, when timer start is triggered twice, list_add_tail() is called twice, too. This ends up with the link corruption and triggers KASAN error. The simplest fix would be replacing list_add_tail() with list_move_tail(), but fundamentally it's the problem that we don't check the double start/stop correctly. So, the right fix here is to add the proper checks to snd_timer_start() and snd_timer_stop() (and their variants). BugLink: http://lkml.kernel.org/r/CACT4Y+ZyPRoMQjmawbvmCEDrkBD2BQuH7R09=eOkf5ESK8kJAw@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit aef523ec3812f822fdd256f64c0d941a0588647f Author: Takashi Iwai Date: Thu Jan 14 17:01:46 2016 +0100 ALSA: timer: Code cleanup [ Upstream commit c3b1681375dc6e71d89a3ae00cc3ce9e775a8917 ] This is a minor code cleanup without any functional changes: - Kill keep_flag argument from _snd_timer_stop(), as all callers pass only it false. - Remove redundant NULL check in _snd_timer_stop(). Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b55a0342e88343fbca10e8a1ac5f6aa1c001f40f Author: Takashi Iwai Date: Sat Jan 30 23:30:25 2016 +0100 ALSA: seq: Fix yet another races among ALSA timer accesses [ Upstream commit 2cdc7b636d55cbcf42e1e6c8accd85e62d3e9ae8 ] ALSA sequencer may open/close and control ALSA timer instance dynamically either via sequencer events or direct ioctls. These are done mostly asynchronously, and it may call still some timer action like snd_timer_start() while another is calling snd_timer_close(). Since the instance gets removed by snd_timer_close(), it may lead to a use-after-free. This patch tries to address such a race by protecting each snd_timer_*() call via the existing spinlock and also by avoiding the access to timer during close call. BugLink: http://lkml.kernel.org/r/CACT4Y+Z6RzW5MBr-HUdV-8zwg71WQfKTdPpYGvOeS7v4cyurNQ@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 666f365e85209f799819793d475cd7cde98a2be2 Author: Takashi Iwai Date: Sun Jan 31 10:32:37 2016 +0100 ALSA: pcm: Fix potential deadlock in OSS emulation [ Upstream commit b248371628aad599a48540962f6b85a21a8a0c3f ] There are potential deadlocks in PCM OSS emulation code while accessing read/write and mmap concurrently. This comes from the infamous mmap_sem usage in copy_from/to_user(). Namely, snd_pcm_oss_write() -> &runtime->oss.params_lock -> copy_to_user() -> &mm->mmap_sem mmap() -> &mm->mmap_sem -> snd_pcm_oss_mmap() -> &runtime->oss.params_lock Since we can't avoid taking params_lock from mmap code path, use trylock variant and aborts with -EAGAIN as a workaround of this AB/BA deadlock. BugLink: http://lkml.kernel.org/r/CACT4Y+bVrBKDG0G2_AcUgUQa+X91VKTeS4v+wN7BSHwHtqn3kQ@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 216b6d4f24b88ab70c58e0574e30b8da1b2b053b Author: Takashi Iwai Date: Mon Feb 1 12:04:55 2016 +0100 ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check [ Upstream commit cc85f7a634cfaf9f0713c6aa06d08817424db37a ] NULL user-space buffer can be passed even in a normal path, thus it's not good to spew a kernel warning with stack trace at each time. Just drop snd_BUG_ON() macro usage there. BugLink: http://lkml.kernel.org/r/CACT4Y+YfVJ3L+q0i-4vyQVyyPD7V=OMX0PWPi29x9Bo3QaBLdw@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 81bce29eec26617db18ff21543c7a091b5c10c92 Author: Takashi Iwai Date: Mon Feb 1 12:06:42 2016 +0100 ALSA: seq: Fix race at closing in virmidi driver [ Upstream commit 2d1b5c08366acd46c35a2e9aba5d650cb5bf5c19 ] The virmidi driver has an open race at closing its assigned rawmidi device, and this may lead to use-after-free in snd_seq_deliver_single_event(). Plug the hole by properly protecting the linked list deletion and calling in the right order in snd_virmidi_input_close(). BugLink: http://lkml.kernel.org/r/CACT4Y+Zd66+w12fNN85-425cVQT=K23kWbhnCEcMB8s3us-Frw@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bd92b10c95b37a4d6c043ad76d51d13dee45c477 Author: Wang, Rui Y Date: Wed Jan 27 17:08:37 2016 +0800 crypto: algif_hash - wait for crypto_ahash_init() to complete [ Upstream commit fe09786178f9df713a4b2dd6b93c0a722346bf5e ] hash_sendmsg/sendpage() need to wait for the completion of crypto_ahash_init() otherwise it can cause panic. Cc: stable@vger.kernel.org Signed-off-by: Rui Wang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit caec5c97583b7ea44c57be91a19d28b0ac447fe4 Author: Lev Lybin Date: Fri Jan 29 22:55:11 2016 +0700 ALSA: usb-audio: Add quirk for Microsoft LifeCam HD-6000 [ Upstream commit 1b3c993a699bed282e47c3f7c49d539c331dae04 ] Microsoft LifeCam HD-6000 (045e:076f) requires the similar quirk for avoiding the stall due to the invalid sample rate reads. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111491 Signed-off-by: Lev Lybin Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 29eccdaa46023d0c57c691ce047f9f424114c2b6 Author: Jurgen Kramer Date: Fri Jan 29 14:59:25 2016 +0100 ALSA: usb-audio: Add native DSD support for PS Audio NuWave DAC [ Upstream commit ad678b4ccd41aa51cf5f142c0e8cffe9d61fc2bf ] This patch adds native DSD support for the PS Audio NuWave DAC. Signed-off-by: Jurgen Kramer Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a16d95b6a648c5d4761ec5988923421b4c0ecabb Author: Jurgen Kramer Date: Fri Jan 29 14:49:55 2016 +0100 ALSA: usb-audio: Fix OPPO HA-1 vendor ID [ Upstream commit 5327d6ba975042fd3da50ac6e94d1e9551ebeaec ] In my patch adding native DSD support for the Oppo HA-1, the wrong vendor ID got through. This patch fixes the vendor ID and aligns the comment. Fixes: a4eae3a506ea ('ALSA: usb: Add native DSD support for Oppo HA-1') Signed-off-by: Jurgen Kramer Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 43293f825820f7228871ff16b6ff34260113b62e Author: Jani Nikula Date: Wed Jan 13 16:35:20 2016 +0200 drm/i915/dp: fall back to 18 bpp when sink capability is unknown [ Upstream commit 5efd407674068dede403551bea3b0b134c32513a ] Per DP spec, the source device should fall back to 18 bpp, VESA range RGB when the sink capability is unknown. Fix the color depth clamping. 18 bpp color depth should ensure full color range in automatic mode. The clamping has been HDMI specific since its introduction in commit 996a2239f93b03c5972923f04b097f65565c5bed Author: Daniel Vetter Date: Fri Apr 19 11:24:34 2013 +0200 drm/i915: Disable high-bpc on pre-1.4 EDID screens Cc: stable@vger.kernel.org Reported-and-tested-by: Dihan Wickremasuriya Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331 Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com (cherry picked from commit 013dd9e038723bbd2aa67be51847384b75be8253) Signed-off-by: Sasha Levin commit 73f876ae98498f5a929053e4d402062a5516aa73 Author: Herbert Xu Date: Wed Jan 27 00:16:37 2016 +0800 crypto: shash - Fix has_key setting [ Upstream commit 00420a65fa2beb3206090ead86942484df2275f3 ] The has_key logic is wrong for shash algorithms as they always have a setkey function. So we should instead be testing against shash_no_setkey. Fixes: a5596d633278 ("crypto: hash - Add crypto_ahash_has_setkey") Cc: stable@vger.kernel.org Reported-by: Stephan Mueller Signed-off-by: Herbert Xu Tested-by: Stephan Mueller Signed-off-by: Sasha Levin commit 505a9f25a6c33070eb51ea50aabf168b8aafa6d1 Author: Nicolas Ferre Date: Wed Jan 27 11:03:02 2016 +0100 ARM: dts: at91: sama5d4 xplained: fix phy0 IRQ type [ Upstream commit e873cc022ce5e2c04bbc53b5874494b657e29d3f ] For phy0 KSZ8081, the type of GPIO IRQ should be "level low" instead of "edge falling". Signed-off-by: Nicolas Ferre Fixes: 38153a017896 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board") Cc: # 4.1+ Signed-off-by: Sasha Levin commit 06fa2c9ac1aa1dfe3d7e55644c23e96214067040 Author: Wenyou Yang Date: Wed Jan 27 13:16:24 2016 +0800 ARM: dts: at91: sama5d4ek: add phy address and IRQ for macb0 [ Upstream commit aae6b18f5c95b9dc78de66d1e27e8afeee2763b7 ] On SAMA5D4EK board, the Ethernet doesn't work after resuming from the suspend state. Signed-off-by: Wenyou Yang [nicolas.ferre@atmel.com: adapt to newer kernel] Fixes: 38153a017896 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board") Cc: # 4.1+ Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit d54ed290a5011beeeeb38082aa4323af4c60e7be Author: Mohamed Jamsheeth Hajanajubudeen Date: Fri Dec 11 17:06:26 2015 +0530 ARM: dts: at91: sama5d4: fix instance id of DBGU [ Upstream commit 929e883f2bfdf68d4bd3aec43912e956417005c7 ] Change instance id of DBGU to 45. Signed-off-by: Mohamed Jamsheeth Hajanajubudeen Fixes: 7c661394c56c ("ARM: at91: dt: add device tree file for SAMA5D4 SoC") Cc: stable@vger.kernel.org # 3.18+ Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit 5abd25f01c03b52d8aa39813656782917aa10d9b Author: Johannes Berg Date: Tue Jan 26 11:29:03 2016 +0100 rfkill: fix rfkill_fop_read wait_event usage [ Upstream commit 6736fde9672ff6717ac576e9bba2fd5f3dfec822 ] The code within wait_event_interruptible() is called with !TASK_RUNNING, so mustn't call any functions that can sleep, like mutex_lock(). Since we re-check the list_empty() in a loop after the wait, it's safe to simply use list_empty() without locking. This bug has existed forever, but was only discovered now because all userspace implementations, including the default 'rfkill' tool, use poll() or select() to get a readable fd before attempting to read. Cc: stable@vger.kernel.org Fixes: c64fb01627e24 ("rfkill: create useful userspace interface") Reported-by: Dmitry Vyukov Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8448609ec0b8b36759338905a7a5f620555623d8 Author: Sachin Kulkarni Date: Tue Jan 12 14:30:19 2016 +0530 mac80211: Requeue work after scan complete for all VIF types. [ Upstream commit 4fa11ec726a32ea6dd768dbb2e2af3453a98ec0a ] During a sw scan ieee80211_iface_work ignores work items for all vifs. However after the scan complete work is requeued only for STA, ADHOC and MESH iftypes. This occasionally results in event processing getting delayed/not processed for iftype AP when it coexists with a STA. This can result in data halt and eventually disconnection on the AP interface. Cc: stable@vger.kernel.org Signed-off-by: Sachin Kulkarni Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 22186aa8b53c158418f8c1f70b1a556a78ed1012 Author: Tony Lindgren Date: Thu Jan 14 12:20:48 2016 -0800 ARM: OMAP2+: Fix ppa_zero_params and ppa_por_params for rodata [ Upstream commit 4da597d16602d14405b71a18d45e1c59f28f0fd2 ] We don't want to write to .text so let's move ppa_zero_params and ppa_por_params to .data and access them via pointers. Note that I have not been able to test as we I don't have a HS omap4 to test with. The code has been changed in similar way as for omap3 though. Cc: Kees Cook Cc: Laura Abbott Cc: Nishanth Menon Cc: Richard Woodruff Cc: Russell King Cc: Tero Kristo Acked-by: Nicolas Pitre Cc: stable@vger.kernel.org # v4.0+ Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be non-executable") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit b6204db55d575691f837a64fbc31eb9a4bcb3c52 Author: Tony Lindgren Date: Thu Jan 14 12:20:47 2016 -0800 ARM: OMAP2+: Fix save_secure_ram_context for rodata [ Upstream commit a5311d4d13df80bd71a9e47f9ecaf327f478fab1 ] We don't want to write to .text and we can move save_secure_ram_context into .data as it all gets copied into SRAM anyways. Cc: Kees Cook Cc: Laura Abbott Cc: Nishanth Menon Cc: Richard Woodruff Cc: Russell King Cc: Sergei Shtylyov Cc: Tero Kristo Acked-by: Nicolas Pitre Cc: stable@vger.kernel.org # v4.0+ Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be non-executable") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 2c0fae21283fe4d8ca6475e40f56603f7426613d Author: Tony Lindgren Date: Thu Jan 14 12:20:47 2016 -0800 ARM: OMAP2+: Fix l2dis_3630 for rodata [ Upstream commit eeaf9646aca89d097861caa24d9818434e48810e ] We don't want to write to .text section. Let's move l2dis_3630 to .data and access it via a pointer. For calculating the offset, let's optimize out the add and do it in ldr/str as suggested by Nicolas Pitre . Cc: Kees Cook Cc: Laura Abbott Cc: Nishanth Menon Cc: Richard Woodruff Cc: Russell King Cc: Tero Kristo Cc: stable@vger.kernel.org # v4.0+ Acked-by: Nicolas Pitre Cc: stable@vger.kernel.org # v4.0+ Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be non-executable") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 01c7c52c66428c45484b59dac950b613e38cc7dc Author: Tony Lindgren Date: Thu Jan 14 12:20:47 2016 -0800 ARM: OMAP2+: Fix wait_dll_lock_timed for rodata [ Upstream commit d9db59103305eb5ec2a86369f32063e9921b6ac5 ] We don't want to be writing to .text so it can be set rodata. Fix error "Unable to handle kernel paging request at virtual address c012396c" in wait_dll_lock_timed if CONFIG_DEBUG_RODATA is selected. As these counters are for debugging only and unused, we can just remove them. Cc: Kees Cook Cc: Laura Abbott Cc: Nishanth Menon Cc: Richard Woodruff Cc: Russell King Cc: Tero Kristo Acked-by: Nicolas Pitre Cc: stable@vger.kernel.org # v4.0+ Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be non-executable") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 9f4bab04f3788cd66b203c501fe30d093fe4d8d7 Author: Insu Yun Date: Sat Jan 23 15:44:19 2016 -0500 ACPI / PCI / hotplug: unlock in error path in acpiphp_enable_slot() [ Upstream commit 2c3033a0664dfae91e1dee7fabac10f24354b958 ] In acpiphp_enable_slot(), there is a missing unlock path when error occurred. It needs to be unlocked before returning an error. Signed-off-by: Insu Yun Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4470ba0e8a7f353cf3868eca475272d49605f823 Author: Huacai Chen Date: Thu Jan 21 21:09:52 2016 +0800 MIPS: Fix some missing CONFIG_CPU_MIPSR6 #ifdefs [ Upstream commit 4f33f6c522948fffc345261896042b58dea23754 ] Commit be0c37c985eddc4 (MIPS: Rearrange PTE bits into fixed positions.) defines fixed PTE bits for MIPS R2. Then, commit d7b631419b3d230a4d383 (MIPS: pgtable-bits: Fix XPA damage to R6 definitions.) adds the MIPS R6 definitions in the same way as MIPS R2. But some R6 #ifdefs in the later commit are missing, so in this patch I fix that. Signed-off-by: Huacai Chen Cc: Aurelien Jarno Cc: Steven J. Hill Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12164/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 156e0fd0ecf2f78b732584253a2f21c56a7e79ba Author: Mika Westerberg Date: Fri Jan 29 16:49:47 2016 +0200 serial: 8250_pci: Add Intel Broadwell ports [ Upstream commit 6c55d9b98335f7f6bd5f061866ff1633401f3a44 ] Some recent (early 2015) macbooks have Intel Broadwell where LPSS UARTs are PCI enumerated instead of ACPI. The LPSS UART block is pretty much same as used on Intel Baytrail so we can reuse the existing Baytrail setup code. Add both Broadwell LPSS UART ports to the list of supported devices. Signed-off-by: Leif Liddy Signed-off-by: Mika Westerberg Reviewed-by: Andy Shevchenko Reviewed-by: Heikki Krogerus Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3704a44fc2706841b7af21235e928e0be0bb251d Author: Matt Fleming Date: Fri Jan 29 11:36:10 2016 +0000 x86/mm/pat: Avoid truncation when converting cpa->numpages to address [ Upstream commit 742563777e8da62197d6cb4b99f4027f59454735 ] There are a couple of nasty truncation bugs lurking in the pageattr code that can be triggered when mapping EFI regions, e.g. when we pass a cpa->pgd pointer. Because cpa->numpages is a 32-bit value, shifting left by PAGE_SHIFT will truncate the resultant address to 32-bits. Viorel-Cătălin managed to trigger this bug on his Dell machine that provides a ~5GB EFI region which requires 1236992 pages to be mapped. When calling populate_pud() the end of the region gets calculated incorrectly in the following buggy expression, end = start + (cpa->numpages << PAGE_SHIFT); And only 188416 pages are mapped. Next, populate_pud() gets invoked for a second time because of the loop in __change_page_attr_set_clr(), only this time no pages get mapped because shifting the remaining number of pages (1048576) by PAGE_SHIFT is zero. At which point the loop in __change_page_attr_set_clr() spins forever because we fail to map progress. Hitting this bug depends very much on the virtual address we pick to map the large region at and how many pages we map on the initial run through the loop. This explains why this issue was only recently hit with the introduction of commit a5caa209ba9c ("x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down") It's interesting to note that safe uses of cpa->numpages do exist in the pageattr code. If instead of shifting ->numpages we multiply by PAGE_SIZE, no truncation occurs because PAGE_SIZE is a UL value, and so the result is unsigned long. To avoid surprises when users try to convert very large cpa->numpages values to addresses, change the data type from 'int' to 'unsigned long', thereby making it suitable for shifting by PAGE_SHIFT without any type casting. The alternative would be to make liberal use of casting, but that is far more likely to cause problems in the future when someone adds more code and fails to cast properly; this bug was difficult enough to track down in the first place. Reported-and-tested-by: Viorel-Cătălin Răpițeanu Acked-by: Borislav Petkov Cc: Sai Praneeth Prakhya Cc: Signed-off-by: Matt Fleming Link: https://bugzilla.kernel.org/show_bug.cgi?id=110131 Link: http://lkml.kernel.org/r/1454067370-10374-1-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit b143adc3f446be7dbb5a0d4c63089078d7718f06 Author: Samuel Thibault Date: Fri Jan 15 00:47:41 2016 +0100 Staging: speakup: Fix getting port information [ Upstream commit 327b882d3bcc1fba82dbd39b5cf5a838c81218e2 ] Commit f79b0d9c223c ("staging: speakup: Fixed warning instead of ") broke the port information in the speakup driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included, and no other header includes asm/serial.h. We here make sure serialio.c does get the arch-specific definition of SERIAL_PORT_DFNS from asm/serial.h, if any. Along the way, this makes sure that we do have information for the requested serial port number (index) Fixes: f79b0d9c223c ("staging: speakup: Fixed warning instead of ") Signed-off-by: Samuel Thibault Cc: stable # 3.18 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c4bbd2785e0ed7ed3e8c16776194ea9181fc3454 Author: Rob Clark Date: Wed Oct 15 15:00:47 2014 -0400 drm/vmwgfx: respect 'nomodeset' [ Upstream commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 ] Signed-off-by: Rob Clark Reviewed-by: Thomas Hellstrom . Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit f6b4419806e546fb02f91bed03572362e2623879 Author: Takashi Iwai Date: Thu Jan 28 07:54:16 2016 +0100 ALSA: dummy: Disable switching timer backend via sysfs [ Upstream commit 7ee96216c31aabe1eb42fb91ff50dae9fcd014b2 ] ALSA dummy driver can switch the timer backend between system timer and hrtimer via its hrtimer module option. This can be also switched dynamically via sysfs, but it may lead to a memory corruption when switching is done while a PCM stream is running; the stream instance for the newly switched timer method tries to access the memory that was allocated by another timer method although the sizes differ. As the simplest fix, this patch just disables the switch via sysfs by dropping the writable bit. BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.com Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2fbdb6c658f4a10c649fd57c42a5199d2a8032d8 Author: Slava Grigorev Date: Tue Jan 26 17:35:57 2016 -0500 drm/radeon: fix DP audio support for APU with DCE4.1 display engine [ Upstream commit fe6fc1f132b4300c1f6defd43a5d673eb60a820d ] Properly setup the DFS divider for DP audio for DCE4.1. Signed-off-by: Slava Grigorev Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2652823a09685084d3c1dc0abe17a2fa6596d19a Author: Slava Grigorev Date: Tue Jan 26 16:56:25 2016 -0500 drm/radeon: Add a common function for DFS handling [ Upstream commit a64c9dab1c4d05c87ec8a1cb9b48915816462143 ] Move encoding of DFS (digital frequency synthesizer) divider into a separate function and improve calculation precision. Signed-off-by: Slava Grigorev Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7fb7275ff91c477cc1a8fbbd9667343f8261998e Author: Slava Grigorev Date: Tue Jan 26 16:45:10 2016 -0500 drm/radeon: cleaned up VCO output settings for DP audio [ Upstream commit c9a392eac18409f51a071520cf508c0b4ad990e2 ] This is preparation for the fixes in the following patches. Signed-off-by: Slava Grigorev Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9646e177106ce8154bf87cde52188f015250e8ed Author: Alex Deucher Date: Fri Jul 24 00:42:02 2015 -0400 drm/radeon: rework audio modeset to handle non-audio hdmi features [ Upstream commit 7726e72b3d6879ee5fc743a230eb6f5afa12844b ] Need to setup the deep color and avi packets regardless of audio setup. Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 988590966531b9ab4d7c6101f02a6f065c5df7a5 Author: Jann Horn Date: Sat Dec 26 06:00:48 2015 +0100 seccomp: always propagate NO_NEW_PRIVS on tsync [ Upstream commit 103502a35cfce0710909da874f092cb44823ca03 ] Before this patch, a process with some permissive seccomp filter that was applied by root without NO_NEW_PRIVS was able to add more filters to itself without setting NO_NEW_PRIVS by setting the new filter from a throwaway thread with NO_NEW_PRIVS. Signed-off-by: Jann Horn Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit aa54b6de2b2ffbd6bb3086dbebd8fea61701202b Author: Milo Kim Date: Wed Jan 13 16:19:50 2016 +0900 irqchip/atmel-aic: Fix wrong bit operation for IRQ priority [ Upstream commit 49f34134aea74f19ca016f055d25ee55ec359dee ] Atmel AIC has common structure for SMR (Source Mode Register). bit[6:5] Interrupt source type bit[2:0] Priority level Other bits are unused. To update new priority value, bit[2:0] should be cleared first and then new priority level can be written. However, aic_common_set_priority() helper clears source type bits instead of priority bits. This patch fixes wrong mask bit operation. Fixes: b1479ebb7720 "irqchip: atmel-aic: Add atmel AIC/AIC5 drivers" Signed-off-by: Milo Kim Acked-by: Boris Brezillon Cc: Jason Cooper Cc: Marc Zyngier Cc: Ludovic Desroches Cc: Nicholas Ferre Cc: stable@vger.kernel.org #v3.17+ Link: http://lkml.kernel.org/r/1452669592-3401-2-git-send-email-milo.kim@ti.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit d515d710883d98ee77819fe9b4848bfdcfd0a324 Author: Peter Hurley Date: Sun Jan 10 22:40:58 2016 -0800 staging/speakup: Use tty_ldisc_ref() for paste kworker [ Upstream commit f4f9edcf9b5289ed96113e79fa65a7bf27ecb096 ] As the function documentation for tty_ldisc_ref_wait() notes, it is only callable from a tty file_operations routine; otherwise there is no guarantee the ref won't be NULL. The key difference with the VT's paste_selection() is that is an ioctl, where __speakup_paste_selection() is completely async kworker, kicked off from interrupt context. Fixes: 28a821c30688 ("Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to match vt") Cc: Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 28b824966ab269de94e0ca640b7c61aedc6a83de Author: Peter Hurley Date: Sun Jan 10 22:40:56 2016 -0800 n_tty: Fix unsafe reference to "other" ldisc [ Upstream commit 6d27a63caad3f13e96cf065d2d96828c2006be6b ] Although n_tty_check_unthrottle() has a valid ldisc reference (since the tty core gets the ldisc ref in tty_read() before calling the line discipline read() method), it does not have a valid ldisc reference to the "other" pty of a pty pair. Since getting an ldisc reference for tty->link essentially open-codes tty_wakeup(), just replace with the equivalent tty_wakeup(). Cc: Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 27055738c910ee29a9de4b496e198e17b38b0eed Author: Peter Hurley Date: Sun Jan 10 22:40:55 2016 -0800 tty: Fix unsafe ldisc reference via ioctl(TIOCGETD) [ Upstream commit 5c17c861a357e9458001f021a7afa7aab9937439 ] ioctl(TIOCGETD) retrieves the line discipline id directly from the ldisc because the line discipline id (c_line) in termios is untrustworthy; userspace may have set termios via ioctl(TCSETS*) without actually changing the line discipline via ioctl(TIOCSETD). However, directly accessing the current ldisc via tty->ldisc is unsafe; the ldisc ptr dereferenced may be stale if the line discipline is changing via ioctl(TIOCSETD) or hangup. Wait for the line discipline reference (just like read() or write()) to retrieve the "current" line discipline id. Cc: Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 91e65860a7fe55d3d8c150104084b54f2760bc3d Author: Alan Stern Date: Wed Jan 20 11:26:01 2016 -0500 SCSI: fix crashes in sd and sr runtime PM [ Upstream commit 13b4389143413a1f18127c07f72c74cad5b563e8 ] Runtime suspend during driver probe and removal can cause problems. The driver's runtime_suspend or runtime_resume callbacks may invoked before the driver has finished binding to the device or after the driver has unbound from the device. This problem shows up with the sd and sr drivers, and can cause disk or CD/DVD drives to become unusable as a result. The fix is simple. The drivers store a pointer to the scsi_disk or scsi_cd structure as their private device data when probing is finished, so we simply have to be sure to clear the private data during removal and test it during runtime suspend/resume. This fixes . Signed-off-by: Alan Stern Reported-by: Paul Menzel Reported-by: Erich Schubert Reported-by: Alexandre Rossi Tested-by: Paul Menzel Tested-by: Erich Schubert CC: Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit 329d4fd5f2af659d62fa6f6cea72233c7e033e9a Author: Gavin Shan Date: Wed Dec 2 16:25:32 2015 +1100 powerpc/eeh: Fix PE location code [ Upstream commit 7e56f627768da4e6480986b5145dc3422bc448a5 ] In eeh_pe_loc_get(), the PE location code is retrieved from the "ibm,loc-code" property of the device node for the bridge of the PE's primary bus. It's not correct because the property indicates the parent PE's location code. This reads the correct PE location code from "ibm,io-base-loc-code" or "ibm,slot-location-code" property of PE parent bus's device node. Cc: stable@vger.kernel.org # v3.16+ Fixes: 357b2f3dd9b7 ("powerpc/eeh: Dump PE location code") Signed-off-by: Gavin Shan Tested-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit bd6d701606119bbbc3b55a064a53c6789a1acab6 Author: Jan Beulich Date: Tue Jan 26 04:15:18 2016 -0700 x86/mm: Fix types used in pgprot cacheability flags translations [ Upstream commit 3625c2c234ef66acf21a72d47a5ffa94f6c5ebf2 ] For PAE kernels "unsigned long" is not suitable to hold page protection flags, since _PAGE_NX doesn't fit there. This is the reason for quite a few W+X pages getting reported as insecure during boot (observed namely for the entire initrd range). Fixes: 281d4078be ("x86: Make page cache mode a real type") Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/56A7635602000078000CAFF1@prv-mh.provo.novell.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit daab58866c29c4e9af4d3df2175f2dc485057e46 Author: Mika Penttilä Date: Tue Jan 26 15:47:25 2016 +0000 arm64: mm: avoid calling apply_to_page_range on empty range [ Upstream commit 57adec866c0440976c96a4b8f5b59fb411b1cacb ] Calling apply_to_page_range with an empty range results in a BUG_ON from the core code. This can be triggered by trying to load the st_drv module with CONFIG_DEBUG_SET_MODULE_RONX enabled: kernel BUG at mm/memory.c:1874! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 1764 Comm: insmod Not tainted 4.5.0-rc1+ #2 Hardware name: ARM Juno development board (r0) (DT) task: ffffffc9763b8000 ti: ffffffc975af8000 task.ti: ffffffc975af8000 PC is at apply_to_page_range+0x2cc/0x2d0 LR is at change_memory_common+0x80/0x108 This patch fixes the issue by making change_memory_common (called by the set_memory_* functions) a NOP when numpages == 0, therefore avoiding the erroneous call to apply_to_page_range and bringing us into line with x86 and s390. Cc: Reviewed-by: Laura Abbott Acked-by: David Rientjes Signed-off-by: Mika Penttilä Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2c68386075ac61d3bedbc34491a0ed828ff832b9 Author: Lucas Tanure Date: Mon Jan 25 19:30:23 2016 -0200 ALSA: bebob: Use a signed return type for get_formation_index [ Upstream commit 07905298e4d5777eb58516cdc242f7ac1ca387a2 ] The return type "unsigned int" was used by the get_formation_index function despite of the aspect that it will eventually return a negative error code. So, change to signed int and get index by reference in the parameters. Done with the help of Coccinelle. [Fix the missing braces suggested by Julia Lawall -- tiwai] Signed-off-by: Lucas Tanure Reviewed-by: Takashi Sakamoto Tested-by: Takashi Sakamoto Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 593bd1058b30eb4f0d6949afdfd9c2659d94ae1e Author: Michael S. Tsirkin Date: Thu Jan 14 16:00:41 2016 +0200 virtio_pci: fix use after free on release [ Upstream commit 2989be09a8a9d62a785137586ad941f916e08f83 ] KASan detected a use-after-free error in virtio-pci remove code. In virtio_pci_remove(), vp_dev is still used after being freed in unregister_virtio_device() (in virtio_pci_release_dev() more precisely). To fix, keep a reference until cleanup is done. Fixes: 63bd62a08ca4 ("virtio_pci: defer kfree until release callback") Reported-by: Jerome Marchand Cc: stable@vger.kernel.org Cc: Sasha Levin Signed-off-by: Michael S. Tsirkin Tested-by: Jerome Marchand Signed-off-by: Sasha Levin commit 465cc6de211a88a8af978fd8e1d07e6a453a31c4 Author: Guillaume Fougnies Date: Tue Jan 26 00:28:27 2016 +0100 ALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay [ Upstream commit 5a4ff9ec8d6edd2ab1cfe8ce6a080d6e57cbea9a ] TEAC UD-501/UD-503/NT-503 fail to switch properly between different rate/format. Similar to 'Playback Design', this patch corrects the invalid clock source error for TEAC products and avoids complete freeze of the usb interface of 503 series. Signed-off-by: Guillaume Fougnies Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 488c5719648811d5b9bb174f2c77fe2f09dcd799 Author: Takashi Iwai Date: Mon Jan 25 13:59:21 2016 +0100 ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures [ Upstream commit 462b3f161beb62eeb290f4ec52f5ead29a2f8ac7 ] Some architectures like PowerPC can handle the maximum struct size in an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This problem was revealed recently by a powerpc change, as it's now treated as a fatal build error. This patch is a stop-gap for that: for architectures with less than 14 bit ioctl struct size, get rid of the handling of the relevant ioctl. We should provide an alternative equivalent ioctl code later, but for now just paper over it. Luckily, the compress API hasn't been used on such architectures, so the impact must be effectively zero. Reviewed-by: Mark Brown Acked-by: Sudip Mukherjee Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3f0333c42683452b2315dec5963a5b997e213387 Author: John Ernberg Date: Mon Jan 25 12:27:17 2016 +0000 USB: option: fix Cinterion AHxx enumeration [ Upstream commit 4152b387da81617c80cb2946b2d56e3958906b3e ] In certain kernel configurations where the cdc_ether and option drivers are compiled as modules there can occur a race condition in enumeration. This causes the option driver to enumerate the ethernet(wwan) interface as usb-serial interfaces. usb-devices output for the modem: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e2d ProdID=0055 Rev=00.00 S: Manufacturer=Cinterion S: Product=AHx C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=10mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Signed-off-by: John Ernberg Fixes: 1941138e1c02 ("USB: added support for Cinterion's products...") Cc: stable # v3.9: 8ff10bdb14a52 Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit be630626eccf643f4c2c7e276e1f25b9928ec2e4 Author: Lorenzo Pieralisi Date: Wed Jan 13 14:50:03 2016 +0000 arm64: kernel: fix architected PMU registers unconditional access [ Upstream commit f436b2ac90a095746beb6729b8ee8ed87c9eaede ] The Performance Monitors extension is an optional feature of the AArch64 architecture, therefore, in order to access Performance Monitors registers safely, the kernel should detect the architected PMU unit presence through the ID_AA64DFR0_EL1 register PMUVer field before accessing them. This patch implements a guard by reading the ID_AA64DFR0_EL1 register PMUVer field to detect the architected PMU presence and prevent accessing PMU system registers if the Performance Monitors extension is not implemented in the core. Cc: Peter Maydell Cc: Mark Rutland Cc: Fixes: 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 initialization and restore") Signed-off-by: Lorenzo Pieralisi Reported-by: Guenter Roeck Tested-by: Guenter Roeck Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 5ebf917025ec0d6f62f7d8411744d16efe9745d0 Author: Greg Kroah-Hartman Date: Tue Jan 19 23:43:13 2016 -0800 USB: serial: ftdi_sio: add support for Yaesu SCU-18 cable [ Upstream commit e03cdf22a2727c60307be6a729233edab3bfda9c ] Harald Linden reports that the ftdi_sio driver works properly for the Yaesu SCU-18 cable if the device ids are added to the driver. So let's add them. Reported-by: Harald Linden Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 14a2303b85c63299dad236f0d2df9143d22b9242 Author: Takashi Iwai Date: Mon Jan 25 11:24:56 2016 +0100 ALSA: seq: Degrade the error message for too many opens [ Upstream commit da10816e3d923565b470fec78a674baba794ed33 ] ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too many applications") when user-space tries to open more than the limit. This means that it can easily fill the log buffer. Since it's merely a normal error, it's safe to suppress it via pr_debug() instead. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 16116a3de550c2341933f4b0c54d7e52ceee4edf Author: Takashi Iwai Date: Mon Jan 25 11:01:47 2016 +0100 ALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup() [ Upstream commit 599151336638d57b98d92338aa59c048e3a3e97d ] ALSA sequencer OSS emulation code has a sanity check for currently opened devices, but there is a thinko there, eventually it spews warnings and skips the operation wrongly like: WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311 Fix this off-by-one error. Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a498ef85e10d1ad035499be0bdcef38bdc791c1a Author: Daniele Palmas Date: Tue Jan 12 17:22:06 2016 +0100 USB: serial: option: Adding support for Telit LE922 [ Upstream commit ff4e2494dc17b173468e1713fdf6237fd8578bc7 ] This patch adds support for two PIDs of LE922. Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 85491ceb50c4bc446127776714b41d2b9ca627f1 Author: Vladis Dronov Date: Tue Jan 12 15:10:50 2016 +0100 USB: serial: visor: fix crash on detecting device without write_urbs [ Upstream commit cb3232138e37129e88240a98a1d2aba2187ff57c ] The visor driver crashes in clie_5_attach() when a specially crafted USB device without bulk-out endpoint is detected. This fix adds a check that the device has proper configuration expected by the driver. Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Fixes: cfb8da8f69b8 ("USB: visor: fix initialisation of UX50/TH55 devices") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 5c9cad0a726131934408f3a9e66fc381204a9ba2 Author: Johan Hovold Date: Tue Jan 12 12:05:20 2016 +0100 USB: visor: fix null-deref at probe [ Upstream commit cac9b50b0d75a1d50d6c056ff65c005f3224c8e0 ] Fix null-pointer dereference at probe should a (malicious) Treo device lack the expected endpoints. Specifically, the Treo port-setup hack was dereferencing the bulk-in and interrupt-in urbs without first making sure they had been allocated by core. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 1c47f2c5aff5993647468e8476bb6bbc6e09a939 Author: Peter Dedecker Date: Fri Jan 8 12:34:41 2016 +0100 USB: cp210x: add ID for IAI USB to RS485 adaptor [ Upstream commit f487c54ddd544e1c9172cd510954f697b77b76e3 ] Added the USB serial console device ID for IAI Corp. RCB-CV-USB USB to RS485 adaptor. Signed-off-by: Peter Dedecker Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 522dc09ca0451d118795e8a05c7b3717f3d1ad8b Author: Du, Changbin Date: Mon Jan 18 21:02:42 2016 +0800 usb: hub: do not clear BOS field during reset device [ Upstream commit d8f00cd685f5c8e0def8593e520a7fef12c22407 ] In function usb_reset_and_verify_device, the old BOS descriptor may still be used before allocating a new one. (usb_unlocked_disable_lpm function uses it under the situation that it fails to disable lpm.) So we cannot set the udev->bos to NULL before that, just keep what it was. It will be overwrite when allocating a new one. Crash log: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [] usb_enable_link_state+0x2d/0x2f0 Call Trace: [] ? usb_set_lpm_timeout+0x12b/0x140 [] usb_enable_lpm+0x81/0xa0 [] usb_disable_lpm+0xa8/0xc0 [] usb_unlocked_disable_lpm+0x2c/0x50 [] usb_reset_and_verify_device+0xc3/0x710 [] ? usb_sg_wait+0x13d/0x190 [] usb_reset_device+0x133/0x280 [] usb_stor_port_reset+0x61/0x70 [] usb_stor_invoke_transport+0x88/0x520 Signed-off-by: Du, Changbin Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 08d717c38d856465804b1b1d3fea19b64d8214e7 Author: Oliver Neukum Date: Mon Jan 18 15:45:18 2016 +0100 cdc-acm:exclude Samsung phone 04e8:685d [ Upstream commit e912e685f372ab62a2405a1acd923597f524e94a ] This phone needs to be handled by a specialised firmware tool and is reported to crash irrevocably if cdc-acm takes it. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a7b1bf8b60e4fd4deb414cabc9f218eff244d4f9 Author: Lu Baolu Date: Wed Jan 6 15:10:04 2016 +0800 usb: cdc-acm: send zero packet for intel 7260 modem [ Upstream commit ffdb1e369a73b380fce95b05f8498d92c43842b4 ] For Intel 7260 modem, it is needed for host side to send zero packet if the BULK OUT size is equal to USB endpoint max packet length. Otherwise, modem side may still wait for more data and cannot give response to host side. Signed-off-by: Konrad Leszczynski Signed-off-by: Lu Baolu Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6cdc037a9b649209051e3c982d5fcaf31274cb55 Author: Lu Baolu Date: Wed Dec 30 12:59:08 2015 +0800 usb: cdc-acm: handle unlinked urb in acm read callback [ Upstream commit 19454462acb1bdef80542061bdc9b410e4ed1ff6 ] In current acm driver, the bulk-in callback function ignores the URBs unlinked in usb core. This causes unexpected data loss in some cases. For example, runtime suspend entry will unlinked all urbs and set urb->status to -ENOENT even those urbs might have data not processed yet. Hence, data loss occurs. This patch lets bulk-in callback function handle unlinked urbs to avoid data loss. Signed-off-by: Tang Jian Qiang Signed-off-by: Lu Baolu Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f75f1b25fb42f28b59d6e050cbdd4440797ac9ad Author: Josh Boyer Date: Sun Jan 24 10:46:42 2016 -0500 ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list [ Upstream commit 6b31de3e698582fe0b8f7f4bab15831b73204800 ] Like the Yoga 900 models the Lenovo Yoga 700 does not have a hw rfkill switch, and trying to read the hw rfkill switch through the ideapad module causes it to always reported blocking breaking wifi. This commit adds the Lenovo Yoga 700 to the no_hw_rfkill dmi list, fixing the wifi breakage. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1295272 Tested-by: Cc: stable@vger.kernel.org Signed-off-by: Josh Boyer Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 085c2863e0f3e3107ff50eb79d226462b7f4fd78 Author: Hans de Goede Date: Mon Nov 9 17:09:05 2015 +0100 ideapad-laptop: Add Lenovo Yoga 900 to no_hw_rfkill dmi list [ Upstream commit f71c882dd4cfe4aa88ea07b1402ddd43605d4aef ] Like some of the other Yoga models the Lenovo Yoga 900 does not have a hw rfkill switch, and trying to read the hw rfkill switch through the ideapad module causes it to always reported blocking breaking wifi. This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing the wifi breakage. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490 Cc: stable@vger.kernel.org Reported-and-tested-by: Kevin Fenzi Signed-off-by: Hans de Goede Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 9295dee2df7af7ea4233b664a8d4d4d057748e2f Author: Trond Myklebust Date: Thu Jan 21 15:39:40 2016 -0500 pNFS/flexfiles: Fix an XDR encoding bug in layoutreturn [ Upstream commit 082fa37d1351a41afc491d44a1d095cb8d919aa2 ] We must not skip encoding the statistics, or the server will see an XDR encoding error. Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org # 4.0+ Signed-off-by: Sasha Levin commit b085ab71a7e748a9edb77a36ceadbab514ce0947 Author: Tariq Saeed Date: Thu Jan 21 16:40:39 2016 -0800 ocfs2: NFS hangs in __ocfs2_cluster_lock due to race with ocfs2_unblock_lock [ Upstream commit b1b1e15ef6b80facf76d6757649dfd7295eda29f ] NFS on a 2 node ocfs2 cluster each node exporting dir. The lock causing the hang is the global bit map inode lock. Node 1 is master, has the lock granted in PR mode; Node 2 is in the converting list (PR -> EX). There are no holders of the lock on the master node so it should downconvert to NL and grant EX to node 2 but that does not happen. BLOCKED + QUEUED in lock res are set and it is on osb blocked list. Threads are waiting in __ocfs2_cluster_lock on BLOCKED. One thread wants EX, rest want PR. So it is as though the downconvert thread needs to be kicked to complete the conv. The hang is caused by an EX req coming into __ocfs2_cluster_lock on the heels of a PR req after it sets BUSY (drops l_lock, releasing EX thread), forcing the incoming EX to wait on BUSY without doing anything. PR has called ocfs2_dlm_lock, which sets the node 1 lock from NL -> PR, queues ast. At this time, upconvert (PR ->EX) arrives from node 2, finds conflict with node 1 lock in PR, so the lock res is put on dlm thread's dirty listt. After ret from ocf2_dlm_lock, PR thread now waits behind EX on BUSY till awoken by ast. Now it is dlm_thread that serially runs dlm_shuffle_lists, ast, bast, in that order. dlm_shuffle_lists ques a bast on behalf of node 2 (which will be run by dlm_thread right after the ast). ast does its part, sets UPCONVERT_FINISHING, clears BUSY and wakes its waiters. Next, dlm_thread runs bast. It sets BLOCKED and kicks dc thread. dc thread runs ocfs2_unblock_lock, but since UPCONVERT_FINISHING set, skips doing anything and reques. Inside of __ocfs2_cluster_lock, since EX has been waiting on BUSY ahead of PR, it wakes up first, finds BLOCKED set and skips doing anything but clearing UPCONVERT_FINISHING (which was actually "meant" for the PR thread), and this time waits on BLOCKED. Next, the PR thread comes out of wait but since UPCONVERT_FINISHING is not set, it skips updating the l_ro_holders and goes straight to wait on BLOCKED. So there, we have a hang! Threads in __ocfs2_cluster_lock wait on BLOCKED, lock res in osb blocked list. Only when dc thread is awoken, it will run ocfs2_unblock_lock and things will unhang. One way to fix this is to wake the dc thread on the flag after clearing UPCONVERT_FINISHING Orabug: 20933419 Signed-off-by: Tariq Saeed Signed-off-by: Santosh Shilimkar Reviewed-by: Wengang Wang Reviewed-by: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Reviewed-by: Joseph Qi Cc: Eric Ren Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d4dc115d9b67b7ec9769efd9b55d5bfce8d9ef20 Author: Kirill A. Shutemov Date: Thu Jan 21 16:40:27 2016 -0800 mm: fix mlock accouting [ Upstream commit 7162a1e87b3e380133dadc7909081bb70d0a7041 ] Tetsuo Handa reported underflow of NR_MLOCK on munlock. Testcase: #include #include #include #define BASE ((void *)0x400000000000) #define SIZE (1UL << 21) int main(int argc, char *argv[]) { void *addr; system("grep Mlocked /proc/meminfo"); addr = mmap(BASE, SIZE, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_LOCKED | MAP_FIXED, -1, 0); if (addr == MAP_FAILED) printf("mmap() failed\n"), exit(1); munmap(addr, SIZE); system("grep Mlocked /proc/meminfo"); return 0; } It happens on munlock_vma_page() due to unfortunate choice of nr_pages data type: __mod_zone_page_state(zone, NR_MLOCK, -nr_pages); For unsigned int nr_pages, implicitly casted to long in __mod_zone_page_state(), it becomes something around UINT_MAX. munlock_vma_page() usually called for THP as small pages go though pagevec. Let's make nr_pages signed int. Similar fixes in 6cdb18ad98a4 ("mm/vmstat: fix overflow in mod_zone_page_state()") used `long' type, but `int' here is OK for a count of the number of sub-pages in a huge page. Fixes: ff6a6da60b89 ("mm: accelerate munlock() treatment of THP pages") Signed-off-by: Kirill A. Shutemov Reported-by: Tetsuo Handa Tested-by: Tetsuo Handa Cc: Michel Lespinasse Acked-by: Michal Hocko Cc: [4.4+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 65a7633357c158ed164878d97e8a7fc09fb75946 Author: Ilya Dryomov Date: Mon Dec 28 13:18:34 2015 +0300 libceph: fix ceph_msg_revoke() [ Upstream commit 67645d7619738e51c668ca69f097cb90b5470422 ] There are a number of problems with revoking a "was sending" message: (1) We never make any attempt to revoke data - only kvecs contibute to con->out_skip. However, once the header (envelope) is written to the socket, our peer learns data_len and sets itself to expect at least data_len bytes to follow front or front+middle. If ceph_msg_revoke() is called while the messenger is sending message's data portion, anything we send after that call is counted by the OSD towards the now revoked message's data portion. The effects vary, the most common one is the eventual hang - higher layers get stuck waiting for the reply to the message that was sent out after ceph_msg_revoke() returned and treated by the OSD as a bunch of data bytes. This is what Matt ran into. (2) Flat out zeroing con->out_kvec_bytes worth of bytes to handle kvecs is wrong. If ceph_msg_revoke() is called before the tag is sent out or while the messenger is sending the header, we will get a connection reset, either due to a bad tag (0 is not a valid tag) or a bad header CRC, which kind of defeats the purpose of revoke. Currently the kernel client refuses to work with header CRCs disabled, but that will likely change in the future, making this even worse. (3) con->out_skip is not reset on connection reset, leading to one or more spurious connection resets if we happen to get a real one between con->out_skip is set in ceph_msg_revoke() and before it's cleared in write_partial_skip(). Fixing (1) and (3) is trivial. The idea behind fixing (2) is to never zero the tag or the header, i.e. send out tag+header regardless of when ceph_msg_revoke() is called. That way the header is always correct, no unnecessary resets are induced and revoke stands ready for disabled CRCs. Since ceph_msg_revoke() rips out con->out_msg, introduce a new "message out temp" and copy the header into it before sending. Cc: stable@vger.kernel.org # 4.0+ Reported-by: Matt Conner Signed-off-by: Ilya Dryomov Tested-by: Matt Conner Reviewed-by: Sage Weil Signed-off-by: Sasha Levin commit 92d4a19886bcce4cca4c9f993a7324ac607d142c Author: Mateusz Guzik Date: Wed Jan 20 15:01:02 2016 -0800 prctl: take mmap sem for writing to protect against others [ Upstream commit ddf1d398e517e660207e2c807f76a90df543a217 ] An unprivileged user can trigger an oops on a kernel with CONFIG_CHECKPOINT_RESTORE. proc_pid_cmdline_read takes mmap_sem for reading and obtains args + env start/end values. These get sanity checked as follows: BUG_ON(arg_start > arg_end); BUG_ON(env_start > env_end); These can be changed by prctl_set_mm. Turns out also takes the semaphore for reading, effectively rendering it useless. This results in: kernel BUG at fs/proc/base.c:240! invalid opcode: 0000 [#1] SMP Modules linked in: virtio_net CPU: 0 PID: 925 Comm: a.out Not tainted 4.4.0-rc8-next-20160105dupa+ #71 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff880077a68000 ti: ffff8800784d0000 task.ti: ffff8800784d0000 RIP: proc_pid_cmdline_read+0x520/0x530 RSP: 0018:ffff8800784d3db8 EFLAGS: 00010206 RAX: ffff880077c5b6b0 RBX: ffff8800784d3f18 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 00007f78e8857000 RDI: 0000000000000246 RBP: ffff8800784d3e40 R08: 0000000000000008 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000050 R13: 00007f78e8857800 R14: ffff88006fcef000 R15: ffff880077c5b600 FS: 00007f78e884a740(0000) GS:ffff88007b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f78e8361770 CR3: 00000000790a5000 CR4: 00000000000006f0 Call Trace: __vfs_read+0x37/0x100 vfs_read+0x82/0x130 SyS_read+0x58/0xd0 entry_SYSCALL_64_fastpath+0x12/0x76 Code: 4c 8b 7d a8 eb e9 48 8b 9d 78 ff ff ff 4c 8b 7d 90 48 8b 03 48 39 45 a8 0f 87 f0 fe ff ff e9 d1 fe ff ff 4c 8b 7d 90 eb c6 0f 0b <0f> 0b 0f 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 RIP proc_pid_cmdline_read+0x520/0x530 ---[ end trace 97882617ae9c6818 ]--- Turns out there are instances where the code just reads aformentioned values without locking whatsoever - namely environ_read and get_cmdline. Interestingly these functions look quite resilient against bogus values, but I don't believe this should be relied upon. The first patch gets rid of the oops bug by grabbing mmap_sem for writing. The second patch is optional and puts locking around aformentioned consumers for safety. Consumers of other fields don't seem to benefit from similar treatment and are left untouched. This patch (of 2): The code was taking the semaphore for reading, which does not protect against readers nor concurrent modifications. The problem could cause a sanity checks to fail in procfs's cmdline reader, resulting in an OOPS. Note that some functions perform an unlocked read of various mm fields, but they seem to be fine despite possible modificaton. Signed-off-by: Mateusz Guzik Acked-by: Cyrill Gorcunov Cc: Alexey Dobriyan Cc: Jarod Wilson Cc: Jan Stancek Cc: Al Viro Cc: Anshuman Khandual Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c81f4f0331deb1b482d93b3ac8da5f04ff20ad48 Author: James Bottomley Date: Wed Jan 20 14:58:29 2016 -0800 string_helpers: fix precision loss for some inputs [ Upstream commit 564b026fbd0d28e9f70fb3831293d2922bb7855b ] It was noticed that we lose precision in the final calculation for some inputs. The most egregious example is size=3000 blk_size=1900 in units of 10 should yield 5.70 MB but in fact yields 3.00 MB (oops). This is because the current algorithm doesn't correctly account for all the remainders in the logarithms. Fix this by doing a correct calculation in the remainders based on napier's algorithm. Additionally, now we have the correct result, we have to account for arithmetic rounding because we're printing 3 digits of precision. This means that if the fourth digit is five or greater, we have to round up, so add a section to ensure correct rounding. Finally account for all possible inputs correctly, including zero for block size. Fixes: b9f28d863594c429e1df35a0474d2663ca28b307 Signed-off-by: James Bottomley Reported-by: Vitaly Kuznetsov Cc: [delay until after 4.4 release] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4aba5827e764110bd1462eecf79209e656090f9c Author: Vitaly Kuznetsov Date: Thu Sep 17 16:01:51 2015 -0700 lib/string_helpers.c: fix infinite loop in string_get_size() [ Upstream commit 62bef58a55dfa8ada2a22b2496c6340468ecd98a ] Some string_get_size() calls (e.g.: string_get_size(1, 512, STRING_UNITS_10, ..., ...) string_get_size(15, 64, STRING_UNITS_10, ..., ...) ) result in an infinite loop. The problem is that if size is equal to divisor[units]/blk_size and is smaller than divisor[units] we'll end up with size == 0 when we start doing sf_cap calculations: For string_get_size(1, 512, STRING_UNITS_10, ..., ...) case: ... remainder = do_div(size, divisor[units]); -> size is 0, remainder is 1 remainder *= blk_size; -> remainder is 512 ... size *= blk_size; -> size is still 0 size += remainder / divisor[units]; -> size is still 0 The caller causing the issue is sd_read_capacity(), the problem was noticed on Hyper-V, such weird size was reported by host when scanning collides with device removal. This is probably a separate issue worth fixing, this patch is intended to prevent the library routine from infinite looping. Signed-off-by: Vitaly Kuznetsov Acked-by: James Bottomley Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: "K. Y. Srinivasan" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3730198645d95e2ac438ea9276402d3908b9449d Author: Junil Lee Date: Wed Jan 20 14:58:18 2016 -0800 zsmalloc: fix migrate_zspage-zs_free race condition [ Upstream commit c102f07ca0b04f2cb49cfc161c83f6239d17f491 ] record_obj() in migrate_zspage() does not preserve handle's HANDLE_PIN_BIT, set by find_aloced_obj()->trypin_tag(), and implicitly (accidentally) un-pins the handle, while migrate_zspage() still performs an explicit unpin_tag() on the that handle. This additional explicit unpin_tag() introduces a race condition with zs_free(), which can pin that handle by this time, so the handle becomes un-pinned. Schematically, it goes like this: CPU0 CPU1 migrate_zspage find_alloced_obj trypin_tag set HANDLE_PIN_BIT zs_free() pin_tag() obj_malloc() -- new object, no tag record_obj() -- remove HANDLE_PIN_BIT set HANDLE_PIN_BIT unpin_tag() -- remove zs_free's HANDLE_PIN_BIT The race condition may result in a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 00000000 CPU: 0 PID: 19001 Comm: CookieMonsterCl Tainted: PC is at get_zspage_mapping+0x0/0x24 LR is at obj_free.isra.22+0x64/0x128 Call trace: get_zspage_mapping+0x0/0x24 zs_free+0x88/0x114 zram_free_page+0x64/0xcc zram_slot_free_notify+0x90/0x108 swap_entry_free+0x278/0x294 free_swap_and_cache+0x38/0x11c unmap_single_vma+0x480/0x5c8 unmap_vmas+0x44/0x60 exit_mmap+0x50/0x110 mmput+0x58/0xe0 do_exit+0x320/0x8dc do_group_exit+0x44/0xa8 get_signal+0x538/0x580 do_signal+0x98/0x4b8 do_notify_resume+0x14/0x5c This patch keeps the lock bit in migration path and update value atomically. Signed-off-by: Junil Lee Signed-off-by: Minchan Kim Acked-by: Vlastimil Babka Cc: Sergey Senozhatsky Cc: [4.1+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a9c56fd066f9b5d222e0813b732908dabd721867 Author: Herbert Xu Date: Tue Jan 19 21:23:57 2016 +0800 crypto: algif_skcipher - sendmsg SG marking is off by one [ Upstream commit 202736d99b7f29279db9da61587f11a08a04a9c6 ] We mark the end of the SG list in sendmsg and sendpage and unmark it on the next send call. Unfortunately the unmarking in sendmsg is off-by-one, leading to an SG list that is too short. Fixes: 0f477b655a52 ("crypto: algif - Mark sgl end at the end of data") Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5446a444ae9e1976a77cb8faeab8198e44168daa Author: Nicholas Bellinger Date: Tue Jan 19 16:15:27 2016 -0800 iscsi-target: Fix potential dead-lock during node acl delete [ Upstream commit 26a99c19f810b2593410899a5b304b21b47428a6 ] This patch is a iscsi-target specific bug-fix for a dead-lock that can occur during explicit struct se_node_acl->acl_group se_session deletion via configfs rmdir(2), when iscsi-target time2retain timer is still active. It changes iscsi-target to obtain se_portal_group->session_lock internally using spin_in_locked() to check for the specific se_node_acl configfs shutdown rmdir(2) case. Note this patch is intended for stable, and the subsequent v4.5-rc patch converts target_core_tpg.c to use proper se_sess->sess_kref reference counting for both se_node_acl deletion + se_node_acl->queue_depth se_session restart. Reported-by:: Sagi Grimberg Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Andy Grover Cc: Mike Christie Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit e004a097257612853c63b3f47726fe04981e94c2 Author: Filipe Manana Date: Fri Jan 15 11:05:12 2016 +0000 Btrfs: fix deadlock running delayed iputs at transaction commit time [ Upstream commit c2d6cb1636d235257086f939a8194ef0bf93af6e ] While running a stress test I ran into a deadlock when running the delayed iputs at transaction time, which produced the following report and trace: [ 886.399989] ============================================= [ 886.400871] [ INFO: possible recursive locking detected ] [ 886.401663] 4.4.0-rc6-btrfs-next-18+ #1 Not tainted [ 886.402384] --------------------------------------------- [ 886.403182] fio/8277 is trying to acquire lock: [ 886.403568] (&fs_info->delayed_iput_sem){++++..}, at: [] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.403568] [ 886.403568] but task is already holding lock: [ 886.403568] (&fs_info->delayed_iput_sem){++++..}, at: [] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.403568] [ 886.403568] other info that might help us debug this: [ 886.403568] Possible unsafe locking scenario: [ 886.403568] [ 886.403568] CPU0 [ 886.403568] ---- [ 886.403568] lock(&fs_info->delayed_iput_sem); [ 886.403568] lock(&fs_info->delayed_iput_sem); [ 886.403568] [ 886.403568] *** DEADLOCK *** [ 886.403568] [ 886.403568] May be due to missing lock nesting notation [ 886.403568] [ 886.403568] 3 locks held by fio/8277: [ 886.403568] #0: (sb_writers#11){.+.+.+}, at: [] __sb_start_write+0x5f/0xb0 [ 886.403568] #1: (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [] btrfs_file_write_iter+0x73/0x408 [btrfs] [ 886.403568] #2: (&fs_info->delayed_iput_sem){++++..}, at: [] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.403568] [ 886.403568] stack backtrace: [ 886.403568] CPU: 6 PID: 8277 Comm: fio Not tainted 4.4.0-rc6-btrfs-next-18+ #1 [ 886.403568] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014 [ 886.403568] 0000000000000000 ffff88009f80f770 ffffffff8125d4fd ffffffff82af1fc0 [ 886.403568] ffff88009f80f830 ffffffff8108e5f9 0000000200000000 ffff88009fd92290 [ 886.403568] 0000000000000000 ffffffff82af1fc0 ffffffff829cfb01 00042b216d008804 [ 886.403568] Call Trace: [ 886.403568] [] dump_stack+0x4e/0x79 [ 886.403568] [] __lock_acquire+0xd42/0xf0b [ 886.403568] [] ? __module_address+0xdf/0x108 [ 886.403568] [] lock_acquire+0x10d/0x194 [ 886.403568] [] ? lock_acquire+0x10d/0x194 [ 886.403568] [] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.489542] [] down_read+0x3e/0x4d [ 886.489542] [] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.489542] [] btrfs_run_delayed_iputs+0x36/0xbf [btrfs] [ 886.489542] [] btrfs_commit_transaction+0x8f5/0x96e [btrfs] [ 886.489542] [] flush_space+0x435/0x44a [btrfs] [ 886.489542] [] ? reserve_metadata_bytes+0x26a/0x384 [btrfs] [ 886.489542] [] reserve_metadata_bytes+0x28d/0x384 [btrfs] [ 886.489542] [] ? btrfs_block_rsv_refill+0x58/0x96 [btrfs] [ 886.489542] [] btrfs_block_rsv_refill+0x70/0x96 [btrfs] [ 886.489542] [] btrfs_evict_inode+0x394/0x55a [btrfs] [ 886.489542] [] evict+0xa7/0x15c [ 886.489542] [] iput+0x1d3/0x266 [ 886.489542] [] btrfs_run_delayed_iputs+0x8f/0xbf [btrfs] [ 886.489542] [] btrfs_commit_transaction+0x8f5/0x96e [btrfs] [ 886.489542] [] ? signal_pending_state+0x31/0x31 [ 886.489542] [] btrfs_alloc_data_chunk_ondemand+0x1d7/0x288 [btrfs] [ 886.489542] [] btrfs_check_data_free_space+0x40/0x59 [btrfs] [ 886.489542] [] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs] [ 886.489542] [] btrfs_direct_IO+0x10c/0x27e [btrfs] [ 886.489542] [] generic_file_direct_write+0xb3/0x128 [ 886.489542] [] btrfs_file_write_iter+0x229/0x408 [btrfs] [ 886.489542] [] ? __lock_is_held+0x38/0x50 [ 886.489542] [] __vfs_write+0x7c/0xa5 [ 886.489542] [] vfs_write+0xa0/0xe4 [ 886.489542] [] SyS_write+0x50/0x7e [ 886.489542] [] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1081.852335] INFO: task fio:8244 blocked for more than 120 seconds. [ 1081.854348] Not tainted 4.4.0-rc6-btrfs-next-18+ #1 [ 1081.857560] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1081.863227] fio D ffff880213f9bb28 0 8244 8240 0x00000000 [ 1081.868719] ffff880213f9bb28 00ffffff810fc6b0 ffffffff0000000a ffff88023ed55240 [ 1081.872499] ffff880206b5d400 ffff880213f9c000 ffff88020a4d5318 ffff880206b5d400 [ 1081.876834] ffffffff00000001 ffff880206b5d400 ffff880213f9bb40 ffffffff81482ba4 [ 1081.880782] Call Trace: [ 1081.881793] [] schedule+0x7f/0x97 [ 1081.883340] [] rwsem_down_write_failed+0x2d5/0x325 [ 1081.895525] [] ? trace_hardirqs_on_caller+0x16/0x1ab [ 1081.897419] [] call_rwsem_down_write_failed+0x13/0x20 [ 1081.899251] [] ? call_rwsem_down_write_failed+0x13/0x20 [ 1081.901063] [] ? __down_write_nested.isra.0+0x1f/0x21 [ 1081.902365] [] down_write+0x43/0x57 [ 1081.903846] [] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1081.906078] [] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1081.908846] [] ? mark_held_locks+0x56/0x6c [ 1081.910409] [] btrfs_check_data_free_space+0x40/0x59 [btrfs] [ 1081.912482] [] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs] [ 1081.914597] [] btrfs_direct_IO+0x10c/0x27e [btrfs] [ 1081.919037] [] generic_file_direct_write+0xb3/0x128 [ 1081.920754] [] btrfs_file_write_iter+0x229/0x408 [btrfs] [ 1081.922496] [] ? __lock_is_held+0x38/0x50 [ 1081.923922] [] __vfs_write+0x7c/0xa5 [ 1081.925275] [] vfs_write+0xa0/0xe4 [ 1081.926584] [] SyS_write+0x50/0x7e [ 1081.927968] [] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1081.985293] INFO: lockdep is turned off. [ 1081.986132] INFO: task fio:8249 blocked for more than 120 seconds. [ 1081.987434] Not tainted 4.4.0-rc6-btrfs-next-18+ #1 [ 1081.988534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1081.990147] fio D ffff880218febbb8 0 8249 8240 0x00000000 [ 1081.991626] ffff880218febbb8 00ffffff81486b8e ffff88020000000b ffff88023ed75240 [ 1081.993258] ffff8802120a9a00 ffff880218fec000 ffff88020a4d5318 ffff8802120a9a00 [ 1081.994850] ffffffff00000001 ffff8802120a9a00 ffff880218febbd0 ffffffff81482ba4 [ 1081.996485] Call Trace: [ 1081.997037] [] schedule+0x7f/0x97 [ 1081.998017] [] rwsem_down_write_failed+0x2d5/0x325 [ 1081.999241] [] ? finish_wait+0x6d/0x76 [ 1082.000306] [] call_rwsem_down_write_failed+0x13/0x20 [ 1082.001533] [] ? call_rwsem_down_write_failed+0x13/0x20 [ 1082.002776] [] ? __down_write_nested.isra.0+0x1f/0x21 [ 1082.003995] [] down_write+0x43/0x57 [ 1082.005000] [] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1082.007403] [] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs] [ 1082.008988] [] btrfs_fallocate+0x7c1/0xc2f [btrfs] [ 1082.010193] [] ? percpu_down_read+0x4e/0x77 [ 1082.011280] [] ? __sb_start_write+0x5f/0xb0 [ 1082.012265] [] ? __sb_start_write+0x5f/0xb0 [ 1082.013021] [] vfs_fallocate+0x170/0x1ff [ 1082.013738] [] ioctl_preallocate+0x89/0x9b [ 1082.014778] [] do_vfs_ioctl+0x40a/0x4ea [ 1082.015778] [] ? SYSC_newfstat+0x25/0x2e [ 1082.016806] [] ? __fget_light+0x4d/0x71 [ 1082.017789] [] SyS_ioctl+0x57/0x79 [ 1082.018706] [] entry_SYSCALL_64_fastpath+0x12/0x6f This happens because we can recursively acquire the semaphore fs_info->delayed_iput_sem when attempting to allocate space to satisfy a file write request as shown in the first trace above - when committing a transaction we acquire (down_read) the semaphore before running the delayed iputs, and when running a delayed iput() we can end up calling an inode's eviction handler, which in turn commits another transaction and attempts to acquire (down_read) again the semaphore to run more delayed iput operations. This results in a deadlock because if a task acquires multiple times a semaphore it should invoke down_read_nested() with a different lockdep class for each level of recursion. Fix this by simplifying the implementation and use a mutex instead that is acquired by the cleaner kthread before it runs the delayed iputs instead of always acquiring a semaphore before delayed references are run from anywhere. Fixes: d7c151717a1e (btrfs: Fix NO_SPACE bug caused by delayed-iput) Cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit f3eaec38506470d74a642b9aa518ed1fd6849b57 Author: David Sterba Date: Thu Nov 19 14:15:51 2015 +0100 btrfs: put delayed item hook into inode [ Upstream commit 8089fe62c6603860f6796ca80519b92391292f21 ] Inodes for delayed iput allocate a trivial helper structure, let's place the list hook directly into the inode and save a kmalloc (killing a __GFP_NOFAIL as a bonus) at the cost of increasing size of btrfs_inode. The inode can be put into the delayed_iputs list more than once and we have to keep the count. This means we can't use the list_splice to process a bunch of inodes because we'd lost track of the count if the inode is put into the delayed iputs again while it's processed. Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c98b306e392edc0898a1dd715761998222c19676 Author: Josh Boyer Date: Wed Dec 9 21:12:52 2015 -0500 ideapad-laptop: Add Lenovo ideapad Y700-17ISK to no_hw_rfkill dmi list [ Upstream commit edde316acb5f07c04abf09a92f59db5d2efd14e2 ] One of the newest ideapad models also lacks a physical hw rfkill switch, and trying to read the hw rfkill switch through the ideapad module causes it to always reported blocking breaking wifi. Fix it by adding this model to the DMI list. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1286293 Cc: stable@vger.kernel.org Signed-off-by: Josh Boyer Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 34d7d523ecaa8c7a6857f97fd251e95e628aa17e Author: Vinit Agnihotri Date: Mon Jan 11 12:57:25 2016 -0500 IB/qib: Support creating qps with GFP_NOIO flag [ Upstream commit fbbeb8632bf0b46ab44cfcedc4654cd7831b7161 ] The current code is problematic when the QP creation and ipoib is used to support NFS and NFS desires to do IO for paging purposes. In that case, the GFP_KERNEL allocation in qib_qp.c causes a deadlock in tight memory situations. This fix adds support to create queue pair with GFP_NOIO flag for connected mode only to cleanly fail the create queue pair in those situations. Cc: # 3.16+ Reviewed-by: Mike Marciniszyn Signed-off-by: Vinit Agnihotri Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit dfaff0ef0343ba85ba3bac69a6547701425c0242 Author: Mike Marciniszyn Date: Thu Jan 7 16:44:10 2016 -0500 IB/qib: fix mcast detach when qp not attached [ Upstream commit 09dc9cd6528f5b52bcbd3292a6312e762c85260f ] The code produces the following trace: [1750924.419007] general protection fault: 0000 [#3] SMP [1750924.420364] Modules linked in: nfnetlink autofs4 rpcsec_gss_krb5 nfsv4 dcdbas rfcomm bnep bluetooth nfsd auth_rpcgss nfs_acl dm_multipath nfs lockd scsi_dh sunrpc fscache radeon ttm drm_kms_helper drm serio_raw parport_pc ppdev i2c_algo_bit lpc_ich ipmi_si ib_mthca ib_qib dca lp parport ib_ipoib mac_hid ib_cm i3000_edac ib_sa ib_uverbs edac_core ib_umad ib_mad ib_core ib_addr tg3 ptp dm_mirror dm_region_hash dm_log psmouse pps_core [1750924.420364] CPU: 1 PID: 8401 Comm: python Tainted: G D 3.13.0-39-generic #66-Ubuntu [1750924.420364] Hardware name: Dell Computer Corporation PowerEdge 860/0XM089, BIOS A04 07/24/2007 [1750924.420364] task: ffff8800366a9800 ti: ffff88007af1c000 task.ti: ffff88007af1c000 [1750924.420364] RIP: 0010:[] [] qib_mcast_qp_free+0x11/0x50 [ib_qib] [1750924.420364] RSP: 0018:ffff88007af1dd70 EFLAGS: 00010246 [1750924.420364] RAX: 0000000000000001 RBX: ffff88007b822688 RCX: 000000000000000f [1750924.420364] RDX: ffff88007b822688 RSI: ffff8800366c15a0 RDI: 6764697200000000 [1750924.420364] RBP: ffff88007af1dd78 R08: 0000000000000001 R09: 0000000000000000 [1750924.420364] R10: 0000000000000011 R11: 0000000000000246 R12: ffff88007baa1d98 [1750924.420364] R13: ffff88003ecab000 R14: ffff88007b822660 R15: 0000000000000000 [1750924.420364] FS: 00007ffff7fd8740(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000 [1750924.420364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1750924.420364] CR2: 00007ffff597c750 CR3: 000000006860b000 CR4: 00000000000007e0 [1750924.420364] Stack: [1750924.420364] ffff88007b822688 ffff88007af1ddf0 ffffffffa0132429 000000007af1de20 [1750924.420364] ffff88007baa1dc8 ffff88007baa0000 ffff88007af1de70 ffffffffa00cb313 [1750924.420364] 00007fffffffde88 0000000000000000 0000000000000008 ffff88003ecab000 [1750924.420364] Call Trace: [1750924.420364] [] qib_multicast_detach+0x1e9/0x350 [ib_qib] [1750924.568035] [] ? ib_uverbs_modify_qp+0x323/0x3d0 [ib_uverbs] [1750924.568035] [] ib_detach_mcast+0x31/0x50 [ib_core] [1750924.568035] [] ib_uverbs_detach_mcast+0x93/0x170 [ib_uverbs] [1750924.568035] [] ib_uverbs_write+0xc6/0x2c0 [ib_uverbs] [1750924.568035] [] ? apparmor_file_permission+0x18/0x20 [1750924.568035] [] ? security_file_permission+0x23/0xa0 [1750924.568035] [] vfs_write+0xb4/0x1f0 [1750924.568035] [] SyS_write+0x49/0xa0 [1750924.568035] [] system_call_fastpath+0x1a/0x1f [1750924.568035] Code: 66 2e 0f 1f 84 00 00 00 00 00 31 c0 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 10 ff 8f 40 01 00 00 74 0e 48 89 df e8 8e f8 06 e1 5b 5d c3 0f [1750924.568035] RIP [] qib_mcast_qp_free+0x11/0x50 [ib_qib] [1750924.568035] RSP [1750924.650439] ---[ end trace 73d5d4b3f8ad4851 ] The fix is to note the qib_mcast_qp that was found. If none is found, then return EINVAL indicating the error. Cc: Reviewed-by: Dennis Dalessandro Reported-by: Jason Gunthorpe Signed-off-by: Mike Marciniszyn Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 5d545a70cca8594f6120a9e3d70187920e62ce77 Author: Jean Delvare Date: Mon Jan 18 17:06:05 2016 +0100 crypto: crc32c - Fix crc32c soft dependency [ Upstream commit fd7f6727102a1ccf6b4c1dfcc631f9b546526b26 ] I don't think it makes sense for a module to have a soft dependency on itself. This seems quite cyclic by nature and I can't see what purpose it could serve. OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty much assumes that some incarnation of the "crc32c" hash algorithm has been loaded. Therefore it makes sense to have the soft dependency there (as crc-t10dif does.) Cc: stable@vger.kernel.org Cc: Tim Chen Cc: "David S. Miller" Signed-off-by: Jean Delvare Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4126014e7cd0d5e667953610139b20388910cbbd Author: Dave Chinner Date: Tue Jan 19 08:28:10 2016 +1100 xfs: log mount failures don't wait for buffers to be released [ Upstream commit 85bec5460ad8e05e0a8d70fb0f6750eb719ad092 ] Recently I've been seeing xfs/051 fail on 1k block size filesystems. Trying to trace the events during the test lead to the problem going away, indicating that it was a race condition that lead to this ASSERT failure: XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 156 ..... [] xfs_free_perag+0x87/0xb0 [] xfs_mountfs+0x4d9/0x900 [] xfs_fs_fill_super+0x3bf/0x4d0 [] mount_bdev+0x180/0x1b0 [] xfs_fs_mount+0x15/0x20 [] mount_fs+0x38/0x170 [] vfs_kern_mount+0x67/0x120 [] do_mount+0x218/0xd60 [] SyS_mount+0x8b/0xd0 When I finally caught it with tracing enabled, I saw that AG 2 had an elevated reference count and a buffer was responsible for it. I tracked down the specific buffer, and found that it was missing the final reference count release that would put it back on the LRU and hence be found by xfs_wait_buftarg() calls in the log mount failure handling. The last four traces for the buffer before the assert were (trimmed for relevance) kworker/0:1-5259 xfs_buf_iodone: hold 2 lock 0 flags ASYNC kworker/0:1-5259 xfs_buf_ioerror: hold 2 lock 0 error -5 mount-7163 xfs_buf_lock_done: hold 2 lock 0 flags ASYNC mount-7163 xfs_buf_unlock: hold 2 lock 1 flags ASYNC This is an async write that is completing, so there's nobody waiting for it directly. Hence we call xfs_buf_relse() once all the processing is complete. That does: static inline void xfs_buf_relse(xfs_buf_t *bp) { xfs_buf_unlock(bp); xfs_buf_rele(bp); } Now, it's clear that mount is waiting on the buffer lock, and that it has been released by xfs_buf_relse() and gained by mount. This is expected, because at this point the mount process is in xfs_buf_delwri_submit() waiting for all the IO it submitted to complete. The mount process, however, is waiting on the lock for the buffer because it is in xfs_buf_delwri_submit(). This waits for IO completion, but it doesn't wait for the buffer reference owned by the IO to go away. The mount process collects all the completions, fails the log recovery, and the higher level code then calls xfs_wait_buftarg() to free all the remaining buffers in the filesystem. The issue is that on unlocking the buffer, the scheduler has decided that the mount process has higher priority than the the kworker thread that is running the IO completion, and so immediately switched contexts to the mount process from the semaphore unlock code, hence preventing the kworker thread from finishing the IO completion and releasing the IO reference to the buffer. Hence by the time that xfs_wait_buftarg() is run, the buffer still has an active reference and so isn't on the LRU list that the function walks to free the remaining buffers. Hence we miss that buffer and continue onwards to tear down the mount structures, at which time we get find a stray reference count on the perag structure. On a non-debug kernel, this will be ignored and the structure torn down and freed. Hence when the kworker thread is then rescheduled and the buffer released and freed, it will access a freed perag structure. The problem here is that when the log mount fails, we still need to quiesce the log to ensure that the IO workqueues have returned to idle before we run xfs_wait_buftarg(). By synchronising the workqueues, we ensure that all IO completions are fully processed, not just to the point where buffers have been unlocked. This ensures we don't end up in the situation above. cc: # 3.18 Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 34d751ee6985e545e5de6d2c626e33001ea5fc5b Author: Arnd Bergmann Date: Mon Jan 18 10:45:00 2016 +0100 ARM: debug-ll: fix BCM63xx entry for multiplatform [ Upstream commit 6c54809977de3c9e2ef9e9934a2c6625f7e161e7 ] During my randconfig build testing, I found that a kernel with DEBUG_AT91_UART and ARCH_BCM_63XX fails to build: arch/arm/include/debug/at91.S:18:0: error: "CONFIG_DEBUG_UART_VIRT" redefined [-Werror] It turns out that the DEBUG_UART_BCM63XX option is enabled whenever the ARCH_BCM_63XX is, and that breaks multiplatform kernels because we then end up using the UART address from BCM63XX rather than the one we actually configured (if any). This changes the BCM63XX options to only have one Kconfig option, and only enable that if the user explicitly turns it on. Signed-off-by: Arnd Bergmann Fixes: b51312bebfa4 ("ARM: BCM63XX: add low-level UART debug support") Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 40ced0bb2cd8bd17c4f1061176c2ca1db71ec667 Author: Songjun Wu Date: Mon Jan 18 11:14:44 2016 +0100 dmaengine: at_xdmac: fix resume for cyclic transfers [ Upstream commit 611dcadb01c89d1d3521450c05a4ded332e5a32d ] When having cyclic transfers, the channel was paused when performing suspend but was not correctly resumed. Signed-off-by: Songjun Wu Signed-off-by: Ludovic Desroches Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Cc: # 4.1 and later Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3a1e81ad84e4d880b00ecf7ad8d03b9b772ddfa7 Author: Herbert Xu Date: Fri Jan 15 22:01:08 2016 +0800 crypto: algif_hash - Fix race condition in hash_check_key [ Upstream commit ad46d7e33219218605ea619e32553daf4f346b9f ] We need to lock the child socket in hash_check_key as otherwise two simultaneous calls can cause the parent socket to be freed. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8515819fff8fce56be067af985016b6356d1fe5e Author: Herbert Xu Date: Wed Jan 13 15:03:32 2016 +0800 crypto: af_alg - Forbid bind(2) when nokey child sockets are present [ Upstream commit a6a48c565f6f112c6983e2a02b1602189ed6e26e ] This patch forbids the calling of bind(2) when there are child sockets created by accept(2) in existence, even if they are created on the nokey path. This is needed as those child sockets have references to the tfm object which bind(2) will destroy. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 279792e1f4f66d719fe9ff7c720dd600d9880fbf Author: Herbert Xu Date: Wed Jan 13 15:00:36 2016 +0800 crypto: algif_hash - Remove custom release parent function [ Upstream commit f1d84af1835846a5a2b827382c5848faf2bb0e75 ] This patch removes the custom release parent function as the generic af_alg_release_parent now works for nokey sockets too. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 99214a2ff7f6faef389659e93dafdf41ae86a72b Author: Herbert Xu Date: Wed Jan 13 14:59:03 2016 +0800 crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path [ Upstream commit 6a935170a980024dd29199e9dbb5c4da4767a1b9 ] This patch allows af_alg_release_parent to be called even for nokey sockets. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e1ed9a4b4380fc33c558a0c1bd7cbf527e891151 Author: Herbert Xu Date: Fri Jan 8 21:31:04 2016 +0800 crypto: algif_hash - Require setkey before accept(2) [ Upstream commit 6de62f15b581f920ade22d758f4c338311c2f0d4 ] Hash implementations that require a key may crash if you use them without setting a key. This patch adds the necessary checks so that if you do attempt to use them without a key that we return -ENOKEY instead of proceeding. This patch also adds a compatibility path to support old applications that do acept(2) before setkey. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c409087e6db988257adffb614616764116c7337e Author: Herbert Xu Date: Fri Jan 8 21:28:26 2016 +0800 crypto: hash - Add crypto_ahash_has_setkey [ Upstream commit a5596d6332787fd383b3b5427b41f94254430827 ] This patch adds a way for ahash users to determine whether a key is required by a crypto_ahash transform. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 92d76b5b2c3a29e14bc01a5e96d075afd4c6644f Author: Herbert Xu Date: Mon Jan 4 13:35:18 2016 +0900 crypto: af_alg - Add nokey compatibility path [ Upstream commit 37766586c965d63758ad542325a96d5384f4a8c9 ] This patch adds a compatibility path to support old applications that do acept(2) before setkey. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fa988b35c2e40f38e57388a1a3f48de056e81dd3 Author: Herbert Xu Date: Wed Dec 30 20:24:17 2015 +0800 crypto: af_alg - Fix socket double-free when accept fails [ Upstream commit a383292c86663bbc31ac62cc0c04fc77504636a6 ] When we fail an accept(2) call we will end up freeing the socket twice, once due to the direct sk_free call and once again through newsock. This patch fixes this by removing the sk_free call. Cc: stable@vger.kernel.org Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0571ba52a19e18a1c20469454231eef681cb1310 Author: Herbert Xu Date: Wed Dec 30 11:47:53 2015 +0800 crypto: af_alg - Disallow bind/setkey/... after accept(2) [ Upstream commit c840ac6af3f8713a71b4d2363419145760bd6044 ] Each af_alg parent socket obtained by socket(2) corresponds to a tfm object once bind(2) has succeeded. An accept(2) call on that parent socket creates a context which then uses the tfm object. Therefore as long as any child sockets created by accept(2) exist the parent socket must not be modified or freed. This patch guarantees this by using locks and a reference count on the parent socket. Any attempt to modify the parent socket will fail with EBUSY. Cc: stable@vger.kernel.org Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bc24ac15b0746172a8f603171352aa54abcf7c78 Author: Tejun Heo Date: Fri Jan 15 16:58:24 2016 -0800 printk: do cond_resched() between lines while outputting to consoles [ Upstream commit 8d91f8b15361dfb438ab6eb3b319e2ded43458ff ] @console_may_schedule tracks whether console_sem was acquired through lock or trylock. If the former, we're inside a sleepable context and console_conditional_schedule() performs cond_resched(). This allows console drivers which use console_lock for synchronization to yield while performing time-consuming operations such as scrolling. However, the actual console outputting is performed while holding irq-safe logbuf_lock, so console_unlock() clears @console_may_schedule before starting outputting lines. Also, only a few drivers call console_conditional_schedule() to begin with. This means that when a lot of lines need to be output by console_unlock(), for example on a console registration, the task doing console_unlock() may not yield for a long time on a non-preemptible kernel. If this happens with a slow console devices, for example a serial console, the outputting task may occupy the cpu for a very long time. Long enough to trigger softlockup and/or RCU stall warnings, which in turn pile more messages, sometimes enough to trigger the next cycle of warnings incapacitating the system. Fix it by making console_unlock() insert cond_resched() between lines if @console_may_schedule. Signed-off-by: Tejun Heo Reported-by: Calvin Owens Acked-by: Jan Kara Cc: Dave Jones Cc: Kyle McMartin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0e19e24c3fe0abde8e2c5f4543616a251ccea6bf Author: Vitaly Kuznetsov Date: Fri Nov 20 15:57:24 2015 -0800 kernel/panic.c: turn off locks debug before releasing console lock [ Upstream commit 7625b3a0007decf2b135cb47ca67abc78a7b1bc1 ] Commit 08d78658f393 ("panic: release stale console lock to always get the logbuf printed out") introduced an unwanted bad unlock balance report when panic() is called directly and not from OOPS (e.g. from out_of_memory()). The difference is that in case of OOPS we disable locks debug in oops_enter() and on direct panic call nobody does that. Fixes: 08d78658f393 ("panic: release stale console lock to always get the logbuf printed out") Reported-by: kernel test robot Signed-off-by: Vitaly Kuznetsov Cc: HATAYAMA Daisuke Cc: Masami Hiramatsu Cc: Jiri Kosina Cc: Baoquan He Cc: Prarit Bhargava Cc: Xie XiuQi Cc: Seth Jennings Cc: "K. Y. Srinivasan" Cc: Jan Kara Cc: Petr Mladek Cc: Yasuaki Ishimatsu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 94ecf566322c74e13509e834605e71b332d2469f Author: Vitaly Kuznetsov Date: Fri Nov 6 16:32:58 2015 -0800 panic: release stale console lock to always get the logbuf printed out [ Upstream commit 08d78658f393fefaa2e6507ea052c6f8ef4002a2 ] In some cases we may end up killing the CPU holding the console lock while still having valuable data in logbuf. E.g. I'm observing the following: - A crash is happening on one CPU and console_unlock() is being called on some other. - console_unlock() tries to print out the buffer before releasing the lock and on slow console it takes time. - in the meanwhile crashing CPU does lots of printk()-s with valuable data (which go to the logbuf) and sends IPIs to all other CPUs. - console_unlock() finishes printing previous chunk and enables interrupts before trying to print out the rest, the CPU catches the IPI and never releases console lock. This is not the only possible case: in VT/fb subsystems we have many other console_lock()/console_unlock() users. Non-masked interrupts (or receiving NMI in case of extreme slowness) will have the same result. Getting the whole console buffer printed out on crash should be top priority. [akpm@linux-foundation.org: tweak comment text] Signed-off-by: Vitaly Kuznetsov Cc: HATAYAMA Daisuke Cc: Masami Hiramatsu Cc: Jiri Kosina Cc: Baoquan He Cc: Prarit Bhargava Cc: Xie XiuQi Cc: Seth Jennings Cc: "K. Y. Srinivasan" Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2c641f5b0c8e87d43235ce39890bcc4d0c7cd2fb Author: Martijn Coenen Date: Fri Jan 15 16:57:49 2016 -0800 memcg: only free spare array when readers are done [ Upstream commit 6611d8d76132f86faa501de9451a89bf23fb2371 ] A spare array holding mem cgroup threshold events is kept around to make sure we can always safely deregister an event and have an array to store the new set of events in. In the scenario where we're going from 1 to 0 registered events, the pointer to the primary array containing 1 event is copied to the spare slot, and then the spare slot is freed because no events are left. However, it is freed before calling synchronize_rcu(), which means readers may still be accessing threshold->primary after it is freed. Fixed by only freeing after synchronize_rcu(). Signed-off-by: Martijn Coenen Cc: Johannes Weiner Acked-by: Michal Hocko Cc: Vladimir Davydov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4ae0f4a619e2071dc184e0792d90ace3fd18c280 Author: Naoya Horiguchi Date: Fri Jan 15 16:54:03 2016 -0800 mm: soft-offline: check return value in second __get_any_page() call [ Upstream commit d96b339f453997f2f08c52da3f41423be48c978f ] I saw the following BUG_ON triggered in a testcase where a process calls madvise(MADV_SOFT_OFFLINE) on thps, along with a background process that calls migratepages command repeatedly (doing ping-pong among different NUMA nodes) for the first process: Soft offlining page 0x60000 at 0x700000600000 __get_any_page: 0x60000 free buddy page page:ffffea0001800000 count:0 mapcount:-127 mapping: (null) index:0x1 flags: 0x1fffc0000000000() page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0) ------------[ cut here ]------------ kernel BUG at /src/linux-dev/include/linux/mm.h:342! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: cfg80211 rfkill crc32c_intel serio_raw virtio_balloon i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi CPU: 3 PID: 3035 Comm: test_alloc_gene Tainted: G O 4.4.0-rc8-v4.4-rc8-160107-1501-00000-rc8+ #74 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff88007c63d5c0 ti: ffff88007c210000 task.ti: ffff88007c210000 RIP: 0010:[] [] put_page+0x5c/0x60 RSP: 0018:ffff88007c213e00 EFLAGS: 00010246 Call Trace: put_hwpoison_page+0x4e/0x80 soft_offline_page+0x501/0x520 SyS_madvise+0x6bc/0x6f0 entry_SYSCALL_64_fastpath+0x12/0x6a Code: 8b fc ff ff 5b 5d c3 48 89 df e8 b0 fa ff ff 48 89 df 31 f6 e8 c6 7d ff ff 5b 5d c3 48 c7 c6 08 54 a2 81 48 89 df e8 a4 c5 01 00 <0f> 0b 66 90 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b 47 RIP [] put_page+0x5c/0x60 RSP The root cause resides in get_any_page() which retries to get a refcount of the page to be soft-offlined. This function calls put_hwpoison_page(), expecting that the target page is putback to LRU list. But it can be also freed to buddy. So the second check need to care about such case. Fixes: af8fae7c0886 ("mm/memory-failure.c: clean up soft_offline_page()") Signed-off-by: Naoya Horiguchi Cc: Sasha Levin Cc: Aneesh Kumar K.V Cc: Vlastimil Babka Cc: Jerome Marchand Cc: Andrea Arcangeli Cc: Hugh Dickins Cc: Dave Hansen Cc: Mel Gorman Cc: Rik van Riel Cc: Steve Capper Cc: Johannes Weiner Cc: Michal Hocko Cc: Christoph Lameter Cc: David Rientjes Cc: [3.9+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7332411bbb9f327e65467013ef10d1d0f4999fcb Author: Kyeongdon Kim Date: Thu Jan 14 15:22:29 2016 -0800 zram: try vmalloc() after kmalloc() [ Upstream commit d913897abace843bba20249f3190167f7895e9c3 ] When we're using LZ4 multi compression streams for zram swap, we found out page allocation failure message in system running test. That was not only once, but a few(2 - 5 times per test). Also, some failure cases were continually occurring to try allocation order 3. In order to make parallel compression private data, we should call kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order 2/3 size memory to allocate in that time, page allocation fails. This patch makes to use vmalloc() as fallback of kmalloc(), this prevents page alloc failure warning. After using this, we never found warning message in running test, also It could reduce process startup latency about 60-120ms in each case. For reference a call trace : Binder_1: page allocation failure: order:3, mode:0x10c0d0 CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20 Call trace: dump_backtrace+0x0/0x270 show_stack+0x10/0x1c dump_stack+0x1c/0x28 warn_alloc_failed+0xfc/0x11c __alloc_pages_nodemask+0x724/0x7f0 __get_free_pages+0x14/0x5c kmalloc_order_trace+0x38/0xd8 zcomp_lz4_create+0x2c/0x38 zcomp_strm_alloc+0x34/0x78 zcomp_strm_multi_find+0x124/0x1ec zcomp_strm_find+0xc/0x18 zram_bvec_rw+0x2fc/0x780 zram_make_request+0x25c/0x2d4 generic_make_request+0x80/0xbc submit_bio+0xa4/0x15c __swap_writepage+0x218/0x230 swap_writepage+0x3c/0x4c shrink_page_list+0x51c/0x8d0 shrink_inactive_list+0x3f8/0x60c shrink_lruvec+0x33c/0x4cc shrink_zone+0x3c/0x100 try_to_free_pages+0x2b8/0x54c __alloc_pages_nodemask+0x514/0x7f0 __get_free_pages+0x14/0x5c proc_info_read+0x50/0xe4 vfs_read+0xa0/0x12c SyS_read+0x44/0x74 DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB [minchan@kernel.org: change vmalloc gfp and adding comment about gfp] [sergey.senozhatsky@gmail.com: tweak comments and styles] Signed-off-by: Kyeongdon Kim Signed-off-by: Minchan Kim Acked-by: Sergey Senozhatsky Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 664ecf4f243bac17065cd9878790d40a592e2f3d Author: Sergey Senozhatsky Date: Thu Jan 14 15:22:26 2016 -0800 zram/zcomp: use GFP_NOIO to allocate streams [ Upstream commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa ] We can end up allocating a new compression stream with GFP_KERNEL from within the IO path, which may result is nested (recursive) IO operations. That can introduce problems if the IO path in question is a reclaimer, holding some locks that will deadlock nested IOs. Allocate streams and working memory using GFP_NOIO flag, forbidding recursive IO and FS operations. An example: inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage. git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes: (jbd2_handle){+.+.?.}, at: start_this_handle+0x4ca/0x555 {IN-RECLAIM_FS-W} state was registered at: __lock_acquire+0x8da/0x117b lock_acquire+0x10c/0x1a7 start_this_handle+0x52d/0x555 jbd2__journal_start+0xb4/0x237 __ext4_journal_start_sb+0x108/0x17e ext4_dirty_inode+0x32/0x61 __mark_inode_dirty+0x16b/0x60c iput+0x11e/0x274 __dentry_kill+0x148/0x1b8 shrink_dentry_list+0x274/0x44a prune_dcache_sb+0x4a/0x55 super_cache_scan+0xfc/0x176 shrink_slab.part.14.constprop.25+0x2a2/0x4d3 shrink_zone+0x74/0x140 kswapd+0x6b7/0x930 kthread+0x107/0x10f ret_from_fork+0x3f/0x70 irq event stamp: 138297 hardirqs last enabled at (138297): debug_check_no_locks_freed+0x113/0x12f hardirqs last disabled at (138296): debug_check_no_locks_freed+0x33/0x12f softirqs last enabled at (137818): __do_softirq+0x2d3/0x3e9 softirqs last disabled at (137813): irq_exit+0x41/0x95 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(jbd2_handle); lock(jbd2_handle); *** DEADLOCK *** 5 locks held by git/20158: #0: (sb_writers#7){.+.+.+}, at: [] mnt_want_write+0x24/0x4b #1: (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [] lock_rename+0xd9/0xe3 #2: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [] lock_two_nondirectories+0x3f/0x6b #3: (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [] lock_two_nondirectories+0x66/0x6b #4: (jbd2_handle){+.+.?.}, at: [] start_this_handle+0x4ca/0x555 stack backtrace: CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211 Call Trace: dump_stack+0x4c/0x6e mark_lock+0x384/0x56d mark_held_locks+0x5f/0x76 lockdep_trace_alloc+0xb2/0xb5 kmem_cache_alloc_trace+0x32/0x1e2 zcomp_strm_alloc+0x25/0x73 [zram] zcomp_strm_multi_find+0xe7/0x173 [zram] zcomp_strm_find+0xc/0xe [zram] zram_bvec_rw+0x2ca/0x7e0 [zram] zram_make_request+0x1fa/0x301 [zram] generic_make_request+0x9c/0xdb submit_bio+0xf7/0x120 ext4_io_submit+0x2e/0x43 ext4_bio_write_page+0x1b7/0x300 mpage_submit_page+0x60/0x77 mpage_map_and_submit_buffers+0x10f/0x21d ext4_writepages+0xc8c/0xe1b do_writepages+0x23/0x2c __filemap_fdatawrite_range+0x84/0x8b filemap_flush+0x1c/0x1e ext4_alloc_da_blocks+0xb8/0x117 ext4_rename+0x132/0x6dc ? mark_held_locks+0x5f/0x76 ext4_rename2+0x29/0x2b vfs_rename+0x540/0x636 SyS_renameat2+0x359/0x44d SyS_rename+0x1e/0x20 entry_SYSCALL_64_fastpath+0x12/0x6f [minchan@kernel.org: add stable mark] Signed-off-by: Sergey Senozhatsky Acked-by: Minchan Kim Cc: Kyeongdon Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 39e51d967413e64c40eae6201430b1ffdb90ba08 Author: Ravi Bangoria Date: Mon Dec 7 12:25:02 2015 +0530 perf kvm record/report: 'unprocessable sample' error while recording/reporting guest data [ Upstream commit 3caeaa562733c4836e61086ec07666635006a787 ] While recording guest samples in host using perf kvm record, it will populate unprocessable sample error, though samples will be recorded properly. While generating report using perf kvm report, no samples will be processed and same error will populate. We have seen this behaviour with upstream perf(4.4-rc3) on x86 and ppc64 hardware. Reason behind this failure is, when it tries to fetch machine from rb_tree of machines, it fails. As a part of tracing a bug, we figured out that this code was incorrectly refactored in commit 54245fdc3576 ("perf session: Remove wrappers to machines__find"). This patch will change the functionality such that if it can't fetch machine in first trial, it will create one node of machine and add that to rb_tree. So next time when it tries to fetch same machine from rb_tree, it won't fail. Actually it was the case before refactoring of code in aforementioned commit. This patch is generated from acme perf/core branch. Below I've mention an example that demonstrate the behaviour before and after applying patch. Before applying patch: [Note: One needs to run guest before recording data in host] ravi@ravi-bangoria:~$ ./perf kvm record -a Warning: 5903 unprocessable samples recorded. Do you have a KVM guest running and not using 'perf kvm'? [ perf record: Captured and wrote 1.409 MB perf.data.guest (285 samples) ] ravi@ravi-bangoria:~$ ./perf kvm report --stdio Warning: 5903 unprocessable samples recorded. Do you have a KVM guest running and not using 'perf kvm'? # To display the perf.data header info, please use --header/--header-only options. # # Total Lost Samples: 0 # # Samples: 285 of event 'cycles' # Event count (approx.): 88715406 # # Overhead Command Shared Object Symbol # ........ ....... ............. ...... # # (For a higher level overview, try: perf report --sort comm,dso) # After applying patch: ravi@ravi-bangoria:~$ ./perf kvm record -a [ perf record: Captured and wrote 1.188 MB perf.data.guest (17 samples) ] ravi@ravi-bangoria:~$ ./perf kvm report --stdio # To display the perf.data header info, please use --header/--header-only options. # # Total Lost Samples: 0 # # Samples: 17 of event 'cycles' # Event count (approx.): 700746 # # Overhead Command Shared Object Symbol # ........ ....... ................ ...................... # 34.19% :5758 [unknown] [g] 0xffffffff818682ab 22.79% :5758 [unknown] [g] 0xffffffff812dc7f8 22.79% :5758 [unknown] [g] 0xffffffff818650d0 14.83% :5758 [unknown] [g] 0xffffffff8161a1b6 2.49% :5758 [unknown] [g] 0xffffffff818692bf 0.48% :5758 [unknown] [g] 0xffffffff81869253 0.05% :5758 [unknown] [g] 0xffffffff81869250 Signed-off-by: Ravi Bangoria Cc: Naveen N. Rao Cc: stable@vger.kernel.org # v3.19+ Fixes: 54245fdc3576 ("perf session: Remove wrappers to machines__find") Link: http://lkml.kernel.org/r/1449471302-11283-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8467278d965a3c2c2f2e95c8eb723f47b872ad5d Author: xuejiufei Date: Thu Jan 14 15:17:38 2016 -0800 ocfs2/dlm: ignore cleaning the migration mle that is inuse [ Upstream commit bef5502de074b6f6fa647b94b73155d675694420 ] We have found that migration source will trigger a BUG that the refcount of mle is already zero before put when the target is down during migration. The situation is as follows: dlm_migrate_lockres dlm_add_migration_mle dlm_mark_lockres_migrating dlm_get_mle_inuse <<<<<< Now the refcount of the mle is 2. dlm_send_one_lockres and wait for the target to become the new master. <<<<<< o2hb detect the target down and clean the migration mle. Now the refcount is 1. dlm_migrate_lockres woken, and put the mle twice when found the target goes down which trigger the BUG with the following message: "ERROR: bad mle: ". Signed-off-by: Jiufei Xue Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c91d339da50d0f1e1f61556fa6ef3374d6810c80 Author: Sergey Senozhatsky Date: Thu Jan 14 15:16:53 2016 -0800 scripts/bloat-o-meter: fix python3 syntax error [ Upstream commit 72214a24a7677d4c7501eecc9517ed681b5f2db2 ] In Python3+ print is a function so the old syntax is not correct anymore: $ ./scripts/bloat-o-meter vmlinux.o vmlinux.o.old File "./scripts/bloat-o-meter", line 61 print "add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s)" % \ ^ SyntaxError: invalid syntax Fix by calling print as a function. Tested on python 2.7.11, 3.5.1 Signed-off-by: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 68cc9774de3e0ad8de67d6fbbdaf4a808cbc62a9 Author: Laura Abbott Date: Thu Jan 14 15:16:50 2016 -0800 dma-debug: switch check from _text to _stext [ Upstream commit ea535e418c01837d07b6c94e817540f50bfdadb0 ] In include/asm-generic/sections.h: /* * Usage guidelines: * _text, _data: architecture specific, don't use them in * arch-independent code * [_stext, _etext]: contains .text.* sections, may also contain * .rodata.* * and/or .init.* sections _text is not guaranteed across architectures. Architectures such as ARM may reuse parts which are not actually text and erroneously trigger a bug. Switch to using _stext which is guaranteed to contain text sections. Came out of https://lkml.kernel.org/g/<567B1176.4000106@redhat.com> Signed-off-by: Laura Abbott Reviewed-by: Kees Cook Cc: Russell King Cc: Arnd Bergmann Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a5254ac06b9aaf6ef99bb260fe713f6a64371353 Author: Sudip Mukherjee Date: Thu Jan 14 15:16:47 2016 -0800 m32r: fix m32104ut_defconfig build fail [ Upstream commit 601f1db653217f205ffa5fb33514b4e1711e56d1 ] The build of m32104ut_defconfig for m32r arch was failing for long long time with the error: ERROR: "memory_start" [fs/udf/udf.ko] undefined! ERROR: "memory_end" [fs/udf/udf.ko] undefined! ERROR: "memory_end" [drivers/scsi/sg.ko] undefined! ERROR: "memory_start" [drivers/scsi/sg.ko] undefined! ERROR: "memory_end" [drivers/i2c/i2c-dev.ko] undefined! ERROR: "memory_start" [drivers/i2c/i2c-dev.ko] undefined! As done in other architectures export the symbols to fix the error. Reported-by: Fengguang Wu Signed-off-by: Sudip Mukherjee Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c5882812d2e1ab7db5bc71a1bca90b3a2d89dedd Author: Vasily Averin Date: Thu Jan 14 13:41:14 2016 +0300 cifs_dbg() outputs an uninitialized buffer in cifs_readdir() [ Upstream commit 01b9b0b28626db4a47d7f48744d70abca9914ef1 ] In some cases tmp_bug can be not filled in cifs_filldir and stay uninitialized, therefore its printk with "%s" modifier can leak content of kernelspace memory. If old content of this buffer does not contain '\0' access bejond end of allocated object can crash the host. Signed-off-by: Vasily Averin Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit 99b79b15df4ed1a6293cff487b46efc86bd20ae5 Author: Rabin Vincent Date: Wed Dec 23 07:32:41 2015 +0100 cifs: fix race between call_async() and reconnect() [ Upstream commit 820962dc700598ffe8cd21b967e30e7520c34748 ] cifs_call_async() queues the MID to the pending list and calls smb_send_rqst(). If smb_send_rqst() performs a partial send, it sets the tcpStatus to CifsNeedReconnect and returns an error code to cifs_call_async(). In this case, cifs_call_async() removes the MID from the list and returns to the caller. However, cifs_call_async() releases the server mutex _before_ removing the MID. This means that a cifs_reconnect() can race with this function and manage to remove the MID from the list and delete the entry before cifs_call_async() calls cifs_delete_mid(). This leads to various crashes due to the use after free in cifs_delete_mid(). Task1 Task2 cifs_call_async(): - rc = -EAGAIN - mutex_unlock(srv_mutex) cifs_reconnect(): - mutex_lock(srv_mutex) - mutex_unlock(srv_mutex) - list_delete(mid) - mid->callback() cifs_writev_callback(): - mutex_lock(srv_mutex) - delete(mid) - mutex_unlock(srv_mutex) - cifs_delete_mid(mid) <---- use after free Fix this by removing the MID in cifs_call_async() before releasing the srv_mutex. Also hold the srv_mutex in cifs_reconnect() until the MIDs are moved out of the pending list. Signed-off-by: Rabin Vincent Acked-by: Shirish Pargaonkar CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ca7342a8a39704670c4079aacbd78e360beaf223 Author: Jamie Bainbridge Date: Sat Nov 7 22:13:49 2015 +1000 cifs: Ratelimit kernel log messages [ Upstream commit ec7147a99e33a9e4abad6fc6e1b40d15df045d53 ] Under some conditions, CIFS can repeatedly call the cifs_dbg() logging wrapper. If done rapidly enough, the console framebuffer can softlockup or "rcu_sched self-detected stall". Apply the built-in log ratelimiters to prevent such hangs. Signed-off-by: Jamie Bainbridge Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit 5301c0647782e71150361a3854ccf3e004b79bb9 Author: Dmitry V. Levin Date: Sun Dec 27 02:13:27 2015 +0300 sparc64: fix incorrect sign extension in sys_sparc64_personality [ Upstream commit 525fd5a94e1be0776fa652df5c687697db508c91 ] The value returned by sys_personality has type "long int". It is saved to a variable of type "int", which is not a problem yet because the type of task_struct->pesonality is "unsigned int". The problem is the sign extension from "int" to "long int" that happens on return from sys_sparc64_personality. For example, a userspace call personality((unsigned) -EINVAL) will result to any subsequent personality call, including absolutely harmless read-only personality(0xffffffff) call, failing with errno set to EINVAL. Signed-off-by: Dmitry V. Levin Cc: Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2a048a248fad2e7d49a3a5c8b9259f403182b5ac Author: Carlo Caione Date: Wed Jan 13 09:36:55 2016 +0100 mmc: core: Enable tuning according to the actual timing [ Upstream commit e10c321977091f163eceedec0650e0ef4b3cf4bb ] While in sdhci_execute_tuning() the choice whether or not to enable the tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the check is done on the capability of the card. This difference is causing some issues with some SDIO cards in DDR50 mode where the CDM19 is wrongly issued. With this patch we modify the check in both mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision only according to the actual timing specification. Cc: stable@vger.kernel.org Signed-off-by: Carlo Caione Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 6e1e9bd06060eedf56db7aa53909b52944fc3d06 Author: Weijun Yang Date: Sun Oct 4 12:04:11 2015 +0000 mmc: core: enable CMD19 tuning for DDR50 mode [ Upstream commit 4324f6de6d2eb9b232410eb0d67bfafdde8ba711 ] As SD Specifications Part1 Physical Layer Specification Version 3.01 says, CMD19 tuning is available for unlocked cards in transfer state of 1.8V signaling mode. The small difference between v3.00 and 3.01 spec means that CMD19 tuning is also available for DDR50 mode. Signed-off-by: Weijun Yang Signed-off-by: Barry Song Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8a55af069755c320f9f69c29d6bba9856ba8a74a Author: Linus Walleij Date: Mon Jan 4 02:21:55 2016 +0100 mmc: mmci: fix an ages old detection error [ Upstream commit 0bcb7efdff63564e80fe84dd36a9fbdfbf6697a4 ] commit 4956e10903fd ("ARM: 6244/1: mmci: add variant data and default MCICLOCK support") added variant data for ARM, U300 and Ux500 variants. The Nomadik NHK8815/8820 variant was erroneously labeled as a U300 variant, and when the proper Nomadik variant was later introduced in commit 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik MMCI variant") this was not fixes. Let's say this fixes the latter commit as there was no proper Nomadik support until then. Cc: stable@vger.kernel.org Fixes: 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik...") Signed-off-by: Linus Walleij Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 66eba3dabc93f3404e3d011cd19a2eb45b87990f Author: Mans Rullgard Date: Mon Jan 11 13:04:29 2016 +0000 dmaengine: dw: fix cyclic transfer callbacks [ Upstream commit 2895b2cad6e7a95104cf396e5330054453382ae1 ] Cyclic transfer callbacks rely on block completion interrupts which were disabled in commit ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block interrupts"). This re-enables block interrupts so the cyclic callbacks can work. Other transfer types are not affected as they set the INT_EN bit only on the last block. Fixes: ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block interrupts") Signed-off-by: Mans Rullgard Reviewed-by: Viresh Kumar Signed-off-by: Vinod Koul Cc: Signed-off-by: Sasha Levin commit 13aedd784b84cb7d8a3bb835941d80e99f5c796e Author: Mans Rullgard Date: Mon Jan 11 13:04:28 2016 +0000 dmaengine: dw: fix cyclic transfer setup [ Upstream commit df3bb8a0e619d501cd13334c3e0586edcdcbc716 ] Commit 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and chan_cfg register on resume") moved some channel initialisation to a new function which must be called before starting a transfer. This updates dw_dma_cyclic_start() to use dwc_dostart() like the other modes, thus ensuring dwc_initialize() gets called and removing some code duplication. Fixes: 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and chan_cfg register on resume") Signed-off-by: Mans Rullgard Reviewed-by: Viresh Kumar Signed-off-by: Vinod Koul Cc: Signed-off-by: Sasha Levin commit 064ee90886630403af052302f922a07499595515 Author: Greg Kurz Date: Wed Jan 13 18:28:17 2016 +0100 KVM: PPC: Fix ONE_REG AltiVec support [ Upstream commit b4d7f161feb3015d6306e1d35b565c888ff70c9d ] The get and set operations got exchanged by mistake when moving the code from book3s.c to powerpc.c. Fixes: 3840edc8033ad5b86deee309c1c321ca54257452 Cc: stable@vger.kernel.org # 3.18+ Signed-off-by: Greg Kurz Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 12060a1c7cd09460128f8580c1862de807294c3a Author: Chris Wilson Date: Fri Nov 27 13:28:55 2015 +0000 drm/i915: Restore inhibiting the load of the default context [ Upstream commit 06ef83a705a98da63797a5a570220b6ca36febd4 ] Following a GPU reset, we may leave the context in a poorly defined state, and reloading from that context will leave the GPU flummoxed. For secondary contexts, this will lead to that context being banned - but currently it is also causing the default context to become banned, leading to turmoil in the shared state. This is a regression from commit 6702cf16e0ba8b0129f5aa1b6609d4e9c70bc13b [v4.1] Author: Ben Widawsky Date: Mon Mar 16 16:00:58 2015 +0000 drm/i915: Initialize all contexts which quietly introduced the removal of the MI_RESTORE_INHIBIT on the default context. v2: Mark the global default context as uninitialized on GPU reset so that the context-local workarounds are reloaded upon re-enabling. Signed-off-by: Chris Wilson Cc: Michel Thierry Cc: Mika Kuoppala Cc: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1448630935-27377-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala Cc: stable@vger.kernel.org [danvet: This seems to fix a gpu hand on after the first resume, resulting in any future suspend operation failing with -EIO because the gpu seems to be in a funky state. Somehow this patch fixes that.] Signed-off-by: Daniel Vetter (cherry picked from commit 42f1cae8c079bcceb3cff079fddc3ff8852c788f) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 35a317f44dbf18460282a9c4d0d74480f5c3f7b2 Author: Helge Deller Date: Sun Jan 10 09:30:42 2016 +0100 parisc: Fix __ARCH_SI_PREAMBLE_SIZE [ Upstream commit e60fc5aa608eb38b47ba4ee058f306f739eb70a0 ] On a 64bit kernel build the compiler aligns the _sifields union in the struct siginfo_t on a 64bit address. The __ARCH_SI_PREAMBLE_SIZE define compensates for this alignment and thus fixes the wait testcase of the strace package. The symptoms of a wrong __ARCH_SI_PREAMBLE_SIZE value is that _sigchld.si_stime variable is missed to be copied and thus after a copy_siginfo() will have uninitialized values. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c1a7154c7e5d81bba4b027d42ec1f16113992415 Author: Minchan Kim Date: Mon Dec 28 08:35:13 2015 +0900 virtio_balloon: fix race between migration and ballooning [ Upstream commit 21ea9fb69e7c4b1b1559c3e410943d3ff248ffcb ] In balloon_page_dequeue, pages_lock should cover the loop (ie, list_for_each_entry_safe). Otherwise, the cursor page could be isolated by compaction and then list_del by isolation could poison the page->lru.{prev,next} so the loop finally could access wrong address like this. This patch fixes the bug. general protection fault: 0000 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 2 PID: 82 Comm: vballoon Not tainted 4.4.0-rc5-mm1-access_bit+ #1906 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff8800a7ff0000 ti: ffff8800a7fec000 task.ti: ffff8800a7fec000 RIP: 0010:[] [] balloon_page_dequeue+0x54/0x130 RSP: 0018:ffff8800a7fefdc0 EFLAGS: 00010246 RAX: ffff88013fff9a70 RBX: ffffea000056fe00 RCX: 0000000000002b7d RDX: ffff88013fff9a70 RSI: ffffea000056fe00 RDI: ffff88013fff9a68 RBP: ffff8800a7fefde8 R08: ffffea000056fda0 R09: 0000000000000000 R10: ffff8800a7fefd90 R11: 0000000000000001 R12: dead0000000000e0 R13: ffffea000056fe20 R14: ffff880138809070 R15: ffff880138809060 FS: 0000000000000000(0000) GS:ffff88013fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f229c10e000 CR3: 00000000b8b53000 CR4: 00000000000006a0 Stack: 0000000000000100 ffff880138809088 ffff880138809000 ffff880138809060 0000000000000046 ffff8800a7fefe28 ffffffff812c86d3 ffff880138809020 ffff880138809000 fffffffffff91900 0000000000000100 ffff880138809060 Call Trace: [] leak_balloon+0x93/0x1a0 [] balloon+0x217/0x2a0 [] ? __schedule+0x31e/0x8b0 [] ? abort_exclusive_wait+0xb0/0xb0 [] ? update_balloon_stats+0xf0/0xf0 [] kthread+0xc9/0xe0 [] ? kthread_park+0x60/0x60 [] ret_from_fork+0x3f/0x70 [] ? kthread_park+0x60/0x60 Code: 8d 60 e0 0f 84 af 00 00 00 48 8b 43 20 a8 01 75 3b 48 89 d8 f0 0f ba 28 00 72 10 48 8b 03 f6 c4 08 75 2f 48 89 df e8 8c 83 f9 ff <49> 8b 44 24 20 4d 8d 6c 24 20 48 83 e8 20 4d 39 f5 74 7a 4c 89 RIP [] balloon_page_dequeue+0x54/0x130 RSP ---[ end trace 43cf28060d708d5f ]--- Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Cc: Signed-off-by: Minchan Kim Signed-off-by: Michael S. Tsirkin Acked-by: Rafael Aquini Signed-off-by: Sasha Levin commit 3bbe9868ba5654df63f9e10766620f813e92fdf8 Author: Minchan Kim Date: Mon Dec 28 08:35:12 2015 +0900 virtio_balloon: fix race by fill and leak [ Upstream commit f68b992bbb474641881932c61c92dcfa6f5b3689 ] During my compaction-related stuff, I encountered a bug with ballooning. With repeated inflating and deflating cycle, guest memory( ie, cat /proc/meminfo | grep MemTotal) is decreased and couldn't be recovered. The reason is balloon_lock doesn't cover release_pages_balloon so struct virtio_balloon fields could be overwritten by race of fill_balloon(e,g, vb->*pfns could be critical). This patch fixes it in my test. Cc: Signed-off-by: Minchan Kim Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 7daaedba8fa87ade25763e15e5218c66558634c3 Author: Denis V. Lunev Date: Thu Aug 20 00:49:48 2015 +0300 virtio_ballon: change stub of release_pages_by_pfn [ Upstream commit b4d34037329f46ed818d3b0a6e1e23b9c8721f79 ] and rename it to release_pages_balloon. The function originally takes arrays of pfns and now it takes pointer to struct virtio_ballon. This change is necessary to conditionally call adjust_managed_page_count in the next patch. Signed-off-by: Denis V. Lunev CC: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 1fc9a4dd398062e9fa4937f446bedd3305312d1d Author: Benjamin Tissoires Date: Mon Jan 11 17:35:38 2016 -0800 Input: elantech - mark protocols v2 and v3 as semi-mt [ Upstream commit 6544a1df11c48c8413071aac3316792e4678fbfb ] When using a protocol v2 or v3 hardware, elantech uses the function elantech_report_semi_mt_data() to report data. This devices are rather creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid touch is reported. Anyway, userspace (libinput) is now confused by these (0,0) touches, and detect them as palm, and rejects them. Commit 3c0213d17a09 ("Input: elantech - fix semi-mt protocol for v3 HW") was sufficient enough for xf86-input-synaptics and libinput before it has palm rejection. Now we need to actually tell libinput that this device is a semi-mt one and it should not rely on the actual values of the 2 touches. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 27853751e20c1d4c3d060210d38cc0b63ac0c991 Author: Roman Volkov Date: Fri Jan 1 16:24:41 2016 +0300 clocksource/drivers/vt8500: Increase the minimum delta [ Upstream commit f9eccf24615672896dc13251410c3f2f33a14f95 ] The vt8500 clocksource driver declares itself as capable to handle the minimum delay of 4 cycles by passing the value into clockevents_config_and_register(). The vt8500_timer_set_next_event() requires the passed cycles value to be at least 16. The impact is that userspace hangs in nanosleep() calls with small delay intervals. This problem is reproducible in Linux 4.2 starting from: c6eb3f70d448 ('hrtimer: Get rid of hrtimer softirq') From Russell King, more detailed explanation: "It's a speciality of the StrongARM/PXA hardware. It takes a certain number of OSCR cycles for the value written to hit the compare registers. So, if a very small delta is written (eg, the compare register is written with a value of OSCR + 1), the OSCR will have incremented past this value before it hits the underlying hardware. The result is, that you end up waiting a very long time for the OSCR to wrap before the event fires. So, we introduce a check in set_next_event() to detect this and return -ETIME if the calculated delta is too small, which causes the generic clockevents code to retry after adding the min_delta specified in clockevents_config_and_register() to the current time value. min_delta must be sufficient that we don't re-trip the -ETIME check - if we do, we will return -ETIME, forward the next event time, try to set it, return -ETIME again, and basically lock the system up. So, min_delta must be larger than the check inside set_next_event(). A factor of two was chosen to ensure that this situation would never occur. The PXA code worked on PXA systems for years, and I'd suggest no one changes this mechanism without access to a wide range of PXA systems, otherwise they're risking breakage." Cc: stable@vger.kernel.org Cc: Russell King Acked-by: Alexey Charkov Signed-off-by: Roman Volkov Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit e52b0623ee970dfa58d4af089329e193e59be918 Author: Dave Chinner Date: Tue Jan 12 07:04:01 2016 +1100 xfs: handle dquot buffer readahead in log recovery correctly [ Upstream commit 7d6a13f023567d573ac362502bb702eda716e654 ] When we do dquot readahead in log recovery, we do not use a verifier as the underlying buffer may not have dquots in it. e.g. the allocation operation hasn't yet been replayed. Hence we do not want to fail recovery because we detect an operation to be replayed has not been run yet. This problem was addressed for inodes in commit d891400 ("xfs: inode buffers may not be valid during recovery readahead") but the problem was not recognised to exist for dquots and their buffers as the dquot readahead did not have a verifier. The result of not using a verifier is that when the buffer is then next read to replay a dquot modification, the dquot buffer verifier will only be attached to the buffer if *readahead is not complete*. Hence we can read the buffer, replay the dquot changes and then add it to the delwri submission list without it having a verifier attached to it. This then generates warnings in xfs_buf_ioapply(), which catches and warns about this case. Fix this and make it handle the same readahead verifier error cases as for inode buffers by adding a new readahead verifier that has a write operation as well as a read operation that marks the buffer as not done if any corruption is detected. Also make sure we don't run readahead if the dquot buffer has been marked as cancelled by recovery. This will result in readahead either succeeding and the buffer having a valid write verifier, or readahead failing and the buffer state requiring the subsequent read to resubmit the IO with the new verifier. In either case, this will result in the buffer always ending up with a valid write verifier on it. Note: we also need to fix the inode buffer readahead error handling to mark the buffer with EIO. Brian noticed the code I copied from there wrong during review, so fix it at the same time. Add comments linking the two functions that handle readahead verifier errors together so we don't forget this behavioural link in future. cc: # 3.12 - current Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 848235ac48d900d7c5e9c6cfb190d290cdb87a62 Author: Dave Chinner Date: Tue Jan 12 07:03:44 2016 +1100 xfs: inode recovery readahead can race with inode buffer creation [ Upstream commit b79f4a1c68bb99152d0785ee4ea3ab4396cdacc6 ] When we do inode readahead in log recovery, we do can do the readahead before we've replayed the icreate transaction that stamps the buffer with inode cores. The inode readahead verifier catches this and marks the buffer as !done to indicate that it doesn't yet contain valid inodes. In adding buffer error notification (i.e. setting b_error = -EIO at the same time as as we clear the done flag) to such a readahead verifier failure, we can then get subsequent inode recovery failing with this error: XFS (dm-0): metadata I/O error: block 0xa00060 ("xlog_recover_do..(read#2)") error 5 numblks 32 This occurs when readahead completion races with icreate item replay such as: inode readahead find buffer lock buffer submit RA io .... icreate recovery xfs_trans_get_buffer find buffer lock buffer ..... fails verifier clear XBF_DONE set bp->b_error = -EIO release and unlock buffer icreate initialises buffer marks buffer as done adds buffer to delayed write queue releases buffer At this point, we have an initialised inode buffer that is up to date but has an -EIO state registered against it. When we finally get to recovering an inode in that buffer: inode item recovery xfs_trans_read_buffer find buffer lock buffer sees XBF_DONE is set, returns buffer sees bp->b_error is set fail log recovery! Essentially, we need xfs_trans_get_buf_map() to clear the error status of the buffer when doing a lookup. This function returns uninitialised buffers, so the buffer returned can not be in an error state and none of the code that uses this function expects b_error to be set on return. Indeed, there is an ASSERT(!bp->b_error); in the transaction case in xfs_trans_get_buf_map() that would have caught this if log recovery used transactions.... This patch firstly changes the inode readahead failure to set -EIO on the buffer, and secondly changes xfs_buf_get_map() to never return a buffer with an error state set so this first change doesn't cause unexpected log recovery failures. cc: # 3.12 - current Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 2826e0944f3c7a673da95fd226c8a752254c3e6a Author: Ard Biesheuvel Date: Fri Jan 1 13:39:22 2016 +0100 s390: fix normalization bug in exception table sorting [ Upstream commit bcb7825a77f41c7dd91da6f7ac10b928156a322e ] The normalization pass in the sorting routine of the relative exception table serves two purposes: - it ensures that the address fields of the exception table entries are fully ordered, so that no ambiguities arise between entries with identical instruction offsets (i.e., when two instructions that are exactly 8 bytes apart each have an exception table entry associated with them) - it ensures that the offsets of both the instruction and the fixup fields of each entry are relative to their final location after sorting. Commit eb608fb366de ("s390/exceptions: switch to relative exception table entries") ported the relative exception table format from x86, but modified the sorting routine to only normalize the instruction offset field and not the fixup offset field. The result is that the fixup offset of each entry will be relative to the original location of the entry before sorting, likely leading to crashes when those entries are dereferenced. Fixes: eb608fb366de ("s390/exceptions: switch to relative exception table entries") Signed-off-by: Ard Biesheuvel Cc: Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit ccafc9df447a3de7b5b88d246404d97f70f80d6f Author: Ben Skeggs Date: Fri Jan 8 08:56:51 2016 +1000 drm/nouveau/kms: take mode_config mutex in connector hotplug path [ Upstream commit 0a882cadbc63fd2da3994af7115b4ada2fcbd638 ] fdo#93634 Signed-off-by: Ben Skeggs Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 498b346868790663ef443951bb06a30a57b64b32 Author: Vegard Nossum Date: Fri Dec 18 21:28:53 2015 +0100 uml: flush stdout before forking [ Upstream commit 0754fb298f2f2719f0393491d010d46cfb25d043 ] I was seeing some really weird behaviour where piping UML's output somewhere would cause output to get duplicated: $ ./vmlinux | head -n 40 Checking that ptrace can change system call numbers...Core dump limits : soft - 0 hard - NONE OK Checking syscall emulation patch for ptrace...Core dump limits : soft - 0 hard - NONE OK Checking advanced syscall emulation patch for ptrace...Core dump limits : soft - 0 hard - NONE OK Core dump limits : soft - 0 hard - NONE This is because these tests do a fork() which duplicates the non-empty stdout buffer, then glibc flushes the duplicated buffer as each child exits. A simple workaround is to flush before forking. Cc: stable@vger.kernel.org Signed-off-by: Vegard Nossum Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 4e623240d3054ca29fbb294d15a24b2ed971a413 Author: Vegard Nossum Date: Wed Dec 16 21:59:56 2015 +0100 uml: fix hostfs mknod() [ Upstream commit 9f2dfda2f2f1c6181c3732c16b85c59ab2d195e0 ] An inverted return value check in hostfs_mknod() caused the function to return success after handling it as an error (and cleaning up). It resulted in the following segfault when trying to bind() a named unix socket: Pid: 198, comm: a.out Not tainted 4.4.0-rc4 RIP: 0033:[<0000000061077df6>] RSP: 00000000daae5d60 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 000000006092a460 RCX: 00000000dfc54208 RDX: 0000000061073ef1 RSI: 0000000000000070 RDI: 00000000e027d600 RBP: 00000000daae5de0 R08: 00000000da980ac0 R09: 0000000000000000 R10: 0000000000000003 R11: 00007fb1ae08f72a R12: 0000000000000000 R13: 000000006092a460 R14: 00000000daaa97c0 R15: 00000000daaa9a88 Kernel panic - not syncing: Kernel mode fault at addr 0x40, ip 0x61077df6 CPU: 0 PID: 198 Comm: a.out Not tainted 4.4.0-rc4 #1 Stack: e027d620 dfc54208 0000006f da981398 61bee000 0000c1ed daae5de0 0000006e e027d620 dfcd4208 00000005 6092a460 Call Trace: [<60dedc67>] SyS_bind+0xf7/0x110 [<600587be>] handle_syscall+0x7e/0x80 [<60066ad7>] userspace+0x3e7/0x4e0 [<6006321f>] ? save_registers+0x1f/0x40 [<6006c88e>] ? arch_prctl+0x1be/0x1f0 [<60054985>] fork_handler+0x85/0x90 Let's also get rid of the "cosmic ray protection" while we're at it. Fixes: e9193059b1b3 "hostfs: fix races in dentry_name() and inode_name()" Signed-off-by: Vegard Nossum Cc: Jeff Dike Cc: Al Viro Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 27f8627c3a656409f8594e3d976d03ab445d7fcc Author: Mikulas Patocka Date: Fri Jan 8 19:07:55 2016 -0500 dm snapshot: fix hung bios when copy error occurs [ Upstream commit 385277bfb57faac44e92497104ba542cdd82d5fe ] When there is an error copying a chunk dm-snapshot can incorrectly hold associated bios indefinitely, resulting in hung IO. The function copy_callback sets pe->error if there was error copying the chunk, and then calls complete_exception. complete_exception calls pending_complete on error, otherwise it calls commit_exception with commit_callback (and commit_callback calls complete_exception). The persistent exception store (dm-snap-persistent.c) assumes that calls to prepare_exception and commit_exception are paired. persistent_prepare_exception increases ps->pending_count and persistent_commit_exception decreases it. If there is a copy error, persistent_prepare_exception is called but persistent_commit_exception is not. This results in the variable ps->pending_count never returning to zero and that causes some pending exceptions (and their associated bios) to be held forever. Fix this by unconditionally calling commit_exception regardless of whether the copy was successful. A new "valid" parameter is added to commit_exception -- when the copy fails this parameter is set to zero so that the chunk that failed to copy (and all following chunks) is not recorded in the snapshot store. Also, remove commit_callback now that it is merely a wrapper around pending_complete. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9d8246cd71ec50f8aa57c1ea74d8aff314908043 Author: Mike Christie Date: Thu Jan 7 16:34:05 2016 -0600 scsi: add Synology to 1024 sector blacklist [ Upstream commit 9055082fb100cc66e20c048251d05159f5f2cfba ] Another iscsi target that cannot handle large IOs, but does not tell us a limit. The Synology iSCSI targets report: Block limits VPD page (SBC): Write same no zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 0 blocks Maximum transfer length: 0 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 0 Maximum unmap block descriptor count: 0 Optimal unmap granularity: 0 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x0 blocks and the size of the command it can handle seems to depend on how much memory it can allocate at the time. This results in IO errors when handling large IOs. This patch just has us use the old 1024 default sectors for this target by adding it to the scsi blacklist. We do not have good contacs with this vendors, so I have not been able to try and fix on their side. I have posted this a long while back, but it was not merged. This version just fixes it up for merge/patch failures in the original version. Reported-by: Ancoron Luciferis Reported-by: Michael Meyers Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Cc: # 4.1+ Signed-off-by: Sasha Levin commit 2e21928b854d0201e5af8413daaa8dfe1b32690d Author: Jeff Layton Date: Thu Jan 7 16:38:10 2016 -0500 locks: fix unlock when fcntl_setlk races with a close [ Upstream commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 ] Dmitry reported that he was able to reproduce the WARN_ON_ONCE that fires in locks_free_lock_context when the flc_posix list isn't empty. The problem turns out to be that we're basically rebuilding the file_lock from scratch in fcntl_setlk when we discover that the setlk has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END, then we may end up with fl_start and fl_end values that differ from when the lock was initially set, if the file position or length of the file has changed in the interim. Fix this by just reusing the same lock request structure, and simply override fl_type value with F_UNLCK as appropriate. That ensures that we really are unlocking the lock that was initially set. While we're there, make sure that we do pop a WARN_ON_ONCE if the removal ever fails. Also return -EBADF in this event, since that's what we would have returned if the close had happened earlier. Cc: Alexander Viro Cc: Fixes: c293621bbf67 (stale POSIX lock handling) Reported-by: Dmitry Vyukov Signed-off-by: Jeff Layton Acked-by: "J. Bruce Fields" Signed-off-by: Sasha Levin commit d9d42b679e3653759b107ff99daf8da9c21aaec7 Author: Emmanuel Grumbach Date: Tue Jan 5 15:25:43 2016 +0200 iwlwifi: pcie: properly configure the debug buffer size for 8000 [ Upstream commit 62d7476d958ce06d7a10b02bdb30006870286fe2 ] 8000 device family has a new debug engine that needs to be configured differently than 7000's. The debug engine's DMA works in chunks of memory and the size of the buffer really means the start of the last chunk. Since one chunk is 256-byte long, we should configure the device to write to buffer_size - 256. This fixes a situation were the device would write to memory it is not allowed to access. CC: [4.1+] Signed-off-by: Emmanuel Grumbach Signed-off-by: Sasha Levin commit 01999150f50e945ee85914c37a1337784c1993c8 Author: Sasha Levin Date: Mon Feb 1 15:02:44 2016 -0500 iwlwifi: update and fix 7265 series PCI IDs [ Upstream commit 006bda75d81fd27a583a3b310e9444fea2aa6ef2 ] Update and fix some 7265 PCI IDs entries. CC: [3.13+] Signed-off-by: Oren Givon Signed-off-by: Emmanuel Grumbach Signed-off-by: Sasha Levin commit 1ecdadef5db6404bb57c9f369c0f026e1e9ac638 Author: David Sterba Date: Mon Nov 30 17:27:06 2015 +0100 btrfs: handle invalid num_stripes in sys_array [ Upstream commit f5cdedd73fa71b74dcc42f2a11a5735d89ce7c4f ] We can handle the special case of num_stripes == 0 directly inside btrfs_read_sys_array. The BUG_ON in btrfs_chunk_item_size is there to catch other unhandled cases where we fail to validate external data. A crafted or corrupted image crashes at mount time: BTRFS: device fsid 9006933e-2a9a-44f0-917f-514252aeec2c devid 1 transid 7 /dev/loop0 BTRFS info (device loop0): disk space caching is enabled BUG: failure at fs/btrfs/ctree.h:337/btrfs_chunk_item_size()! Kernel panic - not syncing: BUG! CPU: 0 PID: 313 Comm: mount Not tainted 4.2.5-00657-ge047887-dirty #25 Stack: 637af890 60062489 602aeb2e 604192ba 60387961 00000011 637af8a0 6038a835 637af9c0 6038776b 634ef32b 00000000 Call Trace: [<6001c86d>] show_stack+0xfe/0x15b [<6038a835>] dump_stack+0x2a/0x2c [<6038776b>] panic+0x13e/0x2b3 [<6020f099>] btrfs_read_sys_array+0x25d/0x2ff [<601cfbbe>] open_ctree+0x192d/0x27af [<6019c2c1>] btrfs_mount+0x8f5/0xb9a [<600bc9a7>] mount_fs+0x11/0xf3 [<600d5167>] vfs_kern_mount+0x75/0x11a [<6019bcb0>] btrfs_mount+0x2e4/0xb9a [<600bc9a7>] mount_fs+0x11/0xf3 [<600d5167>] vfs_kern_mount+0x75/0x11a [<600d710b>] do_mount+0xa35/0xbc9 [<600d7557>] SyS_mount+0x95/0xc8 [<6001e884>] handle_syscall+0x6b/0x8e Reported-by: Jiri Slaby Reported-by: Vegard Nossum CC: stable@vger.kernel.org # 3.19+ Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 16870da043de536d1e4b866b594c60f0475f6739 Author: Grygorii Strashko Date: Thu Dec 10 21:18:20 2015 +0200 PCI: host: Mark PCIe/PCI (MSI) IRQ cascade handlers as IRQF_NO_THREAD [ Upstream commit 8ff0ef996ca00028519c70e8d51d32bd37eb51dc ] On -RT and if kernel is booting with "threadirqs" cmd line parameter, PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler()) will be forced threaded and, as result, will generate warnings like this: WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174() irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts Backtrace: (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40) (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174) (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8) (handle_irq_event) from (handle_simple_irq+0x90/0x118) (handle_simple_irq) from (generic_handle_irq+0x30/0x44) (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c) (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c) (irq_forced_thread_fn) from (irq_thread+0x128/0x204) This happens because all of them invoke generic_handle_irq() from the requested handler. generic_handle_irq() grabs raw_locks and thus needs to run in raw-IRQ context. This issue was originally reproduced on TI dra7-evem, but, as was identified during discussion [1], other hosts can also suffer from this issue. Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers IRQF_NO_THREAD explicitly. [1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com [bhelgaas: add stable tag, fix typos] Signed-off-by: Grygorii Strashko Signed-off-by: Bjorn Helgaas Acked-by: Lucas Stach (for imx6) CC: stable@vger.kernel.org CC: Kishon Vijay Abraham I CC: Jingoo Han CC: Kukjin Kim CC: Krzysztof Kozlowski CC: Richard Zhu CC: Thierry Reding CC: Stephen Warren CC: Alexandre Courbot CC: Simon Horman CC: Pratyush Anand CC: Michal Simek CC: "Sören Brinkmann" CC: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 24ab3b8e796248bfbdb8a80469b9811b5df39caa Author: Christoph Biedl Date: Wed Dec 23 16:51:57 2015 +0100 PCI: Fix minimum allocation address overwrite [ Upstream commit 3460baa620685c20f5ee19afb6d99d26150c382c ] Commit 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address") claimed to do no functional changes but unfortunately did: The "min" variable is altered. At least the AVM A1 PCMCIA adapter was no longer detected, breaking ISDN operation. Use a local copy of "min" to restore the previous behaviour. [bhelgaas: avoid gcc "?:" extension for portability and readability] Fixes: 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address") Signed-off-by: Christoph Biedl Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.14+ Signed-off-by: Sasha Levin commit 67d0df37bf4235bc3aa1866571e74437cba33199 Author: Mykola Lysenko Date: Fri Dec 25 16:14:48 2015 +0800 drm/dp/mst: fix in RAD element access [ Upstream commit 7a11a334aa6af4c65c6a0d81b60c97fc18673532 ] This is needed to receive correct port number from RAD, so MSTB could be found Acked-by: Dave Airlie Signed-off-by: Mykola Lysenko Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8605e8573eae0457d6d3a1826ba3253e56c3d644 Author: Mykola Lysenko Date: Fri Dec 25 16:14:47 2015 +0800 drm/dp/mst: fix in MSTB RAD initialization [ Upstream commit 75af4c8c4c0f60d7ad135419805798f144e9baf9 ] This fix is needed to support more then two branch displays, so RAD address consist at least of 2 elements Acked-by: Dave Airlie Signed-off-by: Mykola Lysenko Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1d1e2c4f98c1673ae2c99ab6f133d2a1d3fa0b9e Author: Mykola Lysenko Date: Fri Dec 18 17:14:43 2015 -0500 drm/dp/mst: always send reply for UP request [ Upstream commit 1f16ee7fa13649f4e55aa48ad31c3eb0722a62d3 ] We should always send reply for UP request in order to make downstream device clean-up resources appropriately. Issue was that reply for UP request was sent only once. Acked-by: Dave Airlie Signed-off-by: Mykola Lysenko Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e76bda944f6f601dd7bf2a26b34803a30d4503e3 Author: Mykola Lysenko Date: Fri Dec 18 17:14:42 2015 -0500 drm/dp/mst: process broadcast messages correctly [ Upstream commit bd9343208704fcc70a5b919f228a7d26ae472727 ] In case broadcast message received in UP request, RAD cannot be used to identify message originator. Message should be parsed, originator should be found by GUID from parsed message. Also reply with broadcast in case broadcast message received (for now it is always broadcast) Acked-by: Dave Airlie Signed-off-by: Mykola Lysenko Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 516a102b0add0610805d0062670b18b1b44ccdda Author: Andrew Gabbasov Date: Thu Dec 24 10:25:33 2015 -0600 udf: Check output buffer length when converting name to CS0 [ Upstream commit bb00c898ad1ce40c4bb422a8207ae562e9aea7ae ] If a name contains at least some characters with Unicode values exceeding single byte, the CS0 output should have 2 bytes per character. And if other input characters have single byte Unicode values, then the single input byte is converted to 2 output bytes, and the length of output becomes larger than the length of input. And if the input name is long enough, the output length may exceed the allocated buffer length. All this means that conversion from UTF8 or NLS to CS0 requires checking of output length in order to stop when it exceeds the given output buffer size. [JK: Make code return -ENAMETOOLONG instead of silently truncating the name] CC: stable@vger.kernel.org Signed-off-by: Andrew Gabbasov Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit d6341753c418d3699948290d8c0b9d9dc78bd209 Author: Andrew Gabbasov Date: Thu Dec 24 10:25:32 2015 -0600 udf: Prevent buffer overrun with multi-byte characters [ Upstream commit ad402b265ecf6fa22d04043b41444cdfcdf4f52d ] udf_CS0toUTF8 function stops the conversion when the output buffer length reaches UDF_NAME_LEN-2, which is correct maximum name length, but, when checking, it leaves the space for a single byte only, while multi-bytes output characters can take more space, causing buffer overflow. Similar error exists in udf_CS0toNLS function, that restricts the output length to UDF_NAME_LEN, while actual maximum allowed length is UDF_NAME_LEN-2. In these cases the output can override not only the current buffer length field, causing corruption of the name buffer itself, but also following allocation structures, causing kernel crash. Adjust the output length checks in both functions to prevent buffer overruns in case of multi-bytes UTF8 or NLS characters. CC: stable@vger.kernel.org Signed-off-by: Andrew Gabbasov Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit eaf7c91b334172cc4ec2871940baee3cc0ebeede Author: Aurélien Francillon Date: Sat Jan 2 20:39:54 2016 -0800 Input: i8042 - add Fujitsu Lifebook U745 to the nomux list [ Upstream commit dd0d0d4de582a6a61c032332c91f4f4cb2bab569 ] Without i8042.nomux=1 the Elantech touch pad is not working at all on a Fujitsu Lifebook U745. This patch does not seem necessary for all U745 (maybe because of different BIOS versions?). However, it was verified that the patch does not break those (see opensuse bug 883192: https://bugzilla.opensuse.org/show_bug.cgi?id=883192). Signed-off-by: Aurélien Francillon Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 34ed7459a09569f4b2dd8a549f420fac8c3619e0 Author: Uri Mashiach Date: Thu Dec 24 16:05:00 2015 +0200 wlcore/wl12xx: spi: fix NULL pointer dereference (Oops) [ Upstream commit e47301b06d5a65678690f04c2248fd181db1e59a ] Fix the below Oops when trying to modprobe wlcore_spi. The oops occurs because the wl1271_power_{off,on}() function doesn't check the power() function pointer. [ 23.401447] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 23.409954] pgd = c0004000 [ 23.412922] [00000000] *pgd=00000000 [ 23.416693] Internal error: Oops: 80000007 [#1] SMP ARM [ 23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211 musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23 c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon [ 23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted 4.2.0-00002-g951efee-dirty #233 [ 23.461720] Hardware name: Generic AM33XX (Flattened Device Tree) [ 23.468123] Workqueue: events request_firmware_work_func [ 23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000 [ 23.479341] PC is at 0x0 [ 23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore] [ 23.488074] pc : [<00000000>] lr : [] psr: 60000013 [ 23.488074] sp : de4efe50 ip : 00000002 fp : 00000000 [ 23.500162] r10: de7cdd00 r9 : dc848800 r8 : bf27af00 [ 23.505663] r7 : bf27a1a8 r6 : dcbd8a80 r5 : dce0e2e0 r4 : dce0d2e0 [ 23.512536] r3 : 00000000 r2 : 00000000 r1 : 00000001 r0 : dc848810 [ 23.519412] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 23.527109] Control: 10c5387d Table: 9cb78019 DAC: 00000015 [ 23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218) [ 23.539760] Stack: (0xde4efe50 to 0xde4f0000) [...] [ 23.665030] [] (wl12xx_set_power_on [wlcore]) from [] (wlcore_nvs_cb+0x118/0xa4c [wlcore]) [ 23.675604] [] (wlcore_nvs_cb [wlcore]) from [] (request_firmware_work_func+0x30/0x58) [ 23.685784] [] (request_firmware_work_func) from [] (process_one_work+0x1b4/0x4b4) [ 23.695591] [] (process_one_work) from [] (worker_thread+0x3c/0x4a4) [ 23.704124] [] (worker_thread) from [] (kthread+0xd4/0xf0) [ 23.711747] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 23.719357] Code: bad PC value [ 23.722760] ---[ end trace 981be8510db9b3a9 ]--- Prevent oops by validationg power() pointer value before calling the function. Signed-off-by: Uri Mashiach Cc: stable@vger.kernel.org Acked-by: Igor Grinberg Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ebd138117e5be089d0e10fea7cb308e8345ed643 Author: Kent Overstreet Date: Sun Nov 29 18:47:01 2015 -0800 bcache: Change refill_dirty() to always scan entire disk if necessary [ Upstream commit 627ccd20b4ad3ba836472468208e2ac4dfadbf03 ] Previously, it would only scan the entire disk if it was starting from the very start of the disk - i.e. if the previous scan got to the end. This was broken by refill_full_stripes(), which updates last_scanned so that refill_dirty was never triggering the searched_from_start path. But if we change refill_dirty() to always scan the entire disk if necessary, regardless of what last_scanned was, the code gets cleaner and we fix that bug too. Signed-off-by: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ad148665b58dcd0a4336188ce4a2194d7f353c5f Author: Stefan Bader Date: Sun Nov 29 18:44:49 2015 -0800 bcache: prevent crash on changing writeback_running [ Upstream commit 8d16ce540c94c9d366eb36fc91b7154d92d6397b ] Added a safeguard in the shutdown case. At least while not being attached it is also possible to trigger a kernel bug by writing into writeback_running. This change adds the same check before trying to wake up the thread for that case. Signed-off-by: Stefan Bader Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d5402134c27d66e83295ae2961772b89bc6a50bc Author: Gabriel de Perthuis Date: Sun Nov 29 18:40:23 2015 -0800 bcache: allows use of register in udev to avoid "device_busy" error. [ Upstream commit d7076f21629f8f329bca4a44dc408d94670f49e2 ] Allows to use register, not register_quiet in udev to avoid "device_busy" error. The initial patch proposed at https://lkml.org/lkml/2013/8/26/549 by Gabriel de Perthuis does not unlock the mutex and hangs the kernel. See http://thread.gmane.org/gmane.linux.kernel.bcache.devel/2594 for the discussion. Cc: Denis Bychkov Cc: Kent Overstreet Cc: Eric Wheeler Cc: Gabriel de Perthuis Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 322d0128f1e4af6b5b3532e0848fae633fd5a992 Author: Zheng Liu Date: Sun Nov 29 17:21:57 2015 -0800 bcache: unregister reboot notifier if bcache fails to unregister device [ Upstream commit 2ecf0cdb2b437402110ab57546e02abfa68a716b ] In bcache_init() function it forgot to unregister reboot notifier if bcache fails to unregister a block device. This commit fixes this. Signed-off-by: Zheng Liu Tested-by: Joshua Schmid Tested-by: Eric Wheeler Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 888841b4a1fc60d064919dde3da80102f8dbe53c Author: Al Viro Date: Sun Nov 29 17:20:59 2015 -0800 bcache: fix a leak in bch_cached_dev_run() [ Upstream commit 4d4d8573a8451acc9f01cbea24b7e55f04a252fe ] Signed-off-by: Al Viro Tested-by: Joshua Schmid Tested-by: Eric Wheeler Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 14dca8988999b6ccf4126cf6a3455e5822777a8f Author: Zheng Liu Date: Sun Nov 29 17:19:32 2015 -0800 bcache: clear BCACHE_DEV_UNLINK_DONE flag when attaching a backing device [ Upstream commit fecaee6f20ee122ad75402c53d8278f9bb142ddc ] This bug can be reproduced by the following script: #!/bin/bash bcache_sysfs="/sys/fs/bcache" function clear_cache() { if [ ! -e $bcache_sysfs ]; then echo "no bcache sysfs" exit fi cset_uuid=$(ls -l $bcache_sysfs|head -n 2|tail -n 1|awk '{print $9}') sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/detach" sleep 5 sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/attach" } for ((i=0;i<10;i++)); do clear_cache done The warning messages look like below: [ 275.948611] ------------[ cut here ]------------ [ 275.963840] WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xb8/0xd0() (Tainted: P W --------------- ) [ 275.979253] Hardware name: Tecal RH2285 [ 275.994106] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:09.0/0000:08:00.0/host4/target4:2:1/4:2:1:0/block/sdb/sdb1/bcache/cache' [ 276.024105] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan] [ 276.072643] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1 [ 276.089315] Call Trace: [ 276.105801] [] ? warn_slowpath_common+0x87/0xc0 [ 276.122650] [] ? warn_slowpath_fmt+0x46/0x50 [ 276.139361] [] ? sysfs_add_one+0xb8/0xd0 [ 276.156012] [] ? sysfs_do_create_link+0x12b/0x170 [ 276.172682] [] ? sysfs_create_link+0x13/0x20 [ 276.189282] [] ? bcache_device_link+0xc1/0x110 [bcache] [ 276.205993] [] ? bch_cached_dev_attach+0x478/0x4f0 [bcache] [ 276.222794] [] ? bch_cached_dev_store+0x627/0x780 [bcache] [ 276.239680] [] ? alloc_pages_current+0xaa/0x110 [ 276.256594] [] ? sysfs_write_file+0xe5/0x170 [ 276.273364] [] ? vfs_write+0xb8/0x1a0 [ 276.290133] [] ? sys_write+0x51/0x90 [ 276.306368] [] ? system_call_fastpath+0x16/0x1b [ 276.322301] ---[ end trace 9f5d4fcdd0c3edfb ]--- [ 276.338241] ------------[ cut here ]------------ [ 276.354109] WARNING: at /home/wenqing.lz/bcache/bcache/super.c:720 bcache_device_link+0xdf/0x110 [bcache]() (Tainted: P W --------------- ) [ 276.386017] Hardware name: Tecal RH2285 [ 276.401430] Couldn't create device <-> cache set symlinks [ 276.401759] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan] [ 276.465477] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1 [ 276.482169] Call Trace: [ 276.498610] [] ? warn_slowpath_common+0x87/0xc0 [ 276.515405] [] ? warn_slowpath_fmt+0x46/0x50 [ 276.532059] [] ? bcache_device_link+0xdf/0x110 [bcache] [ 276.548808] [] ? bch_cached_dev_attach+0x478/0x4f0 [bcache] [ 276.565569] [] ? bch_cached_dev_store+0x627/0x780 [bcache] [ 276.582418] [] ? alloc_pages_current+0xaa/0x110 [ 276.599341] [] ? sysfs_write_file+0xe5/0x170 [ 276.616142] [] ? vfs_write+0xb8/0x1a0 [ 276.632607] [] ? sys_write+0x51/0x90 [ 276.648671] [] ? system_call_fastpath+0x16/0x1b [ 276.664756] ---[ end trace 9f5d4fcdd0c3edfc ]--- We forget to clear BCACHE_DEV_UNLINK_DONE flag in bcache_device_attach() function when we attach a backing device first time. After detaching this backing device, this flag will be true and sysfs_remove_link() isn't called in bcache_device_unlink(). Then when we attach this backing device again, sysfs_create_link() will return EEXIST error in bcache_device_link(). So the fix is trival and we clear this flag in bcache_device_link(). Signed-off-by: Zheng Liu Tested-by: Joshua Schmid Tested-by: Eric Wheeler Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 08656518aa2812e8650b8036201bd9e5463f22a8 Author: Kent Overstreet Date: Sun Nov 29 17:18:33 2015 -0800 bcache: Add a cond_resched() call to gc [ Upstream commit c5f1e5adf956e3ba82d204c7c141a75da9fa449a ] Signed-off-by: Takashi Iwai Tested-by: Eric Wheeler Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c505638900d191ae10d1f8afdc8d09ca8c2de0d4 Author: Zheng Liu Date: Sun Nov 29 17:17:05 2015 -0800 bcache: fix a livelock when we cause a huge number of cache misses [ Upstream commit 2ef9ccbfcb90cf84bdba320a571b18b05c41101b ] Subject : [PATCH v2] bcache: fix a livelock in btree lock Date : Wed, 25 Feb 2015 20:32:09 +0800 (02/25/2015 04:32:09 AM) This commit tries to fix a livelock in bcache. This livelock might happen when we causes a huge number of cache misses simultaneously. When we get a cache miss, bcache will execute the following path. ->cached_dev_make_request() ->cached_dev_read() ->cached_lookup() ->bch->btree_map_keys() ->btree_root() <------------------------ ->bch_btree_map_keys_recurse() | ->cache_lookup_fn() | ->cached_dev_cache_miss() | ->bch_btree_insert_check_key() -| [If btree->seq is not equal to seq + 1, we should return EINTR and traverse btree again.] In bch_btree_insert_check_key() function we first need to check upgrade flag (op->lock == -1), and when this flag is true we need to release read btree->lock and try to take write btree->lock. During taking and releasing this write lock, btree->seq will be monotone increased in order to prevent other threads modify this in cache miss (see btree.h:74). But if there are some cache misses caused by some requested, we could meet a livelock because btree->seq is always changed by others. Thus no one can make progress. This commit will try to take write btree->lock if it encounters a race when we traverse btree. Although it sacrifice the scalability but we can ensure that only one can modify the btree. Signed-off-by: Zheng Liu Tested-by: Joshua Schmid Tested-by: Eric Wheeler Cc: Joshua Schmid Cc: Zhu Yanhai Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e96bbdf82d1943c73af99d1a4e2ea9d140144983 Author: Larry Finger Date: Mon Dec 21 17:05:08 2015 -0600 rtlwifi: rtl_pci: Fix kernel panic [ Upstream commit f99551a2d39dc26ea03dc6761be11ac913eb2d57 ] In commit 38506ecefab9 (rtlwifi: rtl_pci: Start modification for new drivers), a bug was introduced that causes a NULL pointer dereference. As this bug only affects the infrequently used RTL8192EE and only under low-memory conditions, it has taken a long time for the bug to show up. The bug was reported on the linux-wireless mailing list and also at https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/ as bug #1527603 (kernel crashes due to rtl8192ee driver on ubuntu 15.10). Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 8572f2fa313c47750609178b20caf0598fd1042a Author: Trond Myklebust Date: Tue Dec 29 18:55:19 2015 -0500 NFS: Fix attribute cache revalidation [ Upstream commit ade14a7df796d4e86bd9d181193c883a57b13db0 ] If a NFSv4 client uses the cache_consistency_bitmask in order to request only information about the change attribute, timestamps and size, then it has not revalidated all attributes, and hence the attribute timeout timestamp should not be updated. Reported-by: Donald Buczek Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 226864aff728a7253570e8dd3073ee6dc588d1de Author: Trond Myklebust Date: Sun Jul 5 11:12:07 2015 -0400 NFS: Remove the "NFS_CAP_CHANGE_ATTR" capability [ Upstream commit cd812599796f500b042f5464b6665755eca21137 ] Setting the change attribute has been mandatory for all NFS versions, since commit 3a1556e8662c ("NFSv2/v3: Simulate the change attribute"). We should therefore not have anything be conditional on it being set/unset. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit de944618d562173faaf27a853acb37ee85825682 Author: Larry Finger Date: Mon Dec 14 16:34:38 2015 -0600 rtlwifi: rtl8192cu: Add missing parameter setup [ Upstream commit b68d0ae7e58624c33f2eddab471fee55db27dbf9 ] This driver fails to copy the module parameter for software encryption to the locations used by the main code. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 0375ae541a81271fba5adf2b05adff1945cf3251 Author: Larry Finger Date: Mon Dec 14 16:34:37 2015 -0600 rtlwifi: rtl8192ce: Fix handling of module parameters [ Upstream commit b24f19f16b9e43f54218c07609b783ea8625406a ] The module parameter for software encryption was never transferred to the location used by the driver. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 214e5cc67f9f5636b3272410f9ad0c151dafa0ac Author: Larry Finger Date: Mon Dec 14 16:34:36 2015 -0600 rtlwifi: rtl8192se: Fix module parameter initialization [ Upstream commit 7503efbd82c15c4070adffff1344e5169d3634b4 ] Two of the module parameter descriptions show incorrect default values. In addition the value for software encryption is not transferred to the locations used by the driver. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 1a37aece44090c945a9b764e413b901863d32e86 Author: Larry Finger Date: Mon Dec 14 16:34:35 2015 -0600 rtlwifi: rtl8192de: Fix incorrect module parameter descriptions [ Upstream commit d4d60b4caaa5926e1b243070770968f05656107a ] Two of the module parameters are listed with incorrect default values. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 07493d2c6685b2e0a243f5dfda8cabbf581994d8 Author: Larry Finger Date: Mon Dec 14 16:34:34 2015 -0600 rtlwifi: rtl8188ee: Fix module parameter initialization [ Upstream commit 06f34572c6110e2e2d5e653a957f1d74db9e3f2b ] In this driver, parameters disable_watchdog and sw_crypto are never copied into the locations used in the main code. While modifying the parameter handling, the copying of parameter msi_support is moved to be with the rest. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 35de29368026457b742115a340cead9bfea9b0bd Author: Richard Cochran Date: Tue Dec 22 22:19:58 2015 +0100 posix-clock: Fix return code on the poll method's error path [ Upstream commit 1b9f23727abb92c5e58f139e7d180befcaa06fe0 ] The posix_clock_poll function is supposed to return a bit mask of POLLxxx values. However, in case the hardware has disappeared (due to hot plugging for example) this code returns -ENODEV in a futile attempt to throw an error at the file descriptor level. The kernel's file_operations interface does not accept such error codes from the poll method. Instead, this function aught to return POLLERR. The value -ENODEV does, in fact, contain the POLLERR bit (and almost all the other POLLxxx bits as well), but only by chance. This patch fixes code to return a proper bit mask. Credit goes to Markus Elfring for pointing out the suspicious signed/unsigned mismatch. Reported-by: Markus Elfring igned-off-by: Richard Cochran Cc: John Stultz Cc: Julia Lawall Link: http://lkml.kernel.org/r/1450819198-17420-1-git-send-email-richardcochran@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit bdfc34b6cffea584f49ed9356924674e3e40b7e6 Author: Chen Yu Date: Fri Oct 30 16:32:10 2015 +0800 Thermal: do thermal zone update after a cooling device registered [ Upstream commit 4511f7166a2deb5f7a578cf87fd2fe1ae83527e3 ] When a new cooling device is registered, we need to update the thermal zone to set the new registered cooling device to a proper state. This fixes a problem that the system is cool, while the fan devices are left running on full speed after boot, if fan device is registered after thermal zone device. Here is the history of why current patch looks like this: https://patchwork.kernel.org/patch/7273041/ CC: #3.18+ Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431 Tested-by: Manuel Krause Tested-by: szegad Tested-by: prash Tested-by: amish Reviewed-by: Javi Merino Signed-off-by: Zhang Rui Signed-off-by: Chen Yu Signed-off-by: Sasha Levin commit ab4827691501adf64fc580f7a8cadca0332b84b7 Author: Zhang Rui Date: Fri Oct 30 16:31:58 2015 +0800 Thermal: handle thermal zone device properly during system sleep [ Upstream commit ff140fea847e1c2002a220571ab106c2456ed252 ] Current thermal code does not handle system sleep well because 1. the cooling device cooling state may be changed during suspend 2. the previous temperature reading becomes invalid after resumed because it is got before system sleep 3. updating thermal zone device during suspending/resuming is wrong because some devices may have already been suspended or may have not been resumed. Thus, the proper way to do this is to cancel all thermal zone device update requirements during suspend/resume, and after all the devices have been resumed, reset and update every registered thermal zone devices. This also fixes a regression introduced by: Commit 19593a1fb1f6 ("ACPI / fan: convert to platform driver") Because, with above commit applied, all the fan devices are attached to the acpi_general_pm_domain, and they are turned on by the pm_domain automatically after resume, without the awareness of thermal core. CC: #3.18+ Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78201 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=91411 Tested-by: Manuel Krause Tested-by: szegad Tested-by: prash Tested-by: amish Tested-by: Matthias Reviewed-by: Javi Merino Signed-off-by: Zhang Rui Signed-off-by: Chen Yu Signed-off-by: Sasha Levin commit 247d403072cc86564439a919a4f9c48f46d138cd Author: Zhang Rui Date: Fri Oct 30 16:31:47 2015 +0800 Thermal: initialize thermal zone device correctly [ Upstream commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461 ] After thermal zone device registered, as we have not read any temperature before, thus tz->temperature should not be 0, which actually means 0C, and thermal trend is not available. In this case, we need specially handling for the first thermal_zone_device_update(). Both thermal core framework and step_wise governor is enhanced to handle this. And since the step_wise governor is the only one that uses trends, so it's the only thermal governor that needs to be updated. CC: #3.18+ Tested-by: Manuel Krause Tested-by: szegad Tested-by: prash Tested-by: amish Tested-by: Matthias Reviewed-by: Javi Merino Signed-off-by: Zhang Rui Signed-off-by: Chen Yu Signed-off-by: Sasha Levin commit 40b7566cb9872529f0b95bd913e16022e1107731 Author: Andrew Elble Date: Wed Dec 2 09:20:57 2015 -0500 nfs: Fix race in __update_open_stateid() [ Upstream commit 361cad3c89070aeb37560860ea8bfc092d545adc ] We've seen this in a packet capture - I've intermixed what I think was going on. The fix here is to grab the so_lock sooner. 1964379 -> #1 open (for write) reply seqid=1 1964393 -> #2 open (for read) reply seqid=2 __nfs4_close(), state->n_wronly-- nfs4_state_set_mode_locked(), changes state->state = [R] state->flags is [RW] state->state is [R], state->n_wronly == 0, state->n_rdonly == 1 1964398 -> #3 open (for write) call -> because close is already running 1964399 -> downgrade (to read) call seqid=2 (close of #1) 1964402 -> #3 open (for write) reply seqid=3 __update_open_stateid() nfs_set_open_stateid_locked(), changes state->flags state->flags is [RW] state->state is [R], state->n_wronly == 0, state->n_rdonly == 1 new sequence number is exposed now via nfs4_stateid_copy() next step would be update_open_stateflags(), pending so_lock 1964403 -> downgrade reply seqid=2, fails with OLD_STATEID (close of #1) nfs4_close_prepare() gets so_lock and recalcs flags -> send close 1964405 -> downgrade (to read) call seqid=3 (close of #1 retry) __update_open_stateid() gets so_lock * update_open_stateflags() updates state->n_wronly. nfs4_state_set_mode_locked() updates state->state state->flags is [RW] state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1 * should have suppressed the preceding nfs4_close_prepare() from sending open_downgrade 1964406 -> write call 1964408 -> downgrade (to read) reply seqid=4 (close of #1 retry) nfs_clear_open_stateid_locked() state->flags is [R] state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1 1964409 -> write reply (fails, openmode) Signed-off-by: Andrew Elble Cc: stable@vger,kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 33c7c20d62a7916522628fbb45bb65cbc0b9f899 Author: Chen-Yu Tsai Date: Tue Dec 22 02:27:35 2015 -0200 [media] rc: sunxi-cir: Initialize the spinlock properly [ Upstream commit 768acf46e1320d6c41ed1b7c4952bab41c1cde79 ] The driver allocates the spinlock but fails to initialize it correctly. The kernel reports a BUG indicating bad spinlock magic when spinlock debugging is enabled. Call spin_lock_init() on it to initialize it correctly. Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver") Signed-off-by: Chen-Yu Tsai Acked-by: Hans de Goede Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4476dc677064d27c1fb6ff28a47eeac384e8ba64 Author: Vegard Nossum Date: Fri Dec 11 15:54:16 2015 +0100 udf: limit the maximum number of indirect extents in a row [ Upstream commit b0918d9f476a8434b055e362b83fa4fd1d462c3f ] udf_next_aext() just follows extent pointers while extents are marked as indirect. This can loop forever for corrupted filesystem. Limit number the of indirect extents we are willing to follow in a row. [JK: Updated changelog, limit, style] Signed-off-by: Vegard Nossum Cc: stable@vger.kernel.org Cc: Jan Kara Cc: Quentin Casasnovas Cc: Andrew Morton Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit a2da01ce927dd98cb8f1a8f2d2343d2f5827b988 Author: Adrian Hunter Date: Thu Nov 26 14:00:50 2015 +0200 mmc: sdhci: Fix sdhci_runtime_pm_bus_on/off() [ Upstream commit 5c671c410c8704800f4f1673b6f572137e7e6ddd ] sdhci has a legacy facility to prevent runtime suspend if the bus power is on. This is needed in cases where the power to the card is dependent on the bus power. It is controlled by a pair of functions: sdhci_runtime_pm_bus_on() and sdhci_runtime_pm_bus_off(). These functions use a boolean variable 'bus_on' to ensure changes are always paired. There is an additional check for 'runtime_suspended' which is the problem. In fact, its use is ill-conceived as the only requirement for the logic is that 'on' and 'off' are paired, which is actually broken by the check, for example if the bus power is turned on during runtime resume. So remove the check. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # v3.11+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit b0aed82cdc3204ef04bfb05cab8a7892ed8bd9db Author: Adrian Hunter Date: Thu Nov 26 14:00:48 2015 +0200 mmc: sdhci: Fix DMA descriptor with zero data length [ Upstream commit 347ea32dc118326c4f2636928239a29d192cc9b8 ] SDHCI has built-in DMA called ADMA2. ADMA2 uses a descriptor table to define DMA scatter-gather. Each desciptor can specify a data length up to 65536 bytes, however the length field is only 16-bits so zero means 65536. Consequently, putting zero when the size is zero must not be allowed. This patch fixes one case where zero data length could be set inadvertently. The problem happens because unaligned data gets split and the code did not consider that the remaining aligned portion might be zero length. That case really only happens for SDIO because SD and eMMC cards transfer blocks that are invariably sector- aligned. For SDIO, access to function registers is done by data transfer (CMD53) when the register is bigger than 1 byte. Generally registers are 4 bytes but 2-byte registers are possible. So DMA of 4 bytes or less can happen. When 32-bit DMA is used, the data alignment must be 4, so 4-byte transfers won't casue a problem, but a 2-byte transfer could. However with the introduction of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes, so all 4-byte transfers not on 8-byte boundaries get "split" into a 4-byte chunk and a 0-byte chunk, thereby hitting the bug. In fact, a closer look at the SDHCI specs indicates that only the descriptor table requires 8-byte alignment for 64-bit DMA. That will be dealt with in a separate patch, but the potential for a 2-byte access remains, so this fix is needed anyway. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e6cbcb008a279d7794fba01799ecfb6be391484f Author: Adrian Hunter Date: Thu Nov 26 14:00:47 2015 +0200 mmc: sdio: Fix invalid vdd in voltage switch power cycle [ Upstream commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d ] The 'ocr' parameter passed to mmc_set_signal_voltage() defines the power-on voltage used when power cycling after a failure to set the voltage. However, in the case of mmc_sdio_init_card(), the value passed has the R4_18V_PRESENT flag set which is not valid for power-on and results in an invalid vdd. Fix by passing the card's ocr value which does not have the flag. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 86062e985300bc13fc5d29c862e34047bcb65c7e Author: Alex Deucher Date: Thu Dec 17 12:52:17 2015 -0500 drm/radeon: clean up fujitsu quirks [ Upstream commit 0eb1c3d4084eeb6fb3a703f88d6ce1521f8fcdd1 ] Combine the two quirks. bug: https://bugzilla.kernel.org/show_bug.cgi?id=109481 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 47062c9c6cf99ef7fa09a2458a26bb95edb02759 Author: Felix Kuehling Date: Mon Nov 23 17:39:11 2015 -0500 drm/radeon: Fix off-by-one errors in radeon_vm_bo_set_addr [ Upstream commit 42ef344c0994cc453477afdc7a8eadc578ed0257 ] eoffset is sometimes treated as the last address inside the address range, and sometimes as the first address outside the range. This was resulting in errors when a test filled up the entire address space. Make it consistent to always be the last address within the range. Also fixed related errors when checking the VA limit and in radeon_vm_fence_pts. Signed-off-by: Felix.Kuehling Reviewed-by: Christian König Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit dc25a0a0d2bc9296d0d66cbe7a17f698122d3c41 Author: Mathieu Poirier Date: Thu Dec 17 08:47:02 2015 -0700 coresight: checking for NULL string in coresight_name_match() [ Upstream commit fadf3a44e974b030e7145218ad1ab25e3ef91738 ] Connection child names associated to ports can sometimes be NULL, which is the case when booting a system on QEMU or when the Coresight power domain isn't switched on. This patch is adding a check to make sure a NULL string isn't fed to strcmp(), something that avoid crashing the system. Cc: # v3.18+ Reported-by: Tyler Baker Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5de8e1eed3221cb8737c2617c4567b70833795e6 Author: Lorenzo Pieralisi Date: Fri Dec 18 10:35:54 2015 +0000 arm64: kernel: enforce pmuserenr_el0 initialization and restore [ Upstream commit d2d39a3b91628ef5abdf58e83905b173e63d5ecf ] commit 60792ad349f3c6dc5735aafefe5dc9121c79e320 upstream. The pmuserenr_el0 register value is architecturally UNKNOWN on reset. Current kernel code resets that register value iff the core pmu device is correctly probed in the kernel. On platforms with missing DT pmu nodes (or disabled perf events in the kernel), the pmu is not probed, therefore the pmuserenr_el0 register is not reset in the kernel, which means that its value retains the reset value that is architecturally UNKNOWN (system may run with eg pmuserenr_el0 == 0x1, which means that PMU counters access is available at EL0, which must be disallowed). This patch adds code that resets pmuserenr_el0 on cold boot and restores it on core resume from shutdown, so that the pmuserenr_el0 setup is always enforced in the kernel. Cc: Mark Rutland Signed-off-by: Lorenzo Pieralisi Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1d4c425164b922424b3f86f93f3f0b7f85293fa7 Author: Will Deacon Date: Thu Aug 20 11:47:13 2015 +0100 arm64: mdscr_el1: avoid exposing DCC to userspace [ Upstream commit d8d23fa0f27f3b2942a7bbc7378c7735324ed519 ] We don't want to expose the DCC to userspace, particularly as there is a kernel console driver for it. This patch resets mdscr_el1 to disable userspace access to the DCC registers on the cold boot path. Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e70aade221a271f91e2d71901b2d602df2faee15 Author: Thomas Gleixner Date: Sat Dec 19 20:07:38 2015 +0000 futex: Drop refcount if requeue_pi() acquired the rtmutex [ Upstream commit fb75a4282d0d9a3c7c44d940582c2d226cf3acfb ] If the proxy lock in the requeue loop acquires the rtmutex for a waiter then it acquired also refcount on the pi_state related to the futex, but the waiter side does not drop the reference count. Add the missing free_pi_state() call. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: Darren Hart Cc: Davidlohr Bueso Cc: Bhuvanesh_Surachari@mentor.com Cc: Andy Lowe Link: http://lkml.kernel.org/r/20151219200607.178132067@linutronix.de Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 51697d5f76e114f27ec08958ea1970fc55db0438 Author: Slava Grigorev Date: Thu Dec 17 11:09:58 2015 -0500 drm/radeon: Fix "slow" audio over DP on DCE8+ [ Upstream commit ac4a9350abddc51ccb897abf0d9f3fd592b97e0b ] DP audio is derived from the dfs clock. Signed-off-by: Slava Grigorev Reviewed-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9e612a000cf889cfa624d984ccef770fdce43cf6 Author: Nikolay Borisov Date: Thu Dec 17 18:03:35 2015 +0200 dm thin: fix race condition when destroying thin pool workqueue [ Upstream commit 18d03e8c25f173f4107a40d0b8c24defb6ed69f3 ] When a thin pool is being destroyed delayed work items are cancelled using cancel_delayed_work(), which doesn't guarantee that on return the delayed item isn't running. This can cause the work item to requeue itself on an already destroyed workqueue. Fix this by using cancel_delayed_work_sync() which guarantees that on return the work item is not running anymore. Fixes: 905e51b39a555 ("dm thin: commit outstanding data every second") Fixes: 85ad643b7e7e5 ("dm thin: add timeout to stop out-of-data-space mode holding IO forever") Signed-off-by: Nikolay Borisov Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit bf0a6a9a3d53615aee7a3e04c12f88fdd3fc1d4c Author: Will Deacon Date: Tue Dec 15 16:08:12 2015 +0000 iommu/io-pgtable-arm: Ensure we free the final level on teardown [ Upstream commit 12c2ab09571e8aae3a87da2a4a452632a5fac1e5 ] When tearing down page tables, we return early for the final level since we know that we won't have any table pointers to follow. Unfortunately, this also means that we forget to free the final level, so we end up leaking memory. Fix the issue by always freeing the current level, but just don't bother to iterate over the ptes if we're at the final level. Cc: Reported-by: Zhang Bo Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 94fde0abd09b14f0e50efe87edb36ec0d1e88510 Author: Borislav Petkov Date: Fri Nov 27 10:38:38 2015 +0100 EDAC: Robustify workqueues destruction [ Upstream commit fcd5c4dd8201595d4c598c9cca5e54760277d687 ] EDAC workqueue destruction is really fragile. We cancel delayed work but if it is still running and requeues itself, we still go ahead and destroy the workqueue and the queued work explodes when workqueue core attempts to run it. Make the destruction more robust by switching op_state to offline so that requeuing stops. Cancel any pending work *synchronously* too. EDAC i7core: Driver loaded. general protection fault: 0000 [#1] SMP CPU 12 Modules linked in: Supported: Yes Pid: 0, comm: kworker/0:1 Tainted: G IE 3.0.101-0-default #1 HP ProLiant DL380 G7 RIP: 0010:[] [] __queue_work+0x17/0x3f0 < ... regs ...> Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600) Stack: ... Call Trace: call_timer_fn run_timer_softirq __do_softirq call_softirq do_softirq irq_exit smp_apic_timer_interrupt apic_timer_interrupt intel_idle cpuidle_idle_call cpu_idle Code: ... RIP __queue_work RSP <...> Signed-off-by: Borislav Petkov Cc: Signed-off-by: Sasha Levin commit eddf977af760a73a9072299e5a41bdb3de4c3930 Author: Borislav Petkov Date: Tue Dec 1 15:52:36 2015 +0100 EDAC, mc_sysfs: Fix freeing bus' name [ Upstream commit 12e26969b32c79018165d52caff3762135614aa1 ] I get the splat below when modprobing/rmmoding EDAC drivers. It happens because bus->name is invalid after bus_unregister() has run. The Code: section below corresponds to: .loc 1 1108 0 movq 672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus .loc 1 1109 0 popq %rbx # .loc 1 1108 0 movq (%rax), %rdi # _7->name, jmp kfree # and %rax has some funky stuff 2030203020312030 which looks a lot like something walked over it. Fix that by saving the name ptr before doing stuff to string it points to. general protection fault: 0000 [#1] SMP Modules linked in: ... CPU: 4 PID: 10318 Comm: modprobe Tainted: G I EN 3.12.51-11-default+ #48 Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011 task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000 RIP: 0010:[] [] edac_unregister_sysfs+0x22/0x30 [edac_core] RSP: 0018:ffff88030da3fe28 EFLAGS: 00010292 RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286 RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110 R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68 R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000 FS: 00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0 Stack: Call Trace: i7core_unregister_mci.isra.9 i7core_remove pci_device_remove __device_release_driver driver_detach bus_remove_driver pci_unregister_driver i7core_exit SyS_delete_module system_call_fastpath 0x7fc9bf426536 Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b RIP [] edac_unregister_sysfs+0x22/0x30 [edac_core] RSP Signed-off-by: Borislav Petkov Cc: Mauro Carvalho Chehab Cc: # v3.6.. Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device") Signed-off-by: Sasha Levin commit 1cbc3b7717e8a0c13ea5009b4157dfdf8f90b0b3 Author: Konstantin Khlebnikov Date: Mon Nov 16 18:44:11 2015 +0300 ovl: check dentry positiveness in ovl_cleanup_whiteouts() [ Upstream commit 84889d49335627bc770b32787c1ef9ebad1da232 ] This patch fixes kernel crash at removing directory which contains whiteouts from lower layers. Cache of directory content passed as "list" contains entries from all layers, including whiteouts from lower layers. So, lookup in upper dir (moved into work at this stage) will return negative entry. Plus this cache is filled long before and we can race with external removal. Example: mkdir -p lower0/dir lower1/dir upper work overlay touch lower0/dir/a lower0/dir/b mknod lower1/dir/a c 0 0 mount -t overlay none overlay -o lowerdir=lower1:lower0,upperdir=upper,workdir=work rm -fr overlay/dir Signed-off-by: Konstantin Khlebnikov Signed-off-by: Miklos Szeredi Cc: # 3.18+ Signed-off-by: Sasha Levin commit c8e1bebf86dff9277e21e9a2769724ca05f40c02 Author: Miklos Szeredi Date: Fri Dec 11 16:30:49 2015 +0100 ovl: setattr: check permissions before copy-up [ Upstream commit cf9a6784f7c1b5ee2b9159a1246e327c331c5697 ] Without this copy-up of a file can be forced, even without actually being allowed to do anything on the file. [Arnd Bergmann] include for PAGE_CACHE_SIZE (used by MAX_LFS_FILESIZE definition). Signed-off-by: Miklos Szeredi Cc: Signed-off-by: Sasha Levin commit 3d51d36e7148182e76fc36d66c494d192c410fdd Author: Uri Mashiach Date: Thu Dec 10 15:12:56 2015 +0200 wlcore/wl12xx: spi: fix oops on firmware load [ Upstream commit 9b2761cb72dc41e1948c8a5512b4efd384eda130 ] The maximum chunks used by the function is (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE + 1). The original commands array had space for (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) commands. When the last chunk is used (len > 4 * WSPI_MAX_CHUNK_SIZE), the last command is stored outside the bounds of the commands array. Oops 5 (page fault) is generated during current wl1271 firmware load attempt: root@debian-armhf:~# ifconfig wlan0 up [ 294.312399] Unable to handle kernel paging request at virtual address 00203fc4 [ 294.320173] pgd = de528000 [ 294.323028] [00203fc4] *pgd=00000000 [ 294.326916] Internal error: Oops: 5 [#1] SMP ARM [ 294.331789] Modules linked in: bnep rfcomm bluetooth ipv6 arc4 wl12xx wlcore mac80211 musb_dsps cfg80211 musb_hdrc usbcore usb_common wlcore_spi omap_rng rng_core musb_am335x omap_wdt cpufreq_dt thermal_sys hwmon [ 294.351838] CPU: 0 PID: 1827 Comm: ifconfig Not tainted 4.2.0-00002-g3e9ad27-dirty #78 [ 294.360154] Hardware name: Generic AM33XX (Flattened Device Tree) [ 294.366557] task: dc9d6d40 ti: de550000 task.ti: de550000 [ 294.372236] PC is at __spi_validate+0xa8/0x2ac [ 294.376902] LR is at __spi_sync+0x78/0x210 [ 294.381200] pc : [] lr : [] psr: 60000013 [ 294.381200] sp : de551998 ip : de5519d8 fp : 00200000 [ 294.393242] r10: de551c8c r9 : de5519d8 r8 : de3a9000 [ 294.398730] r7 : de3a9258 r6 : de3a9400 r5 : de551a48 r4 : 00203fbc [ 294.405577] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : de3a9000 [ 294.412420] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 294.419918] Control: 10c5387d Table: 9e528019 DAC: 00000015 [ 294.425954] Process ifconfig (pid: 1827, stack limit = 0xde550218) [ 294.432437] Stack: (0xde551998 to 0xde552000) ... [ 294.883613] [] (__spi_validate) from [] (__spi_sync+0x78/0x210) [ 294.891670] [] (__spi_sync) from [] (wl12xx_spi_raw_write+0xfc/0x148 [wlcore_spi]) [ 294.901661] [] (wl12xx_spi_raw_write [wlcore_spi]) from [] (wlcore_boot_upload_firmware+0x1ec/0x458 [wlcore]) [ 294.914038] [] (wlcore_boot_upload_firmware [wlcore]) from [] (wl12xx_boot+0xc10/0xfac [wl12xx]) [ 294.925161] [] (wl12xx_boot [wl12xx]) from [] (wl1271_op_add_interface+0x5b0/0x910 [wlcore]) [ 294.936364] [] (wl1271_op_add_interface [wlcore]) from [] (ieee80211_do_open+0x44c/0xf7c [mac80211]) [ 294.947963] [] (ieee80211_do_open [mac80211]) from [] (__dev_open+0xa8/0x110) [ 294.957307] [] (__dev_open) from [] (__dev_change_flags+0x88/0x148) [ 294.965713] [] (__dev_change_flags) from [] (dev_change_flags+0x18/0x48) [ 294.974576] [] (dev_change_flags) from [] (devinet_ioctl+0x6b4/0x7d0) [ 294.983191] [] (devinet_ioctl) from [] (sock_ioctl+0x1e4/0x2bc) [ 294.991244] [] (sock_ioctl) from [] (do_vfs_ioctl+0x420/0x6b0) [ 294.999208] [] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c) [ 295.006880] [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x54) [ 295.014835] Code: e1550004 e2444034 0a00007d e5953018 (e5942008) [ 295.021544] ---[ end trace 66ed188198f4e24e ]--- Signed-off-by: Uri Mashiach Acked-by: Igor Grinberg Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 76e8046ae4f3c7abd9e4f8ab69000609e554eb77 Author: Peter Wu Date: Mon Dec 7 01:07:31 2015 +0100 rtlwifi: fix memory leak for USB device [ Upstream commit 17bc55864f81dd730d05f09b1641312a7990d636 ] Free skb for received frames with a wrong checksum. This can happen pretty rapidly, exhausting all memory. This fixes a memleak (detected with kmemleak). Originally found while using monitor mode, but it also appears during managed mode (once the link is up). Cc: stable@vger.kernel.org Signed-off-by: Peter Wu ACKed-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 01e6b1f4cc792b0c932b3b37f273012af0ae50a1 Author: Ville Syrjälä Date: Thu Dec 3 23:14:09 2015 +0200 drm: Don't overwrite UNVERFIED mode status to OK [ Upstream commit be8719a610003297c28b140f1ebd4445aef1d613 ] The way the mode probing works is this: 1. All modes currently on the mode list are marked as UNVERIFIED 2. New modes are on the probed_modes list (they start with status OK) 3. Modes are moved from the probed_modes list to the actual mode list. If a mode already on the mode list is deemed to match one of the probed modes, the duplicate is dropped and the mode status updated to OK. After this the probed_modes list will be empty. 4. All modes on the mode list are verified to not violate any constraints. Any that do are marked as such. 5. Any mode left with a non-OK status is pruned from the list, with an appropriate debug message. What all this means is that any mode on the original list that didn't have a duplicate on the probed_modes list, should be left with status UNVERFIED (or previously could have been left with some other status, but never OK). I broke that in commit 05acaec334fc ("drm: Reorganize probed mode validation") by always assigning something to the mode->status during the validation step. So any mode from the old list that still passed the validation would be left on the list with status OK in the end. Fix this by not doing the basic mode validation unless the mode already has status OK (meaning it came from the probed_modes list, or at least a duplicate of it was on that list). This way we will correctly prune away any mode from the old mode list that didn't appear on the probed_modes list. Cc: stable@vger.kernel.org Cc: Adam Jackson Fixes: 05acaec334fc ("drm: Reorganize probed mode validation") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com Testcase: igt/kms_force_connector_basic/prune-stale-modes Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332 [danvet: Also applying to drm-misc to avoid too much conflict hell - there's a big pile of patches from Ville on top of this one.] Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit 138792935ec5f83d0e18b18e692be7341fa42a4a Author: Dmitry Tunin Date: Sat Dec 5 14:09:36 2015 +0300 Bluetooth: Add support of Toshiba Broadcom based devices [ Upstream commit 1623d0bf847d3b38d8cf24367b3689ba0e3fe2aa ] BugLink: https://bugs.launchpad.net/bugs/1522949 T: Bus=03 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=0225 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM43142A0 S: SerialNumber=4CBB58034671 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ba122961c9ef892d5b94d68fbb91d59e3d6ec38a Author: Miklos Szeredi Date: Wed Dec 9 16:11:59 2015 +0100 ovl: root: copy attr [ Upstream commit ed06e069775ad9236087594a1c1667367e983fb5 ] We copy i_uid and i_gid of underlying inode into overlayfs inode. Except for the root inode. Fix this omission. Signed-off-by: Miklos Szeredi Cc: Signed-off-by: Sasha Levin commit a94ff8213e3bd0918424f3208450955638f98197 Author: Thomas Huth Date: Fri Nov 20 09:11:45 2015 +0100 KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8 [ Upstream commit 760a7364f27d974d100118d88190e574626e18a6 ] In the old DABR register, the BT (Breakpoint Translation) bit is bit number 61. In the new DAWRX register, the WT (Watchpoint Translation) bit is bit number 59. So to move the DABR-BT bit into the position of the DAWRX-WT bit, it has to be shifted by two, not only by one. This fixes hardware watchpoints in gdb of older guests that only use the H_SET_DABR/X interface instead of the new H_SET_MODE interface. Cc: stable@vger.kernel.org # v3.14+ Signed-off-by: Thomas Huth Reviewed-by: Laurent Vivier Reviewed-by: David Gibson Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 51975a203210d3a94a7711651b1045ed0e3514ed Author: David Gibson Date: Mon Nov 30 12:30:30 2015 +1100 time: Avoid signed overflow in timekeeping_get_ns() [ Upstream commit 35a4933a895927990772ae96fdcfd2f806929ee2 ] 1e75fa8 "time: Condense timekeeper.xtime into xtime_sec" replaced a call to clocksource_cyc2ns() from timekeeping_get_ns() with an open-coded version of the same logic to avoid keeping a semi-redundant struct timespec in struct timekeeper. However, the commit also introduced a subtle semantic change - where clocksource_cyc2ns() uses purely unsigned math, the new version introduces a signed temporary, meaning that if (delta * tk->mult) has a 63-bit overflow the following shift will still give a negative result. The choice of 'maxsec' in __clocksource_updatefreq_scale() means this will generally happen if there's a ~10 minute pause in examining the clocksource. This can be triggered on a powerpc KVM guest by stopping it from qemu for a bit over 10 minutes. After resuming time has jumped backwards several minutes causing numerous problems (jiffies does not advance, msleep()s can be extended by minutes..). It doesn't happen on x86 KVM guests, because the guest TSC is effectively frozen while the guest is stopped, which is not the case for the powerpc timebase. Obviously an unsigned (64 bit) overflow will only take twice as long as a signed, 63-bit overflow. I don't know the time code well enough to know if that will still cause incorrect calculations, or if a 64-bit overflow is avoided elsewhere. Still, an incorrect forwards clock adjustment will cause less trouble than time going backwards. So, this patch removes the potential for intermediate signed overflow. Cc: stable@vger.kernel.org (3.7+) Suggested-by: Laurent Vivier Tested-by: Laurent Vivier Signed-off-by: David Gibson Signed-off-by: John Stultz Signed-off-by: Sasha Levin commit 549913712496e0534b1ee23dcaa24721e0edd6f4 Author: Thomas Petazzoni Date: Fri Dec 4 14:29:02 2015 +0100 ARM: mvebu: remove duplicated regulator definition in Armada 388 GP [ Upstream commit 079ae0c121fd23287f4ad2be9e9f8a13f63cae73 ] The Armada 388 GP Device Tree file describes two times a regulator named 'reg_usb2_1_vbus', with the exact same description. This has been wrong since Armada 388 GP support was introduced. Fixes: 928413bd859c0 ("ARM: mvebu: Add Armada 388 General Purpose Development Board support") Signed-off-by: Thomas Petazzoni Cc: # v4.0+ Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit f04d333fc68c2dc2441e2ef2ca12e2fc4793a587 Author: Alex Deucher Date: Tue Nov 24 14:32:44 2015 -0500 drm/radeon: call hpd_irq_event on resume [ Upstream commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9 ] Need to call this on resume if displays changes during suspend in order to properly be notified of changes. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f0193949e113c8bf87ed8d6143bcf5823dd78db0 Author: Steven Rostedt Date: Mon Nov 16 17:25:16 2015 -0500 tools lib traceevent: Fix output of %llu for 64 bit values read on 32 bit machines [ Upstream commit 32abc2ede536aae52978d6c0a8944eb1df14f460 ] When a long value is read on 32 bit machines for 64 bit output, the parsing needs to change "%lu" into "%llu", as the value is read natively. Unfortunately, if "%llu" is already there, the code will add another "l" to it and fail to parse it properly. Signed-off-by: Steven Rostedt Acked-by: Namhyung Kim Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20151116172516.4b79b109@gandalf.local.home Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 6649b1104932f3213f7e5aca7aefbdff7fbfae6b Author: Malcolm Priestley Date: Mon Aug 31 06:13:45 2015 -0300 [media] media: dvb-core: Don't force CAN_INVERSION_AUTO in oneshot mode [ Upstream commit c9d57de6103e343f2d4e04ea8d9e417e10a24da7 ] When in FE_TUNE_MODE_ONESHOT the frontend must report the actual capabilities so user can take appropriate action. With frontends that can't do auto inversion this is done by dvb-core automatically so CAN_INVERSION_AUTO is valid. However, when in FE_TUNE_MODE_ONESHOT this is not true. So only set FE_CAN_INVERSION_AUTO in modes other than FE_TUNE_MODE_ONESHOT Signed-off-by: Malcolm Priestley Cc: Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bf114c8b221d078ba4a5530732ea17b32367f216 Author: Antonio Ospite Date: Fri Oct 2 17:33:13 2015 -0300 [media] gspca: ov534/topro: prevent a division by 0 [ Upstream commit dcc7fdbec53a960588f2c40232db2c6466c09917 ] v4l2-compliance sends a zeroed struct v4l2_streamparm in v4l2-test-formats.cpp::testParmType(), and this results in a division by 0 in some gspca subdrivers: divide error: 0000 [#1] SMP Modules linked in: gspca_ov534 gspca_main ... CPU: 0 PID: 17201 Comm: v4l2-compliance Not tainted 4.3.0-rc2-ao2 #1 Hardware name: System manufacturer System Product Name/M2N-E SLI, BIOS ASUS M2N-E SLI ACPI BIOS Revision 1301 09/16/2010 task: ffff8800818306c0 ti: ffff880095c4c000 task.ti: ffff880095c4c000 RIP: 0010:[] [] sd_set_streamparm+0x12/0x60 [gspca_ov534] RSP: 0018:ffff880095c4fce8 EFLAGS: 00010296 RAX: 0000000000000000 RBX: ffff8800c9522000 RCX: ffffffffa077a140 RDX: 0000000000000000 RSI: ffff880095e0c100 RDI: ffff8800c9522000 RBP: ffff880095e0c100 R08: ffffffffa077a100 R09: 00000000000000cc R10: ffff880067ec7740 R11: 0000000000000016 R12: ffffffffa07bb400 R13: 0000000000000000 R14: ffff880081b6a800 R15: 0000000000000000 FS: 00007fda0de78740(0000) GS:ffff88012fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000014630f8 CR3: 00000000cf349000 CR4: 00000000000006f0 Stack: ffffffffa07a6431 ffff8800c9522000 ffffffffa077656e 00000000c0cc5616 ffff8800c9522000 ffffffffa07a5e20 ffff880095e0c100 0000000000000000 ffff880067ec7740 ffffffffa077a140 ffff880067ec7740 0000000000000016 Call Trace: [] ? v4l_s_parm+0x21/0x50 [videodev] [] ? vidioc_s_parm+0x4e/0x60 [gspca_main] [] ? __video_do_ioctl+0x280/0x2f0 [videodev] [] ? video_ioctl2+0x20/0x20 [videodev] [] ? video_usercopy+0x319/0x4e0 [videodev] [] ? page_add_new_anon_rmap+0x71/0xa0 [] ? mem_cgroup_commit_charge+0x52/0x90 [] ? handle_mm_fault+0xc18/0x1680 [] ? v4l2_ioctl+0xac/0xd0 [videodev] [] ? do_vfs_ioctl+0x28f/0x480 [] ? SyS_ioctl+0x74/0x80 [] ? entry_SYSCALL_64_fastpath+0x16/0x75 Code: c7 93 d9 79 a0 5b 5d e9 f1 f3 9a e0 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 31 d2 48 89 fb 48 83 ec 08 8b 46 10 76 0c 80 bf ac 0c 00 00 00 88 87 4e 0e 00 00 74 09 80 bf 4f RIP [] sd_set_streamparm+0x12/0x60 [gspca_ov534] RSP ---[ end trace 279710c2c6c72080 ]--- Following what the doc says about a zeroed timeperframe (see http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-parm.html): ... To reset manually applications can just set this field to zero. fix the issue by resetting the frame rate to a default value in case of an unusable timeperframe. The fix is done in the subdrivers instead of gspca.c because only the subdrivers have notion of a default frame rate to reset the camera to. Signed-off-by: Antonio Ospite Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b377c2be9c4cd3a8c422627d9964f257e6d0ed53 Author: Sasha Levin Date: Mon Feb 1 11:27:06 2016 -0500 [media] vb2: fix a regression in poll() behavior for output,streams [ Upstream commit 4623e5967448444a4ea1e77beb58898c4af48693 ] In the 3.17 kernel the poll() behavior changed for output streams: as long as not all buffers were queued up poll() would return that userspace can write. This is fine for the write() call, but when using stream I/O this changed the behavior since the expectation was that it would wait for buffers to become available for dequeuing. This patch only enables the check whether you can queue buffers for file I/O only, and skips it for stream I/O. Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart Cc: # for v3.17 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3c0a63d74b4a12a0a98cd85b195031d8d4b109a6 Author: Vito Caputo Date: Sat Oct 24 07:19:46 2015 -0500 ovl: use a minimal buffer in ovl_copy_xattr [ Upstream commit e4ad29fa0d224d05e08b2858e65f112fd8edd4fe ] Rather than always allocating the high-order XATTR_SIZE_MAX buffer which is costly and prone to failure, only allocate what is needed and realloc if necessary. Fixes https://github.com/coreos/bugs/issues/489 Signed-off-by: Miklos Szeredi Cc: Signed-off-by: Sasha Levin commit c000201d0b514b2324bfdaccb8bf8f63eafec6e8 Author: Miklos Szeredi Date: Tue Nov 10 17:08:41 2015 +0100 ovl: allow zero size xattr [ Upstream commit 97daf8b97ad6f913a34c82515be64dc9ac08d63e ] When ovl_copy_xattr() encountered a zero size xattr no more xattrs were copied and the function returned success. This is clearly not the desired behavior. Signed-off-by: Miklos Szeredi Cc: Signed-off-by: Sasha Levin