1. 13 Jul, 2015 16 commits
    • Simon Guinot's avatar
      ARM: mvebu: update Ethernet compatible string for Armada XP · ea782226
      Simon Guinot authored
      [ Upstream commit ea3b55fe ]
      
      This patch updates the Ethernet DT nodes for Armada XP SoCs with the
      compatible string "marvell,armada-xp-neta".
      Signed-off-by: default avatarSimon Guinot <simon.guinot@sequanux.org>
      Fixes: 77916519 ("arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces")
      Acked-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Reviewed-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ea782226
    • Simon Guinot's avatar
      net: mvneta: introduce compatible string "marvell, armada-xp-neta" · 2027c1d3
      Simon Guinot authored
      [ Upstream commit f522a975 ]
      
      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: default avatarSimon Guinot <simon.guinot@sequanux.org>
      Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit")
      Acked-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Acked-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2027c1d3
    • Tom Lendacky's avatar
      amd-xgbe: Add the __GFP_NOWARN flag to Rx buffer allocation · fb0e5c08
      Tom Lendacky authored
      [ Upstream commit 472cfe71 ]
      
      When allocating Rx related buffers, alloc_pages is called using an order
      number that is decreased until successful. A system under stress can
      experience failures during this allocation process resulting in a warning
      being issued. This message can be of concern to end users even though the
      failure is not fatal. Since the failure is not fatal and can occur
      multiple times, the driver should include the __GFP_NOWARN flag to
      suppress the warning message from being issued.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      fb0e5c08
    • Alexander Sverdlin's avatar
      sctp: Fix race between OOTB responce and route removal · bbc5c1b7
      Alexander Sverdlin authored
      [ Upstream commit 29c4afc4 ]
      
      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: [<ffffffffa05ec9ac>] 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:[<ffffffffa05ec9ac>]  [<ffffffffa05ec9ac>] 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:
       <IRQ>
       [<ffffffffa05c94c5>] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp]
       [<ffffffffa05d6b42>] ? sctp_transport_put+0x52/0x80 [sctp]
       [<ffffffffa05d0bfc>] sctp_do_sm+0xb8c/0x19a0 [sctp]
       [<ffffffff810b0e00>] ? trigger_load_balance+0x90/0x210
       [<ffffffff810e0329>] ? update_process_times+0x59/0x60
       [<ffffffff812c7a40>] ? timerqueue_add+0x60/0xb0
       [<ffffffff810e0549>] ? enqueue_hrtimer+0x29/0xa0
       [<ffffffff8101f599>] ? read_tsc+0x9/0x10
       [<ffffffff8116d4b5>] ? put_page+0x55/0x60
       [<ffffffff810ee1ad>] ? clockevents_program_event+0x6d/0x100
       [<ffffffff81462b68>] ? skb_free_head+0x58/0x80
       [<ffffffffa029a10b>] ? chksum_update+0x1b/0x27 [crc32c_generic]
       [<ffffffff81283f3e>] ? crypto_shash_update+0xce/0xf0
       [<ffffffffa05d3993>] sctp_endpoint_bh_rcv+0x113/0x280 [sctp]
       [<ffffffffa05dd4e6>] sctp_inq_push+0x46/0x60 [sctp]
       [<ffffffffa05ed7a0>] sctp_rcv+0x880/0x910 [sctp]
       [<ffffffffa05ecb50>] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp]
       [<ffffffffa05ecb70>] ? sctp_csum_update+0x20/0x20 [sctp]
       [<ffffffff814b05a5>] ? ip_route_input_noref+0x235/0xd30
       [<ffffffff81051d6b>] ? ack_ioapic_level+0x7b/0x150
       [<ffffffff814b27be>] ip_local_deliver_finish+0xae/0x210
       [<ffffffff814b2e15>] ip_local_deliver+0x35/0x90
       [<ffffffff814b2a15>] ip_rcv_finish+0xf5/0x370
       [<ffffffff814b3128>] ip_rcv+0x2b8/0x3a0
       [<ffffffff81474193>] __netif_receive_skb_core+0x763/0xa50
       [<ffffffff81476c28>] __netif_receive_skb+0x18/0x60
       [<ffffffff81476cb0>] netif_receive_skb_internal+0x40/0xd0
       [<ffffffff814776c8>] napi_gro_receive+0xe8/0x120
       [<ffffffffa03946aa>] rtl8169_poll+0x2da/0x660 [r8169]
       [<ffffffff8147896a>] net_rx_action+0x21a/0x360
       [<ffffffff81078dc1>] __do_softirq+0xe1/0x2d0
       [<ffffffff8107912d>] irq_exit+0xad/0xb0
       [<ffffffff8157d158>] do_IRQ+0x58/0xf0
       [<ffffffff8157b06d>] common_interrupt+0x6d/0x6d
       <EOI>
       [<ffffffff810e1218>] ? hrtimer_start+0x18/0x20
       [<ffffffffa05d65f9>] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp]
       [<ffffffff81020c50>] ? mwait_idle+0x60/0xa0
       [<ffffffff810216ef>] arch_cpu_idle+0xf/0x20
       [<ffffffff810b731c>] cpu_startup_entry+0x3ec/0x480
       [<ffffffff8156b365>] rest_init+0x85/0x90
       [<ffffffff818eb035>] start_kernel+0x48b/0x4ac
       [<ffffffff818ea120>] ? early_idt_handlers+0x120/0x120
       [<ffffffff818ea339>] x86_64_start_reservations+0x2a/0x2c
       [<ffffffff818ea49c>] 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  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
       RSP <ffff880127c037b8>
      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: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      bbc5c1b7
    • Eric Dumazet's avatar
      bnx2x: fix lockdep splat · 5bf4e599
      Eric Dumazet authored
      [ Upstream commit d53c66a5 ]
      
      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]  [<ffffffff816eb1cd>] dump_stack+0x4c/0x65
      [   44.777879]  [<ffffffff8111d921>] ? console_unlock+0x1f1/0x510
      [   44.783708]  [<ffffffff811121f5>] __lock_acquire+0x1d05/0x1f10
      [   44.789538]  [<ffffffff8111370a>] ? mark_held_locks+0x6a/0x90
      [   44.795276]  [<ffffffff81113835>] ? trace_hardirqs_on_caller+0x105/0x1d0
      [   44.801967]  [<ffffffff8111390d>] ? trace_hardirqs_on+0xd/0x10
      [   44.807793]  [<ffffffff811330fa>] ? hrtimer_try_to_cancel+0x4a/0x250
      [   44.814142]  [<ffffffff81112ba6>] lock_acquire+0xb6/0x290
      [   44.819537]  [<ffffffff810d6675>] ? flush_work+0x5/0x280
      [   44.824844]  [<ffffffff810d66ad>] flush_work+0x3d/0x280
      [   44.830061]  [<ffffffff810d6675>] ? flush_work+0x5/0x280
      [   44.835366]  [<ffffffff816f3c43>] ? schedule_hrtimeout_range+0x13/0x20
      [   44.841889]  [<ffffffff8112ec9b>] ? usleep_range+0x4b/0x50
      [   44.847365]  [<ffffffff8111370a>] ? mark_held_locks+0x6a/0x90
      [   44.853102]  [<ffffffff810d8585>] ? __cancel_work_timer+0x105/0x1c0
      [   44.859359]  [<ffffffff81113835>] ? trace_hardirqs_on_caller+0x105/0x1d0
      [   44.866045]  [<ffffffff810d851f>] __cancel_work_timer+0x9f/0x1c0
      [   44.872048]  [<ffffffffa0010982>] ? bnx2x_func_stop+0x42/0x90 [bnx2x]
      [   44.878481]  [<ffffffff810d8670>] cancel_work_sync+0x10/0x20
      [   44.884134]  [<ffffffffa00259e5>] bnx2x_chip_cleanup+0x245/0x730 [bnx2x]
      [   44.890829]  [<ffffffff8110ce02>] ? up+0x32/0x50
      [   44.895439]  [<ffffffff811306b5>] ? del_timer_sync+0x5/0xd0
      [   44.901005]  [<ffffffffa005596d>] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x]
      [   44.907527]  [<ffffffff811f1aef>] ? might_fault+0x5f/0xb0
      [   44.912921]  [<ffffffffa005851c>] bnx2x_reload_if_running+0x2c/0x50 [bnx2x]
      [   44.919879]  [<ffffffffa005a3c5>] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x]
      [   44.926664]  [<ffffffff815d498b>] dev_ethtool+0x55b/0x1c40
      [   44.932148]  [<ffffffff815dfdc7>] ? rtnl_lock+0x17/0x20
      [   44.937364]  [<ffffffff815e7f8b>] dev_ioctl+0x17b/0x630
      [   44.942582]  [<ffffffff815abf8d>] sock_do_ioctl+0x5d/0x70
      [   44.947972]  [<ffffffff815ac013>] sock_ioctl+0x73/0x280
      [   44.953192]  [<ffffffff8124c1c8>] do_vfs_ioctl+0x88/0x5b0
      [   44.958587]  [<ffffffff8110d0b3>] ? up_read+0x23/0x40
      [   44.963631]  [<ffffffff812584cc>] ? __fget_light+0x6c/0xa0
      [   44.969105]  [<ffffffff8124c781>] SyS_ioctl+0x91/0xb0
      [   44.974149]  [<ffffffff816f4dd7>] 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: eeed018c ("bnx2x: Add timestamping and PTP hardware clock support")
      Reported-by: default avatarMichel Lespinasse <walken@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Michal Kalderon <Michal.Kalderon@qlogic.com>
      Cc: Ariel Elior <Ariel.Elior@qlogic.com>
      Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
      Cc: David Decotigny <decot@google.com>
      Acked-by: default avatarSony Chacko <sony.chacko@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5bf4e599
    • Mugunthan V N's avatar
      net: phy: fix phy link up when limiting speed via device tree · 2e761f5a
      Mugunthan V N authored
      [ Upstream commit eb686231 ]
      
      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: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2e761f5a
    • Ido Shamay's avatar
      net/mlx4_en: Fix wrong csum complete report when rxvlan offload is disabled · 18d05726
      Ido Shamay authored
      [ Upstream commit 79a25852 ]
      
      The check_csum() function relied on hwtstamp_rx_filter to know if rxvlan
      offload is disabled. This is wrong since rxvlan offload can be switched
      on/off regardless of hwtstamp_rx_filter.
      
      Also moved check_csum to query CQE information to identify VLAN packets
      and removed the check of IP packets, since it has been validated before.
      
      Fixes: f8c6455b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
      Signed-off-by: default avatarIdo Shamay <idos@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      18d05726
    • Ido Shamay's avatar
      net/mlx4_en: Wake TX queues only when there's enough room · 82ebc57e
      Ido Shamay authored
      [ Upstream commit 488a9b48 ]
      
      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: default avatarIdo Shamay <idos@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      82ebc57e
    • Eran Ben Elisha's avatar
      net/mlx4_en: Release TX QP when destroying TX ring · 363f6210
      Eran Ben Elisha authored
      [ Upstream commit 0eb08514 ]
      
      TX ring QP wasn't released at mlx4_en_destroy_tx_ring. Instead, the code
      used the deprecated base_tx_qpn field. Move TX QP release to
      mlx4_en_destroy_tx_ring and remove the base_tx_qpn field.
      
      Fixes: ddae0349 ('net/mlx4: Change QP allocation scheme')
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      363f6210
    • Christoph Paasch's avatar
      tcp: Do not call tcp_fastopen_reset_cipher from interrupt context · a7b766d4
      Christoph Paasch authored
      [ Upstream commit dfea2aa6 ]
      
      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]  <IRQ>  [<ffffffff8171d53a>] dump_stack+0x4f/0x6d
      [   36.014085]  [<ffffffff810967d3>] ___might_sleep+0x103/0x170
      [   36.015117]  [<ffffffff81096892>] __might_sleep+0x52/0x90
      [   36.016117]  [<ffffffff8118e887>] kmem_cache_alloc_trace+0x47/0x190
      [   36.017266]  [<ffffffff81680d82>] ? tcp_fastopen_reset_cipher+0x42/0x130
      [   36.018485]  [<ffffffff81680d82>] tcp_fastopen_reset_cipher+0x42/0x130
      [   36.019679]  [<ffffffff81680f01>] tcp_fastopen_init_key_once+0x61/0x70
      [   36.020884]  [<ffffffff81680f2c>] __tcp_fastopen_cookie_gen+0x1c/0x60
      [   36.022058]  [<ffffffff816814ff>] tcp_try_fastopen+0x58f/0x730
      [   36.023118]  [<ffffffff81671788>] tcp_conn_request+0x3e8/0x7b0
      [   36.024185]  [<ffffffff810e3872>] ? __module_text_address+0x12/0x60
      [   36.025327]  [<ffffffff8167b2e1>] tcp_v4_conn_request+0x51/0x60
      [   36.026410]  [<ffffffff816727e0>] tcp_rcv_state_process+0x190/0xda0
      [   36.027556]  [<ffffffff81661f97>] ? __inet_lookup_established+0x47/0x170
      [   36.028784]  [<ffffffff8167c2ad>] tcp_v4_do_rcv+0x16d/0x3d0
      [   36.029832]  [<ffffffff812e6806>] ? security_sock_rcv_skb+0x16/0x20
      [   36.030936]  [<ffffffff8167cc8a>] tcp_v4_rcv+0x77a/0x7b0
      [   36.031875]  [<ffffffff816af8c3>] ? iptable_filter_hook+0x33/0x70
      [   36.032953]  [<ffffffff81657d22>] ip_local_deliver_finish+0x92/0x1f0
      [   36.034065]  [<ffffffff81657f1a>] ip_local_deliver+0x9a/0xb0
      [   36.035069]  [<ffffffff81657c90>] ? ip_rcv+0x3d0/0x3d0
      [   36.035963]  [<ffffffff81657569>] ip_rcv_finish+0x119/0x330
      [   36.036950]  [<ffffffff81657ba7>] ip_rcv+0x2e7/0x3d0
      [   36.037847]  [<ffffffff81610652>] __netif_receive_skb_core+0x552/0x930
      [   36.038994]  [<ffffffff81610a57>] __netif_receive_skb+0x27/0x70
      [   36.040033]  [<ffffffff81610b72>] process_backlog+0xd2/0x1f0
      [   36.041025]  [<ffffffff81611482>] net_rx_action+0x122/0x310
      [   36.042007]  [<ffffffff81076743>] __do_softirq+0x103/0x2f0
      [   36.042978]  [<ffffffff81723e3c>] 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 <eric.dumazet@gmail.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Fixes: 222e83d2 ("tcp: switch tcp_fastopen key generation to net_get_random_once")
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a7b766d4
    • Julian Anastasov's avatar
      neigh: do not modify unlinked entries · 435b53d9
      Julian Anastasov authored
      [ Upstream commit 2c51a97f ]
      
      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: 767e97e1 ("neigh: RCU conversion of struct neighbour")
      Fixes: a263b309 ("ipv4: Make neigh lookups directly in output packet path.")
      Fixes: 6fd6ce20 ("ipv6: Do not depend on rt->n in ip6_finish_output2().")
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      435b53d9
    • Willem de Bruijn's avatar
      packet: avoid out of bounds read in round robin fanout · 371bffd2
      Willem de Bruijn authored
      [ Upstream commit 468479e6 ]
      
      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: dc99f600 ("packet: Add fanout support.")
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      371bffd2
    • Eric Dumazet's avatar
      packet: read num_members once in packet_rcv_fanout() · f4f2cfaf
      Eric Dumazet authored
      [ Upstream commit f98f4514 ]
      
      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 95ec3eb4 ("packet: Add 'cpu' fanout policy.")
      
      Fixes: dc99f600 ("packet: Add fanout support.")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f4f2cfaf
    • Nikolay Aleksandrov's avatar
      bridge: fix br_stp_set_bridge_priority race conditions · 8f8d692a
      Nikolay Aleksandrov authored
      [ Upstream commit 2dab80a8 ]
      
      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:
      14f98f25 ("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:
      af615762 ("bridge: add ageing_time, stp_state, priority over netlink")
      Signed-off-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Fixes: 14f98f25 ("bridge: range check STP parameters")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8f8d692a
    • Marcelo Ricardo Leitner's avatar
      sctp: fix ASCONF list handling · a43e8e87
      Marcelo Ricardo Leitner authored
      [ Upstream commit 2d45a02d ]
      
      ->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: 9f7d653b ("sctp: Add Auto-ASCONF support (core).")
      Reported-by: default avatarJi Jianwen <jiji@redhat.com>
      Suggested-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Suggested-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Moritz Mühlenhoff <jmm@inutil.org>
      Reference: CVE-2015-3212
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a43e8e87
    • Shaohua Li's avatar
      net: don't wait for order-3 page allocation · ab17bd6e
      Shaohua Li authored
      [ Upstream commit fb05e7a8 ]
      
      We saw excessive direct memory compaction triggered by skb_page_frag_refill.
      This causes performance issues and add latency. Commit 5640f768
      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 <edumazet@google.com>
      Cc: Chris Mason <clm@fb.com>
      Cc: Debabrata Banerjee <dbavatar@gmail.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ab17bd6e
  2. 10 Jul, 2015 1 commit
  3. 07 Jul, 2015 1 commit
    • Brian Foster's avatar
      xfs: don't truncate attribute extents if no extents exist · 5bbed227
      Brian Foster authored
      commit f66bf042 upstream.
      
      The xfs_attr3_root_inactive() call from xfs_attr_inactive() assumes that
      attribute blocks exist to invalidate. It is possible to have an
      attribute fork without extents, however. Consider the case where the
      attribute fork is created towards the beginning of xfs_attr_set() but
      some part of the subsequent attribute set fails.
      
      If an inode in such a state hits xfs_attr_inactive(), it eventually
      calls xfs_dabuf_map() and possibly xfs_bmapi_read(). The former emits a
      filesystem corruption warning, returns an error that bubbles back up to
      xfs_attr_inactive(), and leads to destruction of the in-core attribute
      fork without an on-disk reset. If the inode happens to make it back
      through xfs_inactive() in this state (e.g., via a concurrent bulkstat
      that cycles the inode from the reclaim state and releases it), i_afp
      might not exist when xfs_bmapi_read() is called and causes a NULL
      dereference panic.
      
      A '-p 2' fsstress run to ENOSPC on a relatively small fs (1GB)
      reproduces these problems. The behavior is a regression caused by:
      
      6dfe5a04 xfs: xfs_attr_inactive leaves inconsistent attr fork state behind
      
      ... which removed logic that avoided the attribute extent truncate when
      no extents exist. Restore this logic to ensure the attribute fork is
      destroyed and reset correctly if it exists without any allocated
      extents.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5bbed227
  4. 06 Jul, 2015 22 commits
    • Nicolas Ferre's avatar
      clk: at91: fix h32mx prototype inclusion in pmc header · 44287b3b
      Nicolas Ferre authored
      commit 28df9c2f upstream.
      
      Trivial fix that prevents to compile this pmc clock driver if h32mx clock is
      present but smd clock isn't.
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Fixes: bcc5fd49 ("clk: at91: add a driver for the h32mx clock")
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      44287b3b
    • Boris Brezillon's avatar
      clk: at91: pll: fix input range validity check · 1c26ff6f
      Boris Brezillon authored
      commit 6c7b03e1 upstream.
      
      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.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reported-by: default avatarJonas Andersson <jonas@microbit.se>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1c26ff6f
    • Michel Dänzer's avatar
      drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query · 63cfdbb0
      Michel Dänzer authored
      commit 3bc980bf upstream.
      
      This tells userspace that it's safe to use the RADEON_VA_UNMAP operation
      of the DRM_RADEON_GEM_VA ioctl.
      
      (NOTE: Backporting this commit requires at least backports of commits
      26d4d129,
      48afbd70 and
      c29c0876 as well, otherwise using
      RADEON_VA_UNMAP runs into trouble)
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      63cfdbb0
    • Steven Rostedt's avatar
      tracing: Have filter check for balanced ops · 20d9ea55
      Steven Rostedt authored
      commit 2cf30dc1 upstream.
      
      When the following filter is used it causes a warning to trigger:
      
       # cd /sys/kernel/debug/tracing
       # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
      -bash: echo: write error: Invalid argument
       # cat events/ext4/ext4_truncate_exit/filter
      ((dev==1)blocks==2)
      ^
      parse_error: No error
      
       ------------[ cut here ]------------
       WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990()
       Modules linked in: bnep lockd grace bluetooth  ...
       CPU: 3 PID: 1223 Comm: bash Tainted: G        W       4.1.0-rc3-test+ #450
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
        0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0
        0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c
        ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea
       Call Trace:
        [<ffffffff816ed4f9>] dump_stack+0x4c/0x6e
        [<ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0
        [<ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80
        [<ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff81159065>] replace_preds+0x3c5/0x990
        [<ffffffff811596b2>] create_filter+0x82/0xb0
        [<ffffffff81159944>] apply_event_filter+0xd4/0x180
        [<ffffffff81152bbf>] event_filter_write+0x8f/0x120
        [<ffffffff811db2a8>] __vfs_write+0x28/0xe0
        [<ffffffff811dda43>] ? __sb_start_write+0x53/0xf0
        [<ffffffff812e51e0>] ? security_file_permission+0x30/0xc0
        [<ffffffff811dc408>] vfs_write+0xb8/0x1b0
        [<ffffffff811dc72f>] SyS_write+0x4f/0xb0
        [<ffffffff816f5217>] system_call_fastpath+0x12/0x6a
       ---[ end trace e11028bd95818dcd ]---
      
      Worse yet, reading the error message (the filter again) it says that
      there was no error, when there clearly was. The issue is that the
      code that checks the input does not check for balanced ops. That is,
      having an op between a closed parenthesis and the next token.
      
      This would only cause a warning, and fail out before doing any real
      harm, but it should still not caues a warning, and the error reported
      should work:
      
       # cd /sys/kernel/debug/tracing
       # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
      -bash: echo: write error: Invalid argument
       # cat events/ext4/ext4_truncate_exit/filter
      ((dev==1)blocks==2)
      ^
      parse_error: Meaningless filter expression
      
      And give no kernel warning.
      
      Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Tested-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      20d9ea55
    • Steve Cornelius's avatar
      crypto: caam - fix RNG buffer cache alignment · e3948f08
      Steve Cornelius authored
      commit 412c98c1 upstream.
      
      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.
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarVictoria Milhoan <vicki.milhoan@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e3948f08
    • Steve Cornelius's avatar
      crypto: caam - improve initalization for context state saves · 0cdc1492
      Steve Cornelius authored
      commit 6fd4b156 upstream.
      
      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 ]---
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarVictoria Milhoan <vicki.milhoan@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0cdc1492
    • Radim Krčmář's avatar
      KVM: x86: fix lapic.timer_mode on restore · 931fcee6
      Radim Krčmář authored
      commit b6ac0695 upstream.
      
      lapic.timer_mode was not properly initialized after migration, which
      broke few useful things, like login, by making every sleep eternal.
      
      Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore.
      
      There are other slowpaths that update lvtt, so this patch makes sure
      something similar doesn't happen again by calling apic_update_lvtt
      after every modification.
      
      Fixes: f30ebc31 ("KVM: x86: optimize some accesses to LVTT and SPIV")
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      931fcee6
    • Adam Jackson's avatar
      drm/mgag200: Reject non-character-cell-aligned mode widths · c269dcb6
      Adam Jackson authored
      commit 25161084 upstream.
      
      Turns out 1366x768 does not in fact work on this hardware.
      Signed-off-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c269dcb6
    • Hui Wang's avatar
      ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine · 6d512c32
      Hui Wang authored
      commit 6ab42ff4 upstream.
      
      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.
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      6d512c32
    • Sagi Grimberg's avatar
      iser-target: Fix possible use-after-free · 7f6080df
      Sagi Grimberg authored
      commit 524630d5 upstream.
      
      iser connection termination process happens in 2 stages:
      - isert_wait_conn:
        - resumes rdma disconnect
        - wait for session commands
        - wait for flush completions (post a marked wr to signal we are done)
        - wait for logout completion
        - queue work for connection cleanup (depends on disconnected/timewait
          events)
      - isert_free_conn
        - last reference put on the connection
      
      In case we are terminating during IOs, we might be posting send/recv
      requests after we posted the last work request which might lead
      to a use-after-free condition in isert_handle_wc.
      After we posted the last wr in isert_wait_conn we are guaranteed that
      no successful completions will follow (meaning no new work request posts
      may happen) but other flush errors might still come. So before we
      put the last reference on the connection, we repeat the process of
      posting a marked work request (isert_wait4flush) in order to make sure all
      pending completions were flushed.
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarJenny Falkovich <jennyf@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7f6080df
    • Sagi Grimberg's avatar
      iser-target: release stale iser connections · 0276e070
      Sagi Grimberg authored
      commit 2f1b6b7d upstream.
      
      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: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarJenny Falkovich <jennyf@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ luis: backported to 3.16:
        - use 'conn_accept_node' instead of 'accept_node' (field renamed by
          dac6ab30 "iser-target: Remove conn_ prefix from struct isert_conn members")
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0276e070
    • Sagi Grimberg's avatar
      iser-target: Fix variable-length response error completion · 23236e68
      Sagi Grimberg authored
      commit 9253e667 upstream.
      
      Since commit "2426bd45 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: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarJenny Falkovich <jennyf@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      23236e68
    • Nikolay Aleksandrov's avatar
      bridge: fix multicast router rlist endless loop · e5410324
      Nikolay Aleksandrov authored
      commit 1a040eac upstream.
      
      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: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Fixes: 0909e117 ("bridge: Add multicast_router sysfs entries")
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e5410324
    • Wilson Kok's avatar
      bridge: use _bh spinlock variant for br_fdb_update to avoid lockup · 5f2be513
      Wilson Kok authored
      commit 1d7c4903 upstream.
      
      br_fdb_update() can be called in process context in the following way:
      br_fdb_add() -> __br_fdb_add() -> br_fdb_update() (if NTF_USE flag is set)
      so we need to use spin_lock_bh because there are softirq users of the
      hash_lock. One easy way to reproduce this is to modify the bridge utility
      to set NTF_USE, enable stp and then set maxageing to a low value so
      br_fdb_cleanup() is called frequently and then just add new entries in
      a loop. This happens because br_fdb_cleanup() is called from timer/softirq
      context. These locks were _bh before commit f8ae737d
      ("[BRIDGE]: forwarding remove unneeded preempt and bh diasables")
      and at the time that commit was correct because br_fdb_update() couldn't be
      called from process context, but that changed after commit:
      292d1398 ("bridge: add NTF_USE support")
      Signed-off-by: default avatarWilson Kok <wkok@cumulusnetworks.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Fixes: 292d1398 ("bridge: add NTF_USE support")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5f2be513
    • Florian Fainelli's avatar
      net: bcmgenet: power on MII block for all MII modes · a9a986e8
      Florian Fainelli authored
      commit afe3f907 upstream.
      
      The RGMII block is currently only powered on when using RGMII or
      RGMII_NO_ID, which is not correct when using the GENET interface in MII
      or Reverse MII modes. We always need to power on the RGMII interface for
      this block to properly work, regardless of the MII mode in which we
      operate.
      
      Fixes: aa09677c ("net: bcmgenet: add MDIO routines")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a9a986e8
    • Dan Williams's avatar
      block: fix ext_dev_lock lockdep report · 31f0610a
      Dan Williams authored
      commit 4d66e5e9 upstream.
      
       =================================
       [ 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: [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70
       {SOFTIRQ-ON-W} state was registered at:
         [<ffffffff810bf6b1>] __lock_acquire+0x461/0x1e70
         [<ffffffff810c1947>] lock_acquire+0xb7/0x290
         [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
         [<ffffffff8143a07d>] blk_alloc_devt+0x6d/0xd0  <-- take the lock in process context
      [..]
        [<ffffffff810bf64e>] __lock_acquire+0x3fe/0x1e70
        [<ffffffff810c00ad>] ? __lock_acquire+0xe5d/0x1e70
        [<ffffffff810c1947>] lock_acquire+0xb7/0x290
        [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
        [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
        [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
        [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70    <-- take the lock in softirq
        [<ffffffff8143bfec>] part_release+0x1c/0x50
        [<ffffffff8158edf6>] device_release+0x36/0xb0
        [<ffffffff8145ac2b>] kobject_cleanup+0x7b/0x1a0
        [<ffffffff8145aad0>] kobject_put+0x30/0x70
        [<ffffffff8158f147>] put_device+0x17/0x20
        [<ffffffff8143c29c>] delete_partition_rcu_cb+0x16c/0x180
        [<ffffffff8143c130>] ? read_dev_sector+0xa0/0xa0
        [<ffffffff810e0e0f>] rcu_process_callbacks+0x2ff/0xa90
        [<ffffffff810e0dcf>] ? rcu_process_callbacks+0x2bf/0xa90
        [<ffffffff81067e2e>] __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: 2da78092 "block:
      Fix dev_t minor allocation lifetime".  Both this and 2da78092 are
      candidates for -stable.
      
      Fixes: 2da78092 ("block: Fix dev_t minor allocation lifetime")
      Cc: Keith Busch <keith.busch@intel.com>
      Reported-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      31f0610a
    • Michel Dänzer's avatar
      drm/radeon: Make sure radeon_vm_bo_set_addr always unreserves the BO · 877d1147
      Michel Dänzer authored
      commit ee18e599 upstream.
      
      Some error paths didn't unreserve the BO. This resulted in a deadlock
      down the road on the next attempt to reserve the (still reserved) BO.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90873Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      877d1147
    • Alex Deucher's avatar
      Revert "drm/radeon: adjust pll when audio is not enabled" · bdb01a95
      Alex Deucher authored
      commit ebb9bf18 upstream.
      
      This reverts commit 7fe04d6f.
      
      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=99651Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      bdb01a95
    • Alex Deucher's avatar
      Revert "drm/radeon: don't share plls if monitors differ in audio support" · bde11f37
      Alex Deucher authored
      commit 6fb3c025 upstream.
      
      This reverts commit a10f0df0.
      
      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=99651Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      bde11f37
    • Jérôme Glisse's avatar
      drm/radeon: fix freeze for laptop with Turks/Thames GPU. · ee7343f3
      Jérôme Glisse authored
      commit 6dfd1972 upstream.
      
      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: default avatarJérôme Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ee7343f3
    • Wang Long's avatar
      ring-buffer-benchmark: Fix the wrong sched_priority of producer · 38b6a0a7
      Wang Long authored
      commit 10802932 upstream.
      
      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.comSigned-off-by: default avatarWang Long <long.wanglong@huawei.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      38b6a0a7
    • Mel Gorman's avatar
      sched, numa: do not hint for NUMA balancing on VM_MIXEDMAP mappings · dd9aed05
      Mel Gorman authored
      commit 8e76d4ee upstream.
      
      Jovi Zhangwei reported the following problem
      
        Below kernel vm bug can be triggered by tcpdump which mmaped a lot of pages
        with GFP_COMP flag.
      
        [Mon May 25 05:29:33 2015] page:ffffea0015414000 count:66 mapcount:1 mapping:          (null) index:0x0
        [Mon May 25 05:29:33 2015] flags: 0x20047580004000(head)
        [Mon May 25 05:29:33 2015] page dumped because: VM_BUG_ON_PAGE(compound_order(page) && !PageTransHuge(page))
        [Mon May 25 05:29:33 2015] ------------[ cut here ]------------
        [Mon May 25 05:29:33 2015] kernel BUG at mm/migrate.c:1661!
        [Mon May 25 05:29:33 2015] invalid opcode: 0000 [#1] SMP
      
      In this case it was triggered by running tcpdump but it's not necessary
      reproducible on all systems.
      
        sudo tcpdump -i bond0.100 'tcp port 4242' -c 100000000000 -w 4242.pcap
      
      Compound pages cannot be migrated and it was not expected that such pages
      be marked for NUMA balancing.  This did not take into account that drivers
      such as net/packet/af_packet.c may insert compound pages into userspace
      with vm_insert_page.  This patch tells the NUMA balancing protection
      scanner to skip all VM_MIXEDMAP mappings which avoids the possibility that
      compound pages are marked for migration.
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Reported-by: default avatarJovi Zhangwei <jovi@cloudflare.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ kamal: backport to 3.19-stable ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      dd9aed05