1. 27 Apr, 2015 15 commits
    • Dan Carpenter's avatar
      PCI: cpcihp: Add missing curly braces in cpci_configure_slot() · eb07dd0e
      Dan Carpenter authored
      commit bc3b5b47 upstream.
      
      I don't have this hardware but it looks like we weren't adding bridge
      devices as intended.  Maybe the bridge is always the last device?
      
      Fixes: 05b12500 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      eb07dd0e
    • Rasmus Villemoes's avatar
      PCI/AER: Avoid info leak in __print_tlp_header() · 253dc6c3
      Rasmus Villemoes authored
      commit a1b7f2f6 upstream.
      
      Commit fab4c256 ("PCI/AER: Add a TLP header print helper") introduced
      the helper function __print_tlp_header(), but contrary to the intention,
      the behaviour did change: Since we're taking the address of the parameter
      t, the first 4 or 8 bytes printed will be the value of the pointer t
      itself, and the remaining 12 or 8 bytes will be who-knows-what (something
      from the stack).
      
      We want to show the values of the four members of the struct
      aer_header_log_regs; that can be done without ugly and error-prone casts.
      On little-endian this should produce the same output as originally
      intended, and since no-one has complained about getting garbage output so
      far, I think big-endian should be ok too.
      
      Fixes: fab4c256 ("PCI/AER: Add a TLP header print helper")
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      253dc6c3
    • oliver@neukum.org's avatar
      HID: add ALWAYS_POLL quirk for a Logitech 0xc007 · c4481429
      oliver@neukum.org authored
      commit a4154577 upstream.
      
      This device disconnects every 60s without X
      Signed-off-by: default avatarOliver Neukum <oliver@neukum.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c4481429
    • Anton Nayshtut's avatar
      bonding: Bonding Overriding Configuration logic restored. · a744e383
      Anton Nayshtut authored
      commit f5e2dc5d upstream.
      
      Before commit 3900f290 ("bonding: slight
      optimizztion for bond_slave_override()") the override logic was to send packets
      with non-zero queue_id through the slave with corresponding queue_id, under two
      conditions only - if the slave can transmit and it's up.
      
      The above mentioned commit changed this logic by introducing an additional
      condition - whether the bond is active (indirectly, using the slave_can_tx and
      later - bond_is_active_slave), that prevents the user from implementing more
      complex policies according to the Documentation/networking/bonding.txt.
      Signed-off-by: default avatarAnton Nayshtut <anton@swortex.com>
      Signed-off-by: default avatarAlexey Bogoslavsky <alexey@swortex.com>
      Signed-off-by: default avatarAndy Gospodarek <gospo@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a744e383
    • Ben Hutchings's avatar
      usbnet: Fix tx_bytes statistic running backward in cdc_ncm · 08e0ae03
      Ben Hutchings authored
      commit 7a1e890e upstream.
      
      cdc_ncm disagrees with usbnet about how much framing overhead should
      be counted in the tx_bytes statistics, and tries 'fix' this by
      decrementing tx_bytes on the transmit path.  But statistics must never
      be decremented except due to roll-over; this will thoroughly confuse
      user-space.  Also, tx_bytes is only incremented by usbnet in the
      completion path.
      
      Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a
      tx_bytes delta along with the tx_packets count.
      
      Fixes: beeecd42 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics")
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      08e0ae03
    • Ben Hutchings's avatar
      usbnet: Fix tx_packets stat for FLAG_MULTI_FRAME drivers · 7d2237ad
      Ben Hutchings authored
      commit 1e9e39f4 upstream.
      
      Currently the usbnet core does not update the tx_packets statistic for
      drivers with FLAG_MULTI_PACKET and there is no hook in the TX
      completion path where they could do this.
      
      cdc_ncm and dependent drivers are bumping tx_packets stat on the
      transmit path while asix and sr9800 aren't updating it at all.
      
      Add a packet count in struct skb_data so these drivers can fill it
      in, initialise it to 1 for other drivers, and add the packet count
      to the tx_packets statistic on completion.
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Tested-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7d2237ad
    • Eric Dumazet's avatar
      tcp: tcp_make_synack() should clear skb->tstamp · 9c518c0e
      Eric Dumazet authored
      commit b50edd78 upstream.
      
      I noticed tcpdump was giving funky timestamps for locally
      generated SYNACK messages on loopback interface.
      
      11:42:46.938990 IP 127.0.0.1.48245 > 127.0.0.2.23850: S
      945476042:945476042(0) win 43690 <mss 65495,nop,nop,sackOK,nop,wscale 7>
      
      20:28:58.502209 IP 127.0.0.2.23850 > 127.0.0.1.48245: S
      3160535375:3160535375(0) ack 945476043 win 43690 <mss
      65495,nop,nop,sackOK,nop,wscale 7>
      
      This is because we need to clear skb->tstamp before
      entering lower stack, otherwise net_timestamp_check()
      does not set skb->tstamp.
      
      Fixes: 7faee5c0 ("tcp: remove TCP_SKB_CB(skb)->when")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9c518c0e
    • hannes@stressinduktion.org's avatar
      ipv6: protect skb->sk accesses from recursive dereference inside the stack · 426b9be6
      hannes@stressinduktion.org authored
      commit f60e5990 upstream.
      
      We should not consult skb->sk for output decisions in xmit recursion
      levels > 0 in the stack. Otherwise local socket settings could influence
      the result of e.g. tunnel encapsulation process.
      
      ipv6 does not conform with this in three places:
      
      1) ip6_fragment: we do consult ipv6_npinfo for frag_size
      
      2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
         loop the packet back to the local socket
      
      3) ip6_skb_dst_mtu could query the settings from the user socket and
         force a wrong MTU
      
      Furthermore:
      In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
      PF_PACKET socket ontop of an IPv6-backed vxlan device.
      
      Reuse xmit_recursion as we are currently only interested in protecting
      tunnel devices.
      
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      426b9be6
    • Michal Kubeček's avatar
      tcp: prevent fetching dst twice in early demux code · 404b73e7
      Michal Kubeček authored
      commit d0c294c5 upstream.
      
      On s390x, gcc 4.8 compiles this part of tcp_v6_early_demux()
      
              struct dst_entry *dst = sk->sk_rx_dst;
      
              if (dst)
                      dst = dst_check(dst, inet6_sk(sk)->rx_dst_cookie);
      
      to code reading sk->sk_rx_dst twice, once for the test and once for
      the argument of ip6_dst_check() (dst_check() is inline). This allows
      ip6_dst_check() to be called with null first argument, causing a crash.
      
      Protect sk->sk_rx_dst access by READ_ONCE() both in IPv4 and IPv6
      TCP early demux code.
      
      Fixes: 41063e9d ("ipv4: Early TCP socket demux.")
      Fixes: c7109986 ("ipv6: Early TCP socket demux")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: used davem's backport to 3.14 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      404b73e7
    • Nadav Amit's avatar
      KVM: x86: Fix lost interrupt on irr_pending race · 94cef1f5
      Nadav Amit authored
      commit f210f757 upstream.
      
      apic_find_highest_irr assumes irr_pending is set if any vector in APIC_IRR is
      set.  If this assumption is broken and apicv is disabled, the injection of
      interrupts may be deferred until another interrupt is delivered to the guest.
      Ultimately, if no other interrupt should be injected to that vCPU, the pending
      interrupt may be lost.
      
      commit 56cc2406 ("KVM: nVMX: fix "acknowledge interrupt on exit" when APICv
      is in use") changed the behavior of apic_clear_irr so irr_pending is cleared
      after setting APIC_IRR vector. After this commit, if apic_set_irr and
      apic_clear_irr run simultaneously, a race may occur, resulting in APIC_IRR
      vector set, and irr_pending cleared. In the following example, assume a single
      vector is set in IRR prior to calling apic_clear_irr:
      
      apic_set_irr				apic_clear_irr
      ------------				--------------
      apic->irr_pending = true;
      					apic_clear_vector(...);
      					vec = apic_search_irr(apic);
      					// => vec == -1
      apic_set_vector(...);
      					apic->irr_pending = (vec != -1);
      					// => apic->irr_pending == false
      
      Nonetheless, it appears the race might even occur prior to this commit:
      
      apic_set_irr				apic_clear_irr
      ------------				--------------
      apic->irr_pending = true;
      					apic->irr_pending = false;
      					apic_clear_vector(...);
      					if (apic_search_irr(apic) != -1)
      						apic->irr_pending = true;
      					// => apic->irr_pending == false
      apic_set_vector(...);
      
      Fixing this issue by:
      1. Restoring the previous behavior of apic_clear_irr: clear irr_pending, call
         apic_clear_vector, and then if APIC_IRR is non-zero, set irr_pending.
      2. On apic_set_irr: first call apic_set_vector, then set irr_pending.
      Signed-off-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      94cef1f5
    • Hans de Goede's avatar
      uas: Do not blacklist ASM1153 disk enclosures · f0932f97
      Hans de Goede authored
      commit 078fd7d6 upstream.
      
      Our detection logic to avoid doing UAS on ASM1051 bridge chips causes problems
      with newer ASM1153 disk enclosures in 2 ways:
      
      1) Some ASM1153 disk enclosures re-use the ASM1051 device-id of 5106, which
         we assume is always an ASM1051, so remove the quirk for 5106, and instead
         use the same detection logic as we already use for device-id 55aa, which is
         used for all of ASM1051, ASM1053 and ASM1153 devices <sigh>.
      
      2) Our detection logic to differentiate between ASM1051 and ASM1053 sees
         ASM1153 devices as ASM1051 because they have 32 streams like ASM1051 devs.
         Luckily the ASM1153 descriptors are not 100% identical, unlike the previous
         models the ASM1153 has bMaxPower == 0, so use that to differentiate it.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f0932f97
    • Arun Chandran's avatar
      arm64: vdso: fix build error when switching from LE to BE · 8b0caebc
      Arun Chandran authored
      commit 1915e2ad upstream.
      
      Building a kernel with CPU_BIG_ENDIAN fails if there are stale objects
      from a !CPU_BIG_ENDIAN build. Due to a missing FORCE prerequisite on an
      if_changed rule in the VDSO Makefile, we attempt to link a stale LE
      object into the new BE kernel.
      
      According to Documentation/kbuild/makefiles.txt, FORCE is required for
      if_changed rules and forgetting it is a common mistake, so fix it by
      'Forcing' the build of vdso. This patch fixes build errors like these:
      
      arch/arm64/kernel/vdso/note.o: compiled for a little endian system and target is big endian
      failed to merge target specific data of file arch/arm64/kernel/vdso/note.o
      
      arch/arm64/kernel/vdso/sigreturn.o: compiled for a little endian system and target is big endian
      failed to merge target specific data of file arch/arm64/kernel/vdso/sigreturn.o
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArun Chandran <achandran@mvista.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8b0caebc
    • Ian Abbott's avatar
      spi: spidev: fix possible arithmetic overflow for multi-transfer message · a53a7ec9
      Ian Abbott authored
      commit f20fbaad upstream.
      
      `spidev_message()` sums the lengths of the individual SPI transfers to
      determine the overall SPI message length.  It restricts the total
      length, returning an error if too long, but it does not check for
      arithmetic overflow.  For example, if the SPI message consisted of two
      transfers and the first has a length of 10 and the second has a length
      of (__u32)(-1), the total length would be seen as 9, even though the
      second transfer is actually very long.  If the second transfer specifies
      a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could
      overrun the spidev's pre-allocated tx buffer before it reaches an
      invalid user memory address.  Fix it by checking that neither the total
      nor the individual transfer lengths exceed the maximum allowed value.
      
      Thanks to Dan Carpenter for reporting the potential integer overflow.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      [ luis: backported to 3.16: used backport provided by Ian ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a53a7ec9
    • Peter Hurley's avatar
      n_tty: Fix read buffer overwrite when no newline · 2d38719a
      Peter Hurley authored
      commit fb5ef9e7 upstream.
      
      In canon mode, the read buffer head will advance over the buffer tail
      if the input > 4095 bytes without receiving a line termination char.
      
      Discard additional input until a line termination is received.
      Before evaluating for overflow, the 'room' value is normalized for
      I_PARMRK and 1 byte is reserved for line termination (even in !icanon
      mode, in case the mode is switched). The following table shows the
      transform:
      
       actual buffer |  'room' value before overflow calc
        space avail  |    !I_PARMRK    |    I_PARMRK
       --------------------------------------------------
            0        |       -1        |       -1
            1        |        0        |        0
            2        |        1        |        0
            3        |        2        |        0
            4+       |        3        |        1
      
      When !icanon or when icanon and the read buffer contains newlines,
      normalized 'room' values of -1 and 0 are clamped to 0, and
      'overflow' is 0, so read_head is not adjusted and the input i/o loop
      exits (setting no_room if called from flush_to_ldisc()). No input
      is discarded since the reader does have input available to read
      which ensures forward progress.
      
      When icanon and the read buffer does not contain newlines and the
      normalized 'room' value is 0, then overflow and room are reset to 1,
      so that the i/o loop will process the next input char normally
      (except for parity errors which are ignored). Thus, erasures, signalling
      chars, 7-bit mode, etc. will continue to be handled properly.
      
      If the input char processed was not a line termination char, then
      the canon_head index will not have advanced, so the normalized 'room'
      value will now be -1 and 'overflow' will be set, which indicates the
      read_head can safely be reset, effectively erasing the last char
      processed.
      
      If the input char processed was a line termination, then the
      canon_head index will have advanced, so 'overflow' is cleared to 0,
      the read_head is not reset, and 'room' is cleared to 0, which exits
      the i/o loop (because the reader now have input available to read
      which ensures forward progress).
      
      Note that it is possible for a line termination to be received, and
      for the reader to copy the line to the user buffer before the
      input i/o loop is ready to process the next input char. This is
      why the i/o loop recomputes the room/overflow state with every
      input char while handling overflow.
      
      Finally, if the input data was processed without receiving
      a line termination (so that overflow is still set), the pty
      driver must receive a write wakeup. A pty writer may be waiting
      to write more data in n_tty_write() but without unthrottling
      here that wakeup will not arrive, and forward progress will halt.
      (Normally, the pty writer is woken when the reader reads data out
      of the buffer and more space become available).
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2d38719a
    • Luis Henriques's avatar
      Linux 3.16.7-ckt10 · aaab4ac7
      Luis Henriques authored
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      aaab4ac7
  2. 21 Apr, 2015 11 commits
  3. 13 Apr, 2015 14 commits
    • Neal Cardwell's avatar
      tcp: fix FRTO undo on cumulative ACK of SACKed range · 39ae67b0
      Neal Cardwell authored
      commit 666b8051 upstream.
      
      On processing cumulative ACKs, the FRTO code was not checking the
      SACKed bit, meaning that there could be a spurious FRTO undo on a
      cumulative ACK of a previously SACKed skb.
      
      The FRTO code should only consider a cumulative ACK to indicate that
      an original/unretransmitted skb is newly ACKed if the skb was not yet
      SACKed.
      
      The effect of the spurious FRTO undo would typically be to make the
      connection think that all previously-sent packets were in flight when
      they really weren't, leading to a stall and an RTO.
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Fixes: e33099f9 ("tcp: implement RFC5682 F-RTO")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      39ae67b0
    • Jonathan Davies's avatar
      xen-netfront: transmit fully GSO-sized packets · 53d556c7
      Jonathan Davies authored
      commit 0c36820e upstream.
      
      xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
      GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
      bytes each. This slight reduction in the size of packets means a slight loss in
      efficiency.
      
      Since c/s 9ecd1a75, xen-netfront sets gso_max_size to
          XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
      where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.
      
      The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
      6c09fa09) in determining when to split an skb into two is
          sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.
      
      So the maximum permitted size of an skb is calculated to be
          (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.
      
      Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
      Instead, there is no need to deviate from the default gso_max_size of 65536 as
      this already accommodates the size of the header.
      
      Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
      of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
      skbs of up to 65160 bytes (45 segments of 1448 bytes each).
      
      Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
      it relates to the size of the whole packet, including the header.
      
      Fixes: 9ecd1a75 ("xen-netfront: reduce gso_max_size to account for max TCP header")
      Signed-off-by: default avatarJonathan Davies <jonathan.davies@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      53d556c7
    • Ido Shamay's avatar
      net/mlx4_en: Call register_netdevice in the proper location · 35dd2e41
      Ido Shamay authored
      commit e5eda89d upstream.
      
      Netdevice registration should be performed a the end of the driver
      initialization flow. If we don't do that, after calling register_netdevice,
      device callbacks may be issued by higher layers of the stack before
      final configuration of the device is done.
      
      For example (VXLAN configuration race), mlx4_SET_PORT_VXLAN was issued
      after the register_netdev command. System network scripts may configure
      the interface (UP) right after the registration, which also attach
      unicast VXLAN steering rule, before mlx4_SET_PORT_VXLAN was called,
      causing the firmware to fail the rule attachment.
      
      Fixes: 837052d0 ("net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling")
      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>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      35dd2e41
    • WANG Cong's avatar
      net: use for_each_netdev_safe() in rtnl_group_changelink() · c3bd57cd
      WANG Cong authored
      commit d079535d upstream.
      
      In case we move the whole dev group to another netns,
      we should call for_each_netdev_safe(), otherwise we get
      a soft lockup:
      
       NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ip:798]
       irq event stamp: 255424
       hardirqs last  enabled at (255423): [<ffffffff81a2aa95>] restore_args+0x0/0x30
       hardirqs last disabled at (255424): [<ffffffff81a2ad5a>] apic_timer_interrupt+0x6a/0x80
       softirqs last  enabled at (255422): [<ffffffff81079ebc>] __do_softirq+0x2c1/0x3a9
       softirqs last disabled at (255417): [<ffffffff8107a190>] irq_exit+0x41/0x95
       CPU: 0 PID: 798 Comm: ip Not tainted 4.0.0-rc4+ #881
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       task: ffff8800d1b88000 ti: ffff880119530000 task.ti: ffff880119530000
       RIP: 0010:[<ffffffff810cad11>]  [<ffffffff810cad11>] debug_lockdep_rcu_enabled+0x28/0x30
       RSP: 0018:ffff880119533778  EFLAGS: 00000246
       RAX: ffff8800d1b88000 RBX: 0000000000000002 RCX: 0000000000000038
       RDX: 0000000000000000 RSI: ffff8800d1b888c8 RDI: ffff8800d1b888c8
       RBP: ffff880119533778 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 000000000000b5c2 R12: 0000000000000246
       R13: ffff880119533708 R14: 00000000001d5a40 R15: ffff88011a7d5a40
       FS:  00007fc01315f740(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 00007f367a120988 CR3: 000000011849c000 CR4: 00000000000007f0
       Stack:
        ffff880119533798 ffffffff811ac868 ffffffff811ac831 ffffffff811ac828
        ffff8801195337c8 ffffffff811ac8c9 ffff8801195339b0 ffff8801197633e0
        0000000000000000 ffff8801195339b0 ffff8801195337d8 ffffffff811ad2d7
       Call Trace:
        [<ffffffff811ac868>] rcu_read_lock+0x37/0x6e
        [<ffffffff811ac831>] ? rcu_read_unlock+0x5f/0x5f
        [<ffffffff811ac828>] ? rcu_read_unlock+0x56/0x5f
        [<ffffffff811ac8c9>] __fget+0x2a/0x7a
        [<ffffffff811ad2d7>] fget+0x13/0x15
        [<ffffffff811be732>] proc_ns_fget+0xe/0x38
        [<ffffffff817c7714>] get_net_ns_by_fd+0x11/0x59
        [<ffffffff817df359>] rtnl_link_get_net+0x33/0x3e
        [<ffffffff817df3d7>] do_setlink+0x73/0x87b
        [<ffffffff810b28ce>] ? trace_hardirqs_off+0xd/0xf
        [<ffffffff81a2aa95>] ? retint_restore_args+0xe/0xe
        [<ffffffff817e0301>] rtnl_newlink+0x40c/0x699
        [<ffffffff817dffe0>] ? rtnl_newlink+0xeb/0x699
        [<ffffffff81a29246>] ? _raw_spin_unlock+0x28/0x33
        [<ffffffff8143ed1e>] ? security_capable+0x18/0x1a
        [<ffffffff8107da51>] ? ns_capable+0x4d/0x65
        [<ffffffff817de5ce>] rtnetlink_rcv_msg+0x181/0x194
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de44d>] ? __rtnl_unlock+0x17/0x17
        [<ffffffff818327c6>] netlink_rcv_skb+0x4d/0x93
        [<ffffffff817de42f>] rtnetlink_rcv+0x26/0x2d
        [<ffffffff81830f18>] netlink_unicast+0xcb/0x150
        [<ffffffff8183198e>] netlink_sendmsg+0x501/0x523
        [<ffffffff8115cba9>] ? might_fault+0x59/0xa9
        [<ffffffff817b5398>] ? copy_from_user+0x2a/0x2c
        [<ffffffff817b7b74>] sock_sendmsg+0x34/0x3c
        [<ffffffff817b7f6d>] ___sys_sendmsg+0x1b8/0x255
        [<ffffffff8115c5eb>] ? handle_pte_fault+0xbd5/0xd4a
        [<ffffffff8100a2b0>] ? native_sched_clock+0x35/0x37
        [<ffffffff8109e94b>] ? sched_clock_local+0x12/0x72
        [<ffffffff8109eb9c>] ? sched_clock_cpu+0x9e/0xb7
        [<ffffffff810cadbf>] ? rcu_read_lock_held+0x3b/0x3d
        [<ffffffff811ac1d8>] ? __fcheck_files+0x4c/0x58
        [<ffffffff811ac946>] ? __fget_light+0x2d/0x52
        [<ffffffff817b8adc>] __sys_sendmsg+0x42/0x60
        [<ffffffff817b8b0c>] SyS_sendmsg+0x12/0x1c
        [<ffffffff81a29e32>] system_call_fastpath+0x12/0x17
      
      Fixes: e7ed828f ("netlink: support setting devgroup parameters")
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c3bd57cd
    • Shachar Raindel's avatar
      IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic · c8f7da00
      Shachar Raindel authored
      commit 8494057a upstream.
      
      Properly verify that the resulting page aligned end address is larger
      than both the start address and the length of the memory area requested.
      
      Both the start and length arguments for ib_umem_get are controlled by
      the user. A misbehaving user can provide values which will cause an
      integer overflow when calculating the page aligned end address.
      
      This overflow can cause also miscalculation of the number of pages
      mapped, and additional logic issues.
      
      Addresses: CVE-2014-8159
      Signed-off-by: default avatarShachar Raindel <raindel@mellanox.com>
      Signed-off-by: default avatarJack Morgenstein <jackm@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c8f7da00
    • Johannes Berg's avatar
      mac80211: fix RX A-MPDU session reorder timer deletion · e4687bfe
      Johannes Berg authored
      commit 788211d8 upstream.
      
      There's an issue with the way the RX A-MPDU reorder timer is
      deleted that can cause a kernel crash like this:
      
       * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
       * station is destroyed
       * reorder timer fires before ieee80211_free_tid_rx() runs,
         accessing the station, thus potentially crashing due to
         the use-after-free
      
      The station deletion is protected by synchronize_net(), but
      that isn't enough -- ieee80211_free_tid_rx() need not have
      run when that returns (it deletes the timer.) We could use
      rcu_barrier() instead of synchronize_net(), but that's much
      more expensive.
      
      Instead, to fix this, add a field tracking that the session
      is being deleted. In this case, the only re-arming of the
      timer happens with the reorder spinlock held, so make that
      code not rearm it if the session is being deleted and also
      delete the timer after setting that field. This ensures the
      timer cannot fire after ___ieee80211_stop_rx_ba_session()
      returns, which fixes the problem.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e4687bfe
    • Stefan Lippers-Hollmann's avatar
      x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk · 77f6f3ba
      Stefan Lippers-Hollmann authored
      commit 80313b30 upstream.
      
      The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
      both BIOS and UEFI mode while rebooting unless reboot=pci is
      used. Add a quirk to reboot via the pci method.
      
      The problem is very intermittent and hard to debug, it might succeed
      rebooting just fine 40 times in a row - but fails half a dozen times
      the next day. It seems to be slightly less common in BIOS CSM mode
      than native UEFI (with the CSM disabled), but it does happen in either
      mode. Since I've started testing this patch in late january, rebooting
      has been 100% reliable.
      
      Most of the time it already hangs during POST, but occasionally it
      might even make it through the bootloader and the kernel might even
      start booting, but then hangs before the mode switch. The same symptoms
      occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
      kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
      Upgrading to the most current mainboard firmware of the ASRock
      Q1900DC-ITX, version 1.20, does not improve the situation.
      
      ( Searching the web seems to suggest that other Bay Trail-D mainboards
        might be affected as well. )
      --
      Signed-off-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mirSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      77f6f3ba
    • Peter Ujfalusi's avatar
      dmaengine: omap-dma: Fix memory leak when terminating running transfer · 61086ac6
      Peter Ujfalusi authored
      commit 02d88b73 upstream.
      
      In omap_dma_start_desc the vdesc->node is removed from the virt-dma
      framework managed lists (to be precise from the desc_issued list).
      If a terminate_all comes before the transfer finishes the omap_desc will
      not be freed up because it is not in any of the lists and we stopped the
      DMA channel so the transfer will not going to complete.
      There is no special sequence for leaking memory when using cyclic (audio)
      transfer: with every start and stop of a cyclic transfer the driver leaks
      struct omap_desc worth of memory.
      
      Free up the allocated memory directly in omap_dma_terminate_all() since the
      framework will not going to do that for us.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: <linux-omap@vger.kernel.org>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      61086ac6
    • Petr Kulhavy's avatar
      dmaengine: edma: fix memory leak when terminating running transfers · 14a39537
      Petr Kulhavy authored
      commit 5ca9e7ce upstream.
      
      If edma_terminate_all() was called while a transfer was running (i.e. after
      edma_execute() but before edma_callback()) the echan->edesc was not freed.
      
      This was due to the fact that a running transfer is on none of the
      vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
      removes it from the desc_issued list), so the vchan_dma_desc_free_list()
      called at the end of edma_terminate_all() didn't find it and didn't free it.
      
      This bug was found on an AM1808 based hardware (very similar to da850evm,
      however using the second MMC/SD controller), where intense operations on the SD
      card wasted the device 128MB RAM within a couple of days.
      
      Peter Ujfalusi:
      The issue is even more severe since it affects cyclic (audio) transfers as
      well. In this case starting/stopping audio will results memory leak.
      Signed-off-by: default avatarPetr Kulhavy <petr@barix.com>
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: <linux-omap@vger.kernel.org>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      14a39537
    • Darshana Padmadas's avatar
      iio: imu: Use iio_trigger_get for indio_dev->trig assignment · 3744e086
      Darshana Padmadas authored
      commit 4ce7ca89 upstream.
      
      This patch uses iio_trigger_get to increment the reference
      count of trigger device, to avoid incorrect assignment.
      Can result in a null pointer dereference during removal if the
      trigger has been changed before removal.
      
      This patch refers to a similar situation encountered through the
      following discussion:
      http://www.spinics.net/lists/linux-iio/msg13669.htmlSigned-off-by: default avatarDarshana Padmadas <darshanapadmadas@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3744e086
    • Stefan Agner's avatar
      iio: adc: vf610: use ADC clock within specification · 6ba8fef3
      Stefan Agner authored
      commit f54e9f2b upstream.
      
      Depending on conversion mode used, the ADC clock (ADCK) needs
      to be below a maximum frequency. According to Vybrid's data
      sheet this is 20MHz for the low power conversion mode.
      
      The ADC clock is depending on input clock, which is the bus
      clock by default. Vybrid SoC are typically clocked at at 400MHz
      or 500MHz, which leads to 66MHz or 83MHz bus clock respectively.
      Hence, a divider of 8 is required to stay below the specified
      maximum clock of 20MHz.
      
      Due to the different bus clock speeds, the resulting sampling
      frequency is not static. Hence use the ADC clock and calculate
      the actual available sampling frequency dynamically.
      
      This fixes bogous values observed on some 500MHz clocked Vybrid
      SoC. The resulting value usually showed Bit 9 being stuck at 1,
      or 0, which lead to a value of +/-512.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Acked-by: default avatarFugang Duan <B38611@freescale.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6ba8fef3
    • David Miller's avatar
      radeon: Do not directly dereference pointers to BIOS area. · 550a4e07
      David Miller authored
      commit f2c9e560 upstream.
      
      Use readb() and memcpy_fromio() accessors instead.
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      550a4e07
    • Alex Deucher's avatar
      drm/radeon/dpm: fix 120hz handling harder · 00092107
      Alex Deucher authored
      commit 3899ca84 upstream.
      
      Need to expand the check to handle short circuiting
      if the selected state is the same as current state.
      
      bug:
      https://bugs.freedesktop.org/show_bug.cgi?id=87796Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      00092107
    • Stefan Agner's avatar
      tty: serial: fsl_lpuart: clear receive flag on FIFO flush · 96fbe89f
      Stefan Agner authored
      commit 8e4934c6 upstream.
      
      When the receiver was enabled during startup, a character could
      have been in the FIFO when the UART get initially used. The
      driver configures the (receive) watermark level, and flushes the
      FIFO. However, the receive flag (RDRF) could still be set at that
      stage (as mentioned in the register description of UARTx_RWFIFO).
      This leads to an interrupt which won't be handled properly in
      interrupt mode: The receive interrupt function lpuart_rxint checks
      the FIFO count, which is 0 at that point (due to the flush
      during initialization). The problem does not manifest when using
      DMA to receive characters.
      
      Fix this situation by explicitly read the status register, which
      leads to clearing of the RDRF flag. Due to the flush just after
      the status flag read, a explicit data read is not to required.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      96fbe89f