1. 23 Feb, 2017 40 commits
    • Paul Fertser's avatar
      Revert "staging: nvec: ps2: change serio type to passthrough" · 2386b74f
      Paul Fertser authored
      commit 17c1c9ba upstream.
      
      This reverts commit 36b30d61.
      
      This is necessary to detect paz00 (ac100) touchpad properly as one
      speaking ETPS/2 protocol. Without it X.org's synaptics driver doesn't
      work as the touchpad is detected as an ImPS/2 mouse instead.
      
      Commit ec6184b1 changed the way
      auto-detection is performed on ports marked as pass through and made the
      issue apparent.
      
      A pass through port is an additional PS/2 port used to connect a slave
      device to a master device that is using PS/2 to communicate with the
      host (so slave's PS/2 communication is tunneled over master's PS/2
      link). "Synaptics PS/2 TouchPad Interfacing Guide" describes such a
      setup (PS/2 PASS-THROUGH OPTION section).
      
      Since paz00's embedded controller is not connected to a PS/2 port
      itself, the PS/2 interface it exposes is not a pass-through one.
      Signed-off-by: default avatarPaul Fertser <fercerpav@gmail.com>
      Acked-by: default avatarMarc Dietrich <marvin24@gmx.de>
      Fixes: 36b30d61 ("staging: nvec: ps2: change serio type to passthrough")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2386b74f
    • Paul Fertser's avatar
      drivers: staging: nvec: remove bogus reset command for PS/2 interface · 6984cd1a
      Paul Fertser authored
      commit d8f8a74d upstream.
      
      This command was sent behind serio's back and the answer to it was
      confusing atkbd probe function which lead to the elantech touchpad
      getting detected as a keyboard.
      
      To prevent this from happening just let every party do its part of the
      job.
      Signed-off-by: default avatarPaul Fertser <fercerpav@gmail.com>
      Acked-by: default avatarMarc Dietrich <marvin24@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6984cd1a
    • Doug Brown's avatar
      USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad · 8f44c909
      Doug Brown authored
      commit 9bfef729 upstream.
      
      This patch adds support for the TI CC3200 LaunchPad board, which uses a
      custom USB vendor ID and product ID. Channel A is used for JTAG, and
      channel B is used for a UART.
      Signed-off-by: default avatarDoug Brown <doug@schmorgal.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8f44c909
    • Song Hongyan's avatar
      iio: hid-sensors: Increase the precision of scale to fix wrong reading interpretation. · 274b874d
      Song Hongyan authored
      commit 6f77199e upstream.
      
      While testing, it was observed that on some platforms the scale value
      from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results
      in the final angular velocity component values to be zeros.
      
      This is caused by insufficient precision of scale value displayed in sysfs.
      If the precision is changed to nano from current micro, then this is
      sufficient to display the scale value on this platform.
      Since this can be a problem for all other HID sensors, increase scale
      precision of all HID sensors to nano from current micro.
      
      Results on Yoga 260:
      
      name		scale before	scale now
      --------------------------------------------
      gyro_3d		0.000000	0.000000174
      als			0.001000	0.001000000
      magn_3d		0.000001	0.000001000
      accel_3d		0.000009	0.000009806
      Signed-off-by: default avatarSong Hongyan <hongyan.song@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      274b874d
    • Sachin Kamat's avatar
      iio: hid-sensors: Fix compilation warning · 0f1ce2b9
      Sachin Kamat authored
      commit a0342342 upstream.
      
      Move the 'static' keyword to beginning of definition to silence the
      following compilation warning:
      drivers/iio/common/hid-sensors/hid-sensor-attributes.c:34:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]
      Signed-off-by: default avatarSachin Kamat <sachin.kamat@samsung.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0f1ce2b9
    • Vladimir Zapolskiy's avatar
      i2c: core: fix NULL pointer dereference under race condition · d776b038
      Vladimir Zapolskiy authored
      commit 147b36d5 upstream.
      
      Race condition between registering an I2C device driver and
      deregistering an I2C adapter device which is assumed to manage that
      I2C device may lead to a NULL pointer dereference due to the
      uninitialized list head of driver clients.
      
      The root cause of the issue is that the I2C bus may know about the
      registered device driver and thus it is matched by bus_for_each_drv(),
      but the list of clients is not initialized and commonly it is NULL,
      because I2C device drivers define struct i2c_driver as static and
      clients field is expected to be initialized by I2C core:
      
        i2c_register_driver()             i2c_del_adapter()
          driver_register()                 ...
            bus_add_driver()                ...
              ...                           bus_for_each_drv(..., __process_removed_adapter)
            ...                               i2c_do_del_adapter()
          ...                                   list_for_each_entry_safe(..., &driver->clients, ...)
          INIT_LIST_HEAD(&driver->clients);
      
      To solve the problem it is sufficient to do clients list head
      initialization before calling driver_register().
      
      The problem was found while using an I2C device driver with a sluggish
      registration routine on a bus provided by a physically detachable I2C
      master controller, but practically the oops may be reproduced under
      the race between arbitraty I2C device driver registration and managing
      I2C bus device removal e.g. by unbinding the latter over sysfs:
      
      % echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
        Unable to handle kernel NULL pointer dereference at virtual address 00000000
        Internal error: Oops: 17 [#1] SMP ARM
        CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
        Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
        task: e5ada400 task.stack: e4936000
        PC is at i2c_do_del_adapter+0x20/0xcc
        LR is at __process_removed_adapter+0x14/0x1c
        Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
        Control: 10c5387d  Table: 35bd004a  DAC: 00000051
        Process sh (pid: 533, stack limit = 0xe4936210)
        Stack: (0xe4937d28 to 0xe4938000)
        Backtrace:
        [<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
        [<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
        [<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
        [<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
        [<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
        [<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
        [<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
        [<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
        [<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
        [<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
        [<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
        [<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
        [<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
        [<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
        [<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
      Signed-off-by: default avatarVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d776b038
    • Lance Richardson's avatar
      ipv4: allow local fragmentation in ip_finish_output_gso() · 62ac9322
      Lance Richardson authored
      commit 9ee6c5dc upstream.
      
      Some configurations (e.g. geneve interface with default
      MTU of 1500 over an ethernet interface with 1500 MTU) result
      in the transmission of packets that exceed the configured MTU.
      While this should be considered to be a "bad" configuration,
      it is still allowed and should not result in the sending
      of packets that exceed the configured MTU.
      
      Fix by dropping the assumption in ip_finish_output_gso() that
      locally originated gso packets will never need fragmentation.
      Basic testing using iperf (observing CPU usage and bandwidth)
      have shown no measurable performance impact for traffic not
      requiring fragmentation.
      
      Fixes: c7ba65d7 ("net: ip: push gso skb forwarding handling down the stack")
      Reported-by: default avatarJan Tluka <jtluka@redhat.com>
      Signed-off-by: default avatarLance Richardson <lrichard@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: never had the IPSKB_FRAG_SEGS flag]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      62ac9322
    • Oliver Neukum's avatar
      HID: usbhid: add ATEN CS962 to list of quirky devices · 32aa5c99
      Oliver Neukum authored
      commit cf0ea4da upstream.
      
      Like many similar devices it needs a quirk to work.
      Issuing the request gets the device into an irrecoverable state.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      32aa5c99
    • Laura Abbott's avatar
      HID: usbhid: Add HID_QUIRK_NOGET for Aten DVI KVM switch · 2e863ced
      Laura Abbott authored
      commit 849eca7b upstream.
      
      Like other KVM switches, the Aten DVI KVM switch needs a quirk to avoid spewing
      errors:
      
      [791759.606542] usb 1-5.4: input irq status -75 received
      [791759.614537] usb 1-5.4: input irq status -75 received
      [791759.622542] usb 1-5.4: input irq status -75 received
      
      Add it.
      Signed-off-by: default avatarLaura Abbott <labbott@fedoraproject.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2e863ced
    • Stefan Richter's avatar
      firewire: net: fix fragmented datagram_size off-by-one · f31d4542
      Stefan Richter authored
      commit e9300a4b upstream.
      
      RFC 2734 defines the datagram_size field in fragment encapsulation
      headers thus:
      
          datagram_size:  The encoded size of the entire IP datagram.  The
          value of datagram_size [...] SHALL be one less than the value of
          Total Length in the datagram's IP header (see STD 5, RFC 791).
      
      Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
      this field with a -/+1 offset:
      
          ether1394_tx() /* transmit */
              ether1394_encapsulate_prep()
                  hdr->ff.dg_size = dg_size - 1;
      
          ether1394_data_handler() /* receive */
              if (hdr->common.lf == ETH1394_HDR_LF_FF)
                  dg_size = hdr->ff.dg_size + 1;
              else
                  dg_size = hdr->sf.dg_size + 1;
      
      Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
      byte sized datagrams in fragments with datagram_size=1499 if link
      fragmentation is required.
      
      Only firewire-net sets and gets datagram_size without this offset.  The
      result is lacking interoperability of firewire-net with OS X, Windows
      XP, and presumably Linux' eth1394.  (I did not test with the latter.)
      For example, FTP data transfers to a Linux firewire-net box with max_rec
      smaller than the 1500 bytes MTU
        - from OS X fail entirely,
        - from Win XP start out with a bunch of fragmented datagrams which
          time out, then continue with unfragmented datagrams because Win XP
          temporarily reduces the MTU to 576 bytes.
      
      So let's fix firewire-net's datagram_size accessors.
      
      Note that firewire-net thereby loses interoperability with unpatched
      firewire-net, but only if link fragmentation is employed.  (This happens
      with large broadcast datagrams, and with large datagrams on several
      FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
      and it can be worked around by setting a small enough MTU.)
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f31d4542
    • John David Anglin's avatar
      parisc: Ensure consistent state when switching to kernel stack at syscall entry · 176ae640
      John David Anglin authored
      commit 6ed51832 upstream.
      
      We have one critical section in the syscall entry path in which we switch from
      the userspace stack to kernel stack. In the event of an external interrupt, the
      interrupt code distinguishes between those two states by analyzing the value of
      sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
      the value of sr7 is in sync with the currently enabled stack.
      
      This patch now disables interrupts while executing the critical section.  This
      prevents the interrupt handler to possibly see an inconsistent state which in
      the worst case can lead to crashes.
      
      Interestingly, in the syscall exit path interrupts were already disabled in the
      critical section which switches back to the userspace stack.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      176ae640
    • Eli Cooper's avatar
      ip6_tunnel: Clear IP6CB in ip6tunnel_xmit() · 9cc90663
      Eli Cooper authored
      commit 23f4ffed upstream.
      
      skb->cb may contain data from previous layers. In the observed scenario,
      the garbage data were misinterpreted as IP6CB(skb)->frag_max_size, so
      that small packets sent through the tunnel are mistakenly fragmented.
      
      This patch unconditionally clears the control buffer in ip6tunnel_xmit(),
      which affects ip6_tunnel, ip6_udp_tunnel and ip6_gre. Currently none of
      these tunnels set IP6CB(skb)->flags, otherwise it needs to be done earlier.
      Signed-off-by: default avatarEli Cooper <elicooper@gmx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9cc90663
    • Johan Hovold's avatar
      PM / sleep: fix device reference leak in test_suspend · e5eb6913
      Johan Hovold authored
      commit ceb75787 upstream.
      
      Make sure to drop the reference taken by class_find_device() after
      opening the RTC device.
      
      Fixes: 77437fd4 (pm: boot time suspend selftest)
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e5eb6913
    • Jason Gunthorpe's avatar
      gpio/mvebu: Use irq_domain_add_linear · f0cde548
      Jason Gunthorpe authored
      commit 812d4788 upstream.
      
      This fixes the irq allocation in this driver to not print:
       irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
       irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
      
      Which happens because the driver already called irq_alloc_descs()
      and so the change to use irq_domain_add_simple resulted in calling
      irq_alloc_descs() twice.
      
      Modernize the irq allocation in this driver to use the
      irq_domain_add_linear flow directly and eliminate the use of
      irq_domain_add_simple/legacy
      
      Fixes: ce931f57 ("gpio/mvebu: convert to use irq_domain_add_simple()")
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [bwh: Backported to 3.16:
       - Keep using irq_set_handler_data(), irq_set_chained_handler()
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f0cde548
    • Johan Hovold's avatar
      uwb: fix device reference leaks · 754c3cd7
      Johan Hovold authored
      commit d6124b40 upstream.
      
      This subsystem consistently fails to drop the device reference taken by
      class_find_device().
      
      Note that some of these lookup functions already take a reference to the
      returned data, while others claim no reference is needed (or does not
      seem need one).
      
      Fixes: 183b9b59 ("uwb: add the UWB stack (core files)")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      754c3cd7
    • Felipe Balbi's avatar
      usb: gadget: u_ether: remove interrupt throttling · 60811cdb
      Felipe Balbi authored
      commit fd9afd3c upstream.
      
      According to Dave Miller "the networking stack has a
      hard requirement that all SKBs which are transmitted
      must have their completion signalled in a fininte
      amount of time. This is because, until the SKB is
      freed by the driver, it holds onto socket,
      netfilter, and other subsystem resources."
      
      In summary, this means that using TX IRQ throttling
      for the networking gadgets is, at least, complex and
      we should avoid it for the time being.
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Suggested-by: default avatarDavid Miller <davem@davemloft.net>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      [bwh: Backported to 3.16: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      60811cdb
    • Andy Gospodarek's avatar
      bgmac: stop clearing DMA receive control register right after it is set · 50ef5ffe
      Andy Gospodarek authored
      commit fcdefcca upstream.
      
      Current bgmac code initializes some DMA settings in the receive control
      register for some hardware and then immediately clears those settings.
      Not clearing those settings results in ~420Mbps *improvement* in
      throughput; this system can now receive frames at line-rate on Broadcom
      5871x hardware compared to ~520Mbps today.  I also tested a few other
      values but found there to be no discernible difference in CPU
      utilization even if burst size and prefetching values are different.
      
      On the hardware tested there was no need to keep the code that cleared
      all but bits 16-17, but since there is a wide variety of hardware that
      used this driver (I did not look at all hardware docs for hardware using
      this IP block), I find it wise to move this call up and clear bits just
      after reading the default value from the hardware rather than completely
      removing it.
      
      This is a good candidate for -stable >=3.14 since that is when the code
      that was supposed to improve performance (but did not) was introduced.
      Signed-off-by: default avatarAndy Gospodarek <gospo@broadcom.com>
      Fixes: 56ceecde ("bgmac: initialize the DMA controller of core...")
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Acked-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      50ef5ffe
    • Oliver Hartkopp's avatar
      can: bcm: fix warning in bcm_connect/proc_register · c3f5d449
      Oliver Hartkopp authored
      commit deb507f9 upstream.
      
      Andrey Konovalov reported an issue with proc_register in bcm.c.
      As suggested by Cong Wang this patch adds a lock_sock() protection and
      a check for unsuccessful proc_create_data() in bcm_connect().
      
      Reference: http://marc.info/?l=linux-netdev&m=147732648731237Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Suggested-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c3f5d449
    • Jakub Sitnicki's avatar
      ipv6: Don't use ufo handling on later transformed packets · 3b805031
      Jakub Sitnicki authored
      commit f89c56ce upstream.
      
      Similar to commit c146066a ("ipv4: Don't use ufo handling on later
      transformed packets"), don't perform UFO on packets that will be IPsec
      transformed. To detect it we rely on the fact that headerlen in
      dst_entry is non-zero only for transformation bundles (xfrm_dst
      objects).
      
      Unwanted segmentation can be observed with a NETIF_F_UFO capable device,
      such as a dummy device:
      
        DEV=dum0 LEN=1493
      
        ip li add $DEV type dummy
        ip addr add fc00::1/64 dev $DEV nodad
        ip link set $DEV up
        ip xfrm policy add dir out src fc00::1 dst fc00::2 \
           tmpl src fc00::1 dst fc00::2 proto esp spi 1
        ip xfrm state add src fc00::1 dst fc00::2 \
           proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
      
        tcpdump -n -nn -i $DEV -t &
        socat /dev/zero,readbytes=$LEN udp6:[fc00::2]:$LEN
      
      tcpdump output before:
      
        IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
        IP6 fc00::1 > fc00::2: frag (1448|48)
        IP6 fc00::1 > fc00::2: ESP(spi=0x00000001,seq=0x2), length 88
      
      ... and after:
      
        IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
        IP6 fc00::1 > fc00::2: frag (1448|80)
      
      Fixes: e89e9cf5 ("[IPv4/IPv6]: UFO Scatter-gather approach")
      Signed-off-by: default avatarJakub Sitnicki <jkbs@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3b805031
    • Alexander Usyskin's avatar
      mei: bus: fix received data size check in NFC fixup · ad6dcc78
      Alexander Usyskin authored
      commit 582ab27a upstream.
      
      NFC version reply size checked against only header size, not against
      full message size. That may lead potentially to uninitialized memory access
      in version data.
      
      That leads to warnings when version data is accessed:
      drivers/misc/mei/bus-fixup.c: warning: '*((void *)&ver+11)' may be used uninitialized in this function [-Wuninitialized]:  => 212:2
      
      Reported in
      Build regressions/improvements in v4.9-rc3
      https://lkml.org/lkml/2016/10/30/57
      
      Fixes: 59fcd7c6 (mei: nfc: Initial nfc implementation)
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.16:
       - Drop change in mei_phy.c
       - Adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ad6dcc78
    • Liping Zhang's avatar
      netfilter: nf_tables: destroy the set if fail to add transaction · 6ca68d95
      Liping Zhang authored
      commit c17c3cdf upstream.
      
      When the memory is exhausted, then we will fail to add the NFT_MSG_NEWSET
      transaction. In such case, we should destroy the set before we free it.
      
      Fixes: 958bee14 ("netfilter: nf_tables: use new transaction infrastructure to handle sets")
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6ca68d95
    • Matt Redfearn's avatar
      virtio: console: Unlock vqs while freeing buffers · 36da5ca7
      Matt Redfearn authored
      commit 34563769 upstream.
      
      Commit c6017e79 ("virtio: console: add locks around buffer removal
      in port unplug path") added locking around the freeing of buffers in the
      vq. However, when free_buf() is called with can_sleep = true and rproc
      is enabled, it calls dma_free_coherent() directly, requiring interrupts
      to be enabled. Currently a WARNING is triggered due to the spin locking
      around free_buf, with a call stack like this:
      
      WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
      free_buf+0x1a8/0x288
      Call Trace:
      [<8040c538>] show_stack+0x74/0xc0
      [<80757240>] dump_stack+0xd0/0x110
      [<80430d98>] __warn+0xfc/0x130
      [<80430ee0>] warn_slowpath_null+0x2c/0x3c
      [<807e7c6c>] free_buf+0x1a8/0x288
      [<807ea590>] remove_port_data+0x50/0xac
      [<807ea6a0>] unplug_port+0xb4/0x1bc
      [<807ea858>] virtcons_remove+0xb0/0xfc
      [<807b6734>] virtio_dev_remove+0x58/0xc0
      [<807f918c>] __device_release_driver+0xac/0x134
      [<807f924c>] device_release_driver+0x38/0x50
      [<807f7edc>] bus_remove_device+0xfc/0x130
      [<807f4b74>] device_del+0x17c/0x21c
      [<807f4c38>] device_unregister+0x24/0x38
      [<807b6b50>] unregister_virtio_device+0x28/0x44
      
      Fix this by restructuring the loops to allow the locks to only be taken
      where it is necessary to protect the vqs, and release it while the
      buffer is being freed.
      
      Fixes: c6017e79 ("virtio: console: add locks around buffer removal in port unplug path")
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      36da5ca7
    • Ashok Raj's avatar
      iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions · a6cc3575
      Ashok Raj authored
      commit 1c387188 upstream.
      
      The VT-d specification (§8.3.3) says:
          ‘Virtual Functions’ of a ‘Physical Function’ are under the scope
          of the same remapping unit as the ‘Physical Function’.
      
      The BIOS is not required to list all the possible VFs in the scope
      tables, and arguably *shouldn't* make any attempt to do so, since there
      could be a huge number of them.
      
      This has been broken basically for ever — the VF is never going to match
      against a specific unit's scope, so it ends up being assigned to the
      INCLUDE_ALL IOMMU. Which was always actually correct by coincidence, but
      now we're looking at Root-Complex integrated devices with SR-IOV support
      it's going to start being wrong.
      
      Fix it to simply use pci_physfn() before doing the lookup for PCI devices.
      Signed-off-by: default avatarSainath Grandhi <sainath.grandhi@intel.com>
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a6cc3575
    • Boris Brezillon's avatar
      m68k: Fix ndelay() macro · 37332b5b
      Boris Brezillon authored
      commit 7e251bb2 upstream.
      
      The current ndelay() macro definition has an extra semi-colon at the
      end of the line thus leading to a compilation error when ndelay is used
      in a conditional block without curly braces like this one:
      
      	if (cond)
      		ndelay(t);
      	else
      		...
      
      which, after the preprocessor pass gives:
      
      	if (cond)
      		m68k_ndelay(t);;
      	else
      		...
      
      thus leading to the following gcc error:
      
      	error: 'else' without a previous 'if'
      
      Remove this extra semi-colon.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Fixes: c8ee038b ("m68k: Implement ndelay() based on the existing udelay() logic")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      37332b5b
    • Jack Morgenstein's avatar
      net/mlx4_en: Fix potential deadlock in port statistics flow · e5f9f9b4
      Jack Morgenstein authored
      commit d2582a03 upstream.
      
      mlx4_en_DUMP_ETH_STATS took the *counter mutex* and then
      called the FW command, with WRAPPED attribute. As a result, the fw command
      is wrapped on the Hypervisor when it calls mlx4_en_DUMP_ETH_STATS.
      The FW command wrapper flow on the hypervisor takes the *slave_cmd_mutex*
      during processing.
      
      At the same time, a VF could be in the process of coming up, and could
      call mlx4_QUERY_FUNC_CAP.  On the hypervisor, the command flow takes the
      *slave_cmd_mutex*, then executes mlx4_QUERY_FUNC_CAP_wrapper.
      mlx4_QUERY_FUNC_CAP wrapper calls mlx4_get_default_counter_index(),
      which takes the *counter mutex*. DEADLOCK.
      
      The fix is that the DUMP_ETH_STATS fw command should be called with
      the NATIVE attribute, so that on the hypervisor, this command does not
      enter the wrapper flow.
      
      Since the Hypervisor no longer goes through the wrapper code, we also
      simply return 0 in mlx4_DUMP_ETH_STATS_wrapper (i.e.the function succeeds,
      but the returned data will be all zeroes).
      No need to test if it is the Hypervisor going through the wrapper.
      
      Fixes: f9baff50 ("mlx4_core: Add "native" argument to mlx4_cmd ...")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: mlx4_en_DUMP_ETH_STATS() only uses this command once]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e5f9f9b4
    • Erez Shitrit's avatar
      net/mlx4_en: Process all completions in RX rings after port goes up · 301dc03b
      Erez Shitrit authored
      commit 8d59de8f upstream.
      
      Currently there is a race between incoming traffic and
      initialization flow. HW is able to receive the packets
      after INIT_PORT is done and unicast steering is configured.
      Before we set priv->port_up NAPI is not scheduled and
      receive queues become full. Therefore we never get
      new interrupts about the completions.
      This issue could happen if running heavy traffic during
      bringing port up.
      The resolution is to schedule NAPI once port_up is set.
      If receive queues were full this will process all cqes
      and release them.
      
      Fixes: c27a02cd ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC")
      Signed-off-by: default avatarErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: default avatarEugenia Emantayev <eugenia@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      301dc03b
    • Eugenia Emantayev's avatar
      net/mlx4_en: Resolve dividing by zero in 32-bit system · 1cdb21d7
      Eugenia Emantayev authored
      commit 4850cf45 upstream.
      
      When doing roundup_pow_of_two for large enough number with
      bit 31, an overflow will occur and a value equal to 1 will
      be returned. In this case 1 will be subtracted from the return
      value and division by zero will be reached.
      
      Fixes: 31c128b6 ("net/mlx4_en: Choose time-stamping shift value according to HW frequency")
      Signed-off-by: default avatarEugenia Emantayev <eugenia@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1cdb21d7
    • Jack Morgenstein's avatar
      net/mlx4_core: Fix the resource-type enum in res tracker to conform to FW spec · d0e5f130
      Jack Morgenstein authored
      commit aa0c08fe upstream.
      
      The resource type enum in the resource tracker was incorrect.
      RES_EQ was put in the position of RES_NPORT_ID (a FC resource).
      
      Since the remaining resources maintain their current values,
      and RES_EQ is not passed from slaves to the hypervisor in any
      FW command, this change affects only the hypervisor.
      Therefore, there is no backwards-compatibility issue.
      
      Fixes: 623ed84b ("mlx4_core: initial header-file changes for SRIOV support")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d0e5f130
    • Willem de Bruijn's avatar
      packet: on direct_xmit, limit tso and csum to supported devices · a920cb0d
      Willem de Bruijn authored
      commit 104ba78c upstream.
      
      When transmitting on a packet socket with PACKET_VNET_HDR and
      PACKET_QDISC_BYPASS, validate device support for features requested
      in vnet_hdr.
      
      Drop TSO packets sent to devices that do not support TSO or have the
      feature disabled. Note that the latter currently do process those
      packets correctly, regardless of not advertising the feature.
      
      Because of SKB_GSO_DODGY, it is not sufficient to test device features
      with netif_needs_gso. Full validate_xmit_skb is needed.
      
      Switch to software checksum for non-TSO packets that request checksum
      offload if that device feature is unsupported or disabled. Note that
      similar to the TSO case, device drivers may perform checksum offload
      correctly even when not advertising it.
      
      When switching to software checksum, packets hit skb_checksum_help,
      which has two BUG_ON checksum not in linear segment. Packet sockets
      always allocate at least up to csum_start + csum_off + 2 as linear.
      
      Tested by running github.com/wdebruij/kerneltools/psock_txring_vnet.c
      
        ethtool -K eth0 tso off tx on
        psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v
        psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v -N
      
        ethtool -K eth0 tx off
        psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G
        psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G -N
      
      v2:
        - add EXPORT_SYMBOL_GPL(validate_xmit_skb_list)
      
      Fixes: d346a3fa ("packet: introduce PACKET_QDISC_BYPASS socket option")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: open-code the necessary checks as we don't have
       validate_xmit_skb_list()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a920cb0d
    • Noa Osherovich's avatar
      net/mlx5: Avoid passing dma address 0 to firmware · e03e406c
      Noa Osherovich authored
      commit 6b276190 upstream.
      
      Currently the firmware can't work with a page with dma address 0.
      Passing such an address to the firmware will cause the give_pages
      command to fail.
      
      To avoid this, in case we get a 0 dma address of a page from the
      dma engine, we avoid passing it to FW by remapping to get an address
      other than 0.
      
      Fixes: bf0bf77f ('mlx5: Support communicating arbitrary host...')
      Signed-off-by: default avatarNoa Osherovich <noaos@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e03e406c
    • NeilBrown's avatar
      md: be careful not lot leak internal curr_resync value into metadata. -- (all) · d1f472da
      NeilBrown authored
      commit 1217e1d1 upstream.
      
      mddev->curr_resync usually records where the current resync is up to,
      but during the starting phase it has some "magic" values.
      
       1 - means that the array is trying to start a resync, but has yielded
           to another array which shares physical devices, and also needs to
           start a resync
       2 - means the array is trying to start resync, but has found another
           array which shares physical devices and has already started resync.
      
       3 - means that resync has commensed, but it is possible that nothing
           has actually been resynced yet.
      
      It is important that this value not be visible to user-space and
      particularly that it doesn't get written to the metadata, as the
      resync or recovery checkpoint.  In part, this is because it may be
      slightly higher than the correct value, though this is very rare.
      In part, because it is not a multiple of 4K, and some devices only
      support 4K aligned accesses.
      
      There are two places where this value is propagates into either
      ->curr_resync_completed or ->recovery_cp or ->recovery_offset.
      These currently avoid the propagation of values 1 and 3, but will
      allow 3 to leak through.
      
      Change them to only propagate the value if it is > 3.
      
      As this can cause an array to fail, the patch is suitable for -stable.
      Reported-by: default avatarViswesh <viswesh.vichu@gmail.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      [bwh: Backported to 3.16: there is only one comparison to fix]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d1f472da
    • Richard Weinberger's avatar
      ubifs: Fix regression in ubifs_readdir() · dba8e88e
      Richard Weinberger authored
      commit a00052a2 upstream.
      
      Commit c83ed4c9 ("ubifs: Abort readdir upon error") broke
      overlayfs support because the fix exposed an internal error
      code to VFS.
      Reported-by: default avatarPeter Rosin <peda@axentia.se>
      Tested-by: default avatarPeter Rosin <peda@axentia.se>
      Reported-by: default avatarRalph Sennhauser <ralph.sennhauser@gmail.com>
      Tested-by: default avatarRalph Sennhauser <ralph.sennhauser@gmail.com>
      Fixes: c83ed4c9 ("ubifs: Abort readdir upon error")
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dba8e88e
    • Gerald Schaefer's avatar
      GenWQE: Fix bad page access during abort of resource allocation · 192d5e7c
      Gerald Schaefer authored
      commit a7a7aeef upstream.
      
      When interrupting an application which was allocating DMAable
      memory, it was possible, that the DMA memory was deallocated
      twice, leading to the error symptoms below.
      
      Thanks to Gerald, who analyzed the problem and provided this
      patch.
      
      I agree with his analysis of the problem: ddcb_cmd_fixups() ->
      genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL
      and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() ->
      genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and
      f/lpage maybe also != NULL)
      
      In this scenario we would have exactly the kind of double free that
      would explain the WARNING / Bad page state, and as expected it is
      caused by broken error handling (cleanup).
      
      Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce
      the "Bad page state" issue, and with the patch on top he could not reproduce
      it any more.
      
      ------------[ cut here ]------------
      WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141
      Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod
      CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu
      task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000
      Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
      Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400
                 0000000000000400 0000000000001fff 0000000000000400 0000000116853000
                 07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001
                 0000000000001000 0000000116854000 0000000000156402 00000000324e7a38
      Krnl Code: 000000000015633a: 95001000           cli     0(%r1),0
                 000000000015633e: a774ffc3           brc     7,1562c4
                #0000000000156342: a7f40001           brc     15,156344
                >0000000000156346: 92011000           mvi     0(%r1),1
                 000000000015634a: a7f4ffbd           brc     15,1562c4
                 000000000015634e: 0707               bcr     0,%r7
                 0000000000156350: c00400000000       brcl    0,156350
                 0000000000156356: eb7ff0500024       stmg    %r7,%r15,80(%r15)
      Call Trace:
      ([<00000000001563e0>] dma_update_trans+0x90/0x228)
       [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160
       [<00000000001567c2>] s390_dma_free+0x62/0x98
       [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card]
       [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card]
       [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card]
       [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card]
       [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card]
       [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518
       [<0000000000325344>] SyS_ioctl+0xa4/0xb8
       [<00000000007b86c6>] system_call+0xd6/0x264
       [<000003ff9e8e520a>] 0x3ff9e8e520a
      Last Breaking-Event-Address:
       [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8
      ---[ end trace 35996336235145c8 ]---
      BUG: Bad page state in process jbd2/dasdb1-8  pfn:3215b
      page:000003d100c856c0 count:-1 mapcount:0 mapping:          (null) index:0x0
      flags: 0x3fffc0000000000()
      page dumped because: nonzero _count
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarFrank Haverkamp <haver@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      192d5e7c
    • Ido Yariv's avatar
      KVM: x86: fix wbinvd_dirty_mask use-after-free · 9ba74d1a
      Ido Yariv authored
      commit bd768e14 upstream.
      
      vcpu->arch.wbinvd_dirty_mask may still be used after freeing it,
      corrupting memory. For example, the following call trace may set a bit
      in an already freed cpu mask:
          kvm_arch_vcpu_load
          vcpu_load
          vmx_free_vcpu_nested
          vmx_free_vcpu
          kvm_arch_vcpu_free
      
      Fix this by deferring freeing of wbinvd_dirty_mask.
      Signed-off-by: default avatarIdo Yariv <ido@wizery.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9ba74d1a
    • Michael Holzheu's avatar
      s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment · b31d60e1
      Michael Holzheu authored
      commit 237d6e68 upstream.
      
      Since commit d86bd1be ("mm/slub: support left redzone") it is no longer
      guaranteed that kmalloc(PAGE_SIZE) returns page aligned memory.
      
      After the above commit we get an error for diag224 because aligned
      memory is required. This leads to the following user visible error:
      
       # mount none -t s390_hypfs /sys/hypervisor/
       mount: unknown filesystem type 's390_hypfs'
      
       # dmesg | grep hypfs
       hypfs.cccfb8: The hardware system does not provide all functions
                     required by hypfs
       hypfs.7a79f0: Initialization of hypfs failed with rc=-61
      
      Fix this problem and use get_free_page() instead of kmalloc() to get
      correctly aligned memory.
      Signed-off-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b31d60e1
    • Daniel Mentz's avatar
      lib/genalloc.c: start search from start of chunk · 2c1a5759
      Daniel Mentz authored
      commit 62e931fa upstream.
      
      gen_pool_alloc_algo() iterates over the chunks of a pool trying to find
      a contiguous block of memory that satisfies the allocation request.
      
      The shortcut
      
      	if (size > atomic_read(&chunk->avail))
      		continue;
      
      makes the loop skip over chunks that do not have enough bytes left to
      fulfill the request.  There are two situations, though, where an
      allocation might still fail:
      
      (1) The available memory is not contiguous, i.e.  the request cannot
          be fulfilled due to external fragmentation.
      
      (2) A race condition.  Another thread runs the same code concurrently
          and is quicker to grab the available memory.
      
      In those situations, the loop calls pool->algo() to search the entire
      chunk, and pool->algo() returns some value that is >= end_bit to
      indicate that the search failed.  This return value is then assigned to
      start_bit.  The variables start_bit and end_bit describe the range that
      should be searched, and this range should be reset for every chunk that
      is searched.  Today, the code fails to reset start_bit to 0.  As a
      result, prefixes of subsequent chunks are ignored.  Memory allocations
      might fail even though there is plenty of room left in these prefixes of
      those other chunks.
      
      Fixes: 7f184275 ("lib, Make gen_pool memory allocator lockless")
      Link: http://lkml.kernel.org/r/1477420604-28918-1-git-send-email-danielmentz@google.comSigned-off-by: default avatarDaniel Mentz <danielmentz@google.com>
      Reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2c1a5759
    • Chris Mason's avatar
      btrfs: fix races on root_log_ctx lists · f86f1bbd
      Chris Mason authored
      commit 570dd450 upstream.
      
      btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the
      list because it knows all of the waiters are patiently waiting for the
      commit to finish.
      
      But, there's a small race where btrfs_sync_log can remove itself from
      the list if it finds a log commit is already done.  Also, it uses
      list_del_init() to remove itself from the list, but there's no way to
      know if btrfs_remove_all_log_ctxs has already run, so we don't know for
      sure if it is safe to call list_del_init().
      
      This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and
      just calls it with the proper locking.
      
      This is part two of the corruption fixed by cbd60aa7.  I should have
      done this in the first place, but convinced myself the optimizations were
      safe.  A 12 hour run of dbench 2048 will eventually trigger a list debug
      WARN_ON for the list_del_init() in btrfs_sync_log().
      
      Fixes: d1433debReported-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f86f1bbd
    • John W. Linville's avatar
      netfilter: nf_tables: fix type mismatch with error return from nft_parse_u32_check · 768071f4
      John W. Linville authored
      commit f1d505bb upstream.
      
      Commit 36b701fa ("netfilter: nf_tables: validate maximum value of
      u32 netlink attributes") introduced nft_parse_u32_check with a return
      value of "unsigned int", yet on error it returns "-ERANGE".
      
      This patch corrects the mismatch by changing the return value to "int",
      which happens to match the actual users of nft_parse_u32_check already.
      
      Found by Coverity, CID 1373930.
      
      Note that commit 21a9e0f1 ("netfilter: nft_exthdr: fix error
      handling in nft_exthdr_init()) attempted to address the issue, but
      did not address the return type of nft_parse_u32_check.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Cc: Laura Garcia Liebana <nevola@gmail.com>
      Cc: Pablo Neira Ayuso <pablo@netfilter.org>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Fixes: 36b701fa ("netfilter: nf_tables: validate maximum value...")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      768071f4
    • Ulrich Weber's avatar
      netfilter: nf_conntrack_sip: extend request line validation · e01234be
      Ulrich Weber authored
      commit 444f9017 upstream.
      
      on SIP requests, so a fragmented TCP SIP packet from an allow header starting with
       INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
       Content-Length: 0
      
      will not bet interpreted as an INVITE request. Also Request-URI must start with an alphabetic character.
      
      Confirm with RFC 3261
       Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
      
      Fixes: 30f33e6d ("[NETFILTER]: nf_conntrack_sip: support method specific request/response handling")
      Signed-off-by: default avatarUlrich Weber <ulrich.weber@riverbed.com>
      Acked-by: default avatarMarco Angaroni <marcoangaroni@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e01234be
    • Scot Doyle's avatar
      vt: clear selection before resizing · dbc3fd44
      Scot Doyle authored
      commit 009e39ae upstream.
      
      When resizing a vt its selection may exceed the new size, resulting in
      an invalid memory access [1]. Clear the selection before resizing.
      
      [1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.comReported-and-tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarScot Doyle <lkml14@scotdoyle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dbc3fd44