1. 26 Aug, 2017 40 commits
    • Mikulas Patocka's avatar
      dm bufio: avoid a possible ABBA deadlock · 4171fcef
      Mikulas Patocka authored
      commit 1b0fb5a5 upstream.
      
      __get_memory_limit() tests if dm_bufio_cache_size changed and calls
      __cache_size_refresh() if it did.  It takes dm_bufio_clients_lock while
      it already holds the client lock.  However, lock ordering is violated
      because in cleanup_old_buffers() dm_bufio_clients_lock is taken before
      the client lock.
      
      This results in a possible deadlock and lockdep engine warning.
      
      Fix this deadlock by changing mutex_lock() to mutex_trylock().  If the
      lock can't be taken, it will be re-checked next time when a new buffer
      is allocated.
      
      Also add "unlikely" to the if condition, so that the optimizer assumes
      that the condition is false.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4171fcef
    • David S. Miller's avatar
      ipv6: Need to export ipv6_push_frag_opts for tunneling now. · 44fda124
      David S. Miller authored
      commit 5b8481fa upstream.
      
      Since that change also made the nfrag function not necessary
      for exports, remove it.
      
      Fixes: 89a23c8b ("ip6_tunnel: Fix missing tunnel encapsulation limit option")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: keep exporting ipv6_push_nfrag_opts(), needed by
       ip6_gre module]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      44fda124
    • Craig Gallek's avatar
      ip6_tunnel: Fix missing tunnel encapsulation limit option · c36e890c
      Craig Gallek authored
      commit 89a23c8b upstream.
      
      The IPv6 tunneling code tries to insert IPV6_TLV_TNL_ENCAP_LIMIT and
      IPV6_TLV_PADN options when an encapsulation limit is defined (the
      default is a limit of 4).  An MTU adjustment is done to account for
      these options as well.  However, the options are never present in the
      generated packets.
      
      The issue appears to be a subtlety between IPV6_DSTOPTS and
      IPV6_RTHDRDSTOPTS defined in RFC 3542.  When the IPIP tunnel driver was
      written, the encap limit options were included as IPV6_RTHDRDSTOPTS in
      dst0opt of struct ipv6_txoptions.  Later, ipv6_push_nfrags_opts was
      (correctly) updated to require IPV6_RTHDR options when IPV6_RTHDRDSTOPTS
      are to be used.  This caused the options to no longer be included in v6
      encapsulated packets.
      
      The fix is to use IPV6_DSTOPTS (in dst1opt of struct ipv6_txoptions)
      instead.  IPV6_DSTOPTS do not have the additional IPV6_RTHDR requirement.
      
      Fixes: 1df64a85: ("[IPV6]: Add ip6ip6 tunnel driver.")
      Fixes: 333fad53: ("[IPV6]: Support several new sockopt / ancillary data in Advanced API (RFC3542)")
      Signed-off-by: default avatarCraig Gallek <kraig@google.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>
      c36e890c
    • Sebastian Reichel's avatar
      Input: twl4030-pwrbutton - use correct device for irq request · e1a68716
      Sebastian Reichel authored
      commit 3071e9dd upstream.
      
      The interrupt should be requested for the platform device
      and not for the input device.
      
      Fixes: 7f9ce649 ("Input: twl4030-pwrbutton - simplify driver using devm_*")
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e1a68716
    • Michael Trimarchi's avatar
      power: supply: pda_power: move from timer to delayed_work · 8a450fa9
      Michael Trimarchi authored
      commit 633e8799 upstream.
      
      This changed is needed to avoid locking problem during
      boot as shown:
      
      <5>[    8.824096] Registering SWP/SWPB emulation handler
      <6>[    8.977294] clock: disabling unused clocks to save power
      <3>[    9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269
      <3>[    9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
      <4>[    9.130249] 3 locks held by swapper/0/1:
      <4>[    9.134613]  #0:  (&__lockdep_no_validate__){......}, at: [<c0342430>] __driver_attach+0x58/0xa8
      <4>[    9.144500]  #1:  (&__lockdep_no_validate__){......}, at: [<c0342440>] __driver_attach+0x68/0xa8
      <4>[    9.154357]  #2:  (&polling_timer){......}, at: [<c0053770>] run_timer_softirq+0x108/0x3ec
      <4>[    9.163726] Backtrace:
      <4>[    9.166473] [<c001269c>] (dump_backtrace+0x0/0x114) from [<c067e5f0>] (dump_stack+0x20/0x24)
      <4>[    9.175811]  r6:00203230 r5:0000010d r4:d782e000 r3:60000113
      <4>[    9.182250] [<c067e5d0>] (dump_stack+0x0/0x24) from [<c007441c>] (__might_sleep+0x10c/0x128)
      <4>[    9.191650] [<c0074310>] (__might_sleep+0x0/0x128) from [<c0688f60>] (mutex_lock_nested+0x34/0x36c)
      <4>[    9.201660]  r5:c02d5350 r4:d79a0c64
      <4>[    9.205688] [<c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<c02d5350>] (regulator_set_current_limit+0x30/0x118)
      <4>[    9.217071] [<c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<c0435ce0>] (update_charger+0x84/0xc4)
      <4>[    9.228027]  r7:d782fb20 r6:00000101 r5:c1767e94 r4:00000000
      <4>[    9.234436] [<c0435c5c>] (update_charger+0x0/0xc4) from [<c0435d40>] (psy_changed+0x20/0x48)
      <4>[    9.243804]  r5:d782e000 r4:c1767e94
      <4>[    9.247802] [<c0435d20>] (psy_changed+0x0/0x48) from [<c0435dec>] (polling_timer_func+0x84/0xb8)
      <4>[    9.257537]  r4:c1767e94 r3:00000002
      <4>[    9.261566] [<c0435d68>] (polling_timer_func+0x0/0xb8) from [<c00537e4>] (run_timer_softirq+0x17c/0x3ec)
      <4>[    9.272033]  r4:c1767eb0 r3:00000000
      <4>[    9.276062] [<c0053668>] (run_timer_softirq+0x0/0x3ec) from [<c004b000>] (__do_softirq+0xf0/0x298)
      <4>[    9.286010] [<c004af10>] (__do_softirq+0x0/0x298) from [<c004b650>] (irq_exit+0x98/0xa0)
      <4>[    9.295013] [<c004b5b8>] (irq_exit+0x0/0xa0) from [<c000edbc>] (handle_IRQ+0x60/0xc0)
      <4>[    9.303680]  r4:c1194e98 r3:c00bc778
      <4>[    9.307708] [<c000ed5c>] (handle_IRQ+0x0/0xc0) from [<c0008504>] (gic_handle_irq+0x34/0x68)
      <4>[    9.316955]  r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100
      <4>[    9.324310] r3:c026ba48
      <4>[    9.327301] [<c00084d0>] (gic_handle_irq+0x0/0x68) from [<c068c2c0>] (__irq_svc+0x40/0x74)
      <4>[    9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
      <4>[    9.342041] fc00:                   d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000
      <4>[    9.351104] fc20: beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50
      <4>[    9.360168] fc40: c026ba48 c001d1f0 00000113 ffffffff
      
      Fixes: b2998049 ("[BATTERY] pda_power platform driver")
      Signed-off-by: default avatarMichael Trimarchi <michael@amarulasolutions.com>
      Signed-off-by: default avatarAnthony Brandon <anthony@amarulasolutions.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8a450fa9
    • Pan Bian's avatar
      power: supply: isp1704: Fix unchecked return value of devm_kzalloc · df5a28b8
      Pan Bian authored
      commit 8b208399 upstream.
      
      Function devm_kzalloc() will return a NULL pointer. However, in function
      isp1704_charger_probe(), the return value of devm_kzalloc() is directly
      used without validation. This may result in a bad memory access bug.
      
      Fixes: 34a10961 ("isp1704_charger: Add DT support")
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Reviewed-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      df5a28b8
    • Szymon Janc's avatar
      Bluetooth: Fix user channel for 32bit userspace on 64bit kernel · 84a0a2ec
      Szymon Janc authored
      commit ab89f0bd upstream.
      
      Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
      defined as 0x80000000. This results in sendmsg failure if used from 32bit
      userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
      in flags check in hci_sock_sendmsg.
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Signed-off-by: default avatarMarko Kiiskila <marko@runtime.io>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      84a0a2ec
    • Christophe Leroy's avatar
      net: ethernet: ucc_geth: fix MEM_PART_MURAM mode · c4e387c8
      Christophe Leroy authored
      commit 8b8642af upstream.
      
      Since commit 5093bb96 ("powerpc/QE: switch to the cpm_muram
      implementation"), muram area is not part of immrbar mapping anymore
      so immrbar_virt_to_phys() is not usable anymore.
      
      Fixes: 5093bb96 ("powerpc/QE: switch to the cpm_muram implementation")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarLi Yang <pku.leo@gmail.com>
      Signed-off-by: default avatarScott Wood <oss@buserror.net>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c4e387c8
    • Eric Biggers's avatar
      ext4: evict inline data when writing to memory map · 59b4a049
      Eric Biggers authored
      commit 7b4cc978 upstream.
      
      Currently the case of writing via mmap to a file with inline data is not
      handled.  This is maybe a rare case since it requires a writable memory
      map of a very small file, but it is trivial to trigger with on
      inline_data filesystem, and it causes the
      'BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));' in
      ext4_writepages() to be hit:
      
          mkfs.ext4 -O inline_data /dev/vdb
          mount /dev/vdb /mnt
          xfs_io -f /mnt/file \
      	-c 'pwrite 0 1' \
      	-c 'mmap -w 0 1m' \
      	-c 'mwrite 0 1' \
      	-c 'fsync'
      
      	kernel BUG at fs/ext4/inode.c:2723!
      	invalid opcode: 0000 [#1] SMP
      	CPU: 1 PID: 2532 Comm: xfs_io Not tainted 4.11.0-rc1-xfstests-00301-g071d9acf3d1f #633
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
      	task: ffff88003d3a8040 task.stack: ffffc90000300000
      	RIP: 0010:ext4_writepages+0xc89/0xf8a
      	RSP: 0018:ffffc90000303ca0 EFLAGS: 00010283
      	RAX: 0000028410000000 RBX: ffff8800383fa3b0 RCX: ffffffff812afcdc
      	RDX: 00000a9d00000246 RSI: ffffffff81e660e0 RDI: 0000000000000246
      	RBP: ffffc90000303dc0 R08: 0000000000000002 R09: 869618e8f99b4fa5
      	R10: 00000000852287a2 R11: 00000000a03b49f4 R12: ffff88003808e698
      	R13: 0000000000000000 R14: 7fffffffffffffff R15: 7fffffffffffffff
      	FS:  00007fd3e53094c0(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 00007fd3e4c51000 CR3: 000000003d554000 CR4: 00000000003406e0
      	Call Trace:
      	 ? _raw_spin_unlock+0x27/0x2a
      	 ? kvm_clock_read+0x1e/0x20
      	 do_writepages+0x23/0x2c
      	 ? do_writepages+0x23/0x2c
      	 __filemap_fdatawrite_range+0x80/0x87
      	 filemap_write_and_wait_range+0x67/0x8c
      	 ext4_sync_file+0x20e/0x472
      	 vfs_fsync_range+0x8e/0x9f
      	 ? syscall_trace_enter+0x25b/0x2d0
      	 vfs_fsync+0x1c/0x1e
      	 do_fsync+0x31/0x4a
      	 SyS_fsync+0x10/0x14
      	 do_syscall_64+0x69/0x131
      	 entry_SYSCALL64_slow_path+0x25/0x25
      
      We could try to be smart and keep the inline data in this case, or at
      least support delayed allocation when allocating the block, but these
      solutions would be more complicated and don't seem worthwhile given how
      rare this case seems to be.  So just fix the bug by calling
      ext4_convert_inline_data() when we're asked to make a page writable, so
      that any inline data gets evicted, with the block allocated immediately.
      Reported-by: default avatarNick Alcock <nick.alcock@oracle.com>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      59b4a049
    • Christoph Hellwig's avatar
      libata: reject passthrough WRITE SAME requests · 0256d09d
      Christoph Hellwig authored
      commit c6ade20f upstream.
      
      The WRITE SAME to TRIM translation rewrites the DATA OUT buffer.  While
      the SCSI code accomodates for this by passing a read-writable buffer
      userspace applications don't cater for this behavior.  In fact it can
      be used to rewrite e.g. a readonly file through mmap and should be
      considered as a security fix.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      [bwh: Backported to 3.16:
       - Open-code blk_rq_is_passthrough()
       - We don't distinguish which field is invaid so goto invalid_fld
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0256d09d
    • Michael J. Ruhl's avatar
      IB/core: For multicast functions, verify that LIDs are multicast LIDs · ffbd148d
      Michael J. Ruhl authored
      commit 8561eae6 upstream.
      
      The Infiniband spec defines "A multicast address is defined by a
      MGID and a MLID" (section 10.5).  Currently the MLID value is not
      validated.
      
      Add check to verify that the MLID value is in the correct address
      range.
      
      Fixes: 0c33aeed ("[IB] Add checks to multicast attach and detach")
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Reviewed-by: default avatarDasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com>
      Signed-off-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.16: use literal number instead of IB_MULTICAST_LID_BASE]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ffbd148d
    • Michael J. Ruhl's avatar
      IB/core: If the MGID/MLID pair is not on the list return an error · 5a5271b4
      Michael J. Ruhl authored
      commit 20c7840a upstream.
      
      A list of MGID/MLID pairs is built when doing a multicast attach.  When
      the multicast detach is called, the list is searched, and regardless of
      the search outcome, the driver detach is called.
      
      If an MGID/MLID pair is not on the list, driver detach should not be
      called, and an error should be returned.  Calling the driver without
      removing an MGID/MLID pair from the list can leave the core and driver
      out of sync.
      
      Fixes: f4e40156 ("IB/uverbs: track multicast group membership for userspace QPs")
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5a5271b4
    • Johan Hovold's avatar
      staging: gdm724x: gdm_mux: fix use-after-free on module unload · e106f1b5
      Johan Hovold authored
      commit b58f45c8 upstream.
      
      Make sure to deregister the USB driver before releasing the tty driver
      to avoid use-after-free in the USB disconnect callback where the tty
      devices are deregistered.
      
      Fixes: 61e12104 ("staging: gdm7240: adding LTE USB driver")
      Cc: Won Kang <wkang77@gmail.com>
      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>
      e106f1b5
    • Amitoj Kaur Chawla's avatar
      staging: gdm724x: gdm_mux: Remove create_workqueue() · 88468b0d
      Amitoj Kaur Chawla authored
      commit c272dc2d upstream.
      
      With concurrency managed workqueues, use of dedicated workqueues
      can be replaced by using system_wq. Drop mux_rx_wq by using system_wq.
      
      Since there is only one work item per mux_dev and different mux_devs
      do not need to be ordered, increase of concurrency level by switching
      to system_wq should not break anything.
      
      cancel_work_sync() is used to ensure that work is not pending or
      executing on any CPU.
      
      Lastly, since all devices are suspended, which shutdowns the work item
      before the driver can be unregistered, it is guaranteed that no work
      item is pending or executing by the time exit path runs.
      Signed-off-by: default avatarAmitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      88468b0d
    • Dan Carpenter's avatar
      staging: rtl8188eu: prevent an underflow in rtw_check_beacon_data() · a61e93c5
      Dan Carpenter authored
      commit 784047eb upstream.
      
      The "len" could be as low as -14 so we should check for negatives.
      
      Fixes: 9a7fe54d ("staging: r8188eu: Add source files for new driver - part 1")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a61e93c5
    • Adrian Salido's avatar
      dm ioctl: prevent stack leak in dm ioctl call · aebe2f15
      Adrian Salido authored
      commit 4617f564 upstream.
      
      When calling a dm ioctl that doesn't process any data
      (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
      dm_ioctl are left initialized.  Current code is incorrectly extending
      the size of data copied back to user, causing the contents of kernel
      stack to be leaked to user.  Fix by only copying contents before data
      and allow the functions processing the ioctl to override.
      Signed-off-by: default avatarAdrian Salido <salidoa@google.com>
      Reviewed-by: default avatarAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      aebe2f15
    • Tony Lindgren's avatar
      mfd: omap-usb-tll: Fix inverted bit use for USB TLL mode · 356fab89
      Tony Lindgren authored
      commit 8b8a84c5 upstream.
      
      Commit 16fa3dc7 ("mfd: omap-usb-tll: HOST TLL platform driver")
      added support for USB TLL, but uses OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF
      bit the wrong way. The comments in the code are correct, but the inverted
      use of OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF causes the register to be
      enabled instead of disabled unlike what the comments say.
      
      Without this change the Wrigley 3G LTE modem on droid 4 EHCI bus can
      be only pinged few times before it stops responding.
      
      Fixes: 16fa3dc7 ("mfd: omap-usb-tll: HOST TLL platform driver")
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      356fab89
    • Maksim Salau's avatar
      usb: misc: legousbtower: Fix buffers on stack · 7c829ab1
      Maksim Salau authored
      commit 942a4873 upstream.
      
      Allocate buffers on HEAP instead of STACK for local structures
      that are to be received using usb_control_msg().
      Signed-off-by: default avatarMaksim Salau <maksim.salau@gmail.com>
      Tested-by: Alfredo Rafael Vicente Boix <alviboi@gmail.com>;
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7c829ab1
    • Andy Lutomirski's avatar
      x86/mm: Fix flush_tlb_page() on Xen · 1ae42286
      Andy Lutomirski authored
      commit dbd68d8e upstream.
      
      flush_tlb_page() passes a bogus range to flush_tlb_others() and
      expects the latter to fix it up.  native_flush_tlb_others() has the
      fixup but Xen's version doesn't.  Move the fixup to
      flush_tlb_others().
      
      AFAICS the only real effect is that, without this fix, Xen would
      flush everything instead of just the one page on remote vCPUs in
      when flush_tlb_page() was called.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Nadav Amit <namit@vmware.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: e7b52ffd ("x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range")
      Link: http://lkml.kernel.org/r/10ed0e4dfea64daef10b87fb85df1746999b4dba.1492844372.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.16: the special case was handled in flush_tlb_func(), not
       native_flush_tlb_others()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1ae42286
    • Alexey Brodkin's avatar
      usb: Make sure usb/phy/of gets built-in · 71bd0f49
      Alexey Brodkin authored
      commit 3d615964 upstream.
      
      DWC3 driver uses of_usb_get_phy_mode() which is
      implemented in drivers/usb/phy/of.c and in bare minimal
      configuration it might not be pulled in kernel binary.
      
      In case of ARC or ARM this could be easily reproduced with
      "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
      
      On building all ends-up with:
      ---------------------->8------------------
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Building modules, stage 2.
        MODPOST 5 modules
      ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
      make[1]: *** [__modpost] Error 1
      make: *** [modules] Error 2
      ---------------------->8------------------
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      71bd0f49
    • Amir Goldstein's avatar
      fanotify: don't expose EOPENSTALE to userspace · 3ea33dcc
      Amir Goldstein authored
      commit 4ff33aaf upstream.
      
      When delivering an event to userspace for a file on an NFS share,
      if the file is deleted on server side before user reads the event,
      user will not get the event.
      
      If the event queue contained several events, the stale event is
      quietly dropped and read() returns to user with events read so far
      in the buffer.
      
      If the event queue contains a single stale event or if the stale
      event is a permission event, read() returns to user with the kernel
      internal error code 518 (EOPENSTALE), which is not a POSIX error code.
      
      Check the internal return value -EOPENSTALE in fanotify_read(), just
      the same as it is checked in path_openat() and drop the event in the
      cases that it is not already dropped.
      
      This is a reproducer from Marko Rauhamaa:
      
      Just take the example program listed under "man fanotify" ("fantest")
      and follow these steps:
      
          ==============================================================
          NFS Server    NFS Client(1)     NFS Client(2)
          ==============================================================
          # echo foo >/nfsshare/bar.txt
                        # cat /nfsshare/bar.txt
                        foo
                                          # ./fantest /nfsshare
                                          Press enter key to terminate.
                                          Listening for events.
          # rm -f /nfsshare/bar.txt
                        # cat /nfsshare/bar.txt
                                          read: Unknown error 518
                        cat: /nfsshare/bar.txt: Operation not permitted
          ==============================================================
      
      where NFS Client (1) and (2) are two terminal sessions on a single NFS
      Client machine.
      Reported-by: default avatarMarko Rauhamaa <marko.rauhamaa@f-secure.com>
      Tested-by: default avatarMarko Rauhamaa <marko.rauhamaa@f-secure.com>
      Cc: <linux-api@vger.kernel.org>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3ea33dcc
    • Stefan Assmann's avatar
      PCI: Disable boot interrupt quirk for ASUS M2N-LR · 6ec3f14b
      Stefan Assmann authored
      commit c4e649b0 upstream.
      
      The ASUS M2N-LR should not trigger boot interrupt quirks although it
      carries an Intel 6702PXH.  On this board the boot interrupt quirks cause
      incorrect IRQ assignments and should be disabled.
      
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43074Tested-by: default avatarSolomon Peachy <pizza@shaftnet.org>
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6ec3f14b
    • Somasundaram Krishnasamy's avatar
      dm era: save spacemap metadata root after the pre-commit · b731d873
      Somasundaram Krishnasamy authored
      commit 117aceb0 upstream.
      
      When committing era metadata to disk, it doesn't always save the latest
      spacemap metadata root in superblock. Due to this, metadata is getting
      corrupted sometimes when reopening the device. The correct order of update
      should be, pre-commit (shadows spacemap root), save the spacemap root
      (newly shadowed block) to in-core superblock and then the final commit.
      Signed-off-by: default avatarSomasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b731d873
    • Vinothkumar Raja's avatar
      dm btree: fix for dm_btree_find_lowest_key() · 891d43b9
      Vinothkumar Raja authored
      commit 7d1fedb6 upstream.
      
      dm_btree_find_lowest_key() is giving incorrect results.  find_key()
      traverses the btree correctly for finding the highest key, but there is
      an error in the way it traverses the btree for retrieving the lowest
      key.  dm_btree_find_lowest_key() fetches the first key of the rightmost
      block of the btree instead of fetching the first key from the leftmost
      block.
      
      Fix this by conditionally passing the correct parameter to value64()
      based on the @find_highest flag.
      Signed-off-by: default avatarErez Zadok <ezk@fsl.cs.sunysb.edu>
      Signed-off-by: default avatarVinothkumar Raja <vinraja@cs.stonybrook.edu>
      Signed-off-by: default avatarNidhi Panpalia <npanpalia@cs.stonybrook.edu>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      891d43b9
    • Liping Zhang's avatar
      netfilter: ctnetlink: make it safer when updating ct->status · 00834185
      Liping Zhang authored
      commit 53b56da8 upstream.
      
      After converting to use rcu for conntrack hash, one CPU may update
      the ct->status via ctnetlink, while another CPU may process the
      packets and update the ct->status.
      
      So the non-atomic operation "ct->status |= status;" via ctnetlink
      becomes unsafe, and this may clear the IPS_DYING_BIT bit set by
      another CPU unexpectedly. For example:
               CPU0                            CPU1
        ctnetlink_change_status        __nf_conntrack_find_get
            old = ct->status              nf_ct_gc_expired
                -                         nf_ct_kill
                -                      test_and_set_bit(IPS_DYING_BIT
            new = old | status;                 -
        ct->status = new; <-- oops, _DYING_ is cleared!
      
      Now using a series of atomic bit operation to solve the above issue.
      
      Also note, user shouldn't set IPS_TEMPLATE, IPS_SEQ_ADJUST directly,
      so make these two bits be unchangable too.
      
      If we set the IPS_TEMPLATE_BIT, ct will be freed by nf_ct_tmpl_free,
      but actually it is alloced by nf_conntrack_alloc.
      If we set the IPS_SEQ_ADJUST_BIT, this may cause the NULL pointer
      deference, as the nfct_seqadj(ct) maybe NULL.
      
      Last, add some comments to describe the logic change due to the
      commit a963d710 ("netfilter: ctnetlink: Fix regression in CTA_STATUS
      processing"), which makes me feel a little confusing.
      
      Fixes: 76507f69 ("[NETFILTER]: nf_conntrack: use RCU for conntrack hash")
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      [bwh: Backported to 3.16: IPS_UNCHANGEABLE_MASK was not previously defined and
       ctnetlink_update_status() is not needed]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      00834185
    • Liping Zhang's avatar
      netfilter: ctnetlink: fix deadlock due to acquire _expect_lock twice · e40bd023
      Liping Zhang authored
      commit 88be4c09 upstream.
      
      Currently, ctnetlink_change_conntrack is always protected by _expect_lock,
      but this will cause a deadlock when deleting the helper from a conntrack,
      as the _expect_lock will be acquired again by nf_ct_remove_expectations:
      
               CPU0
              ----
        lock(nf_conntrack_expect_lock);
        lock(nf_conntrack_expect_lock);
      
        *** DEADLOCK ***
        May be due to missing lock nesting notation
      
        2 locks held by lt-conntrack_gr/12853:
        #0:  (&table[i].mutex){+.+.+.}, at: [<ffffffffa05e2009>]
             nfnetlink_rcv_msg+0x399/0x6a9 [nfnetlink]
        #1:  (nf_conntrack_expect_lock){+.....}, at: [<ffffffffa05f2c1f>]
             ctnetlink_new_conntrack+0x17f/0x408 [nf_conntrack_netlink]
      
        Call Trace:
         dump_stack+0x85/0xc2
         __lock_acquire+0x1608/0x1680
         ? ctnetlink_parse_tuple_proto+0x10f/0x1c0 [nf_conntrack_netlink]
         lock_acquire+0x100/0x1f0
         ? nf_ct_remove_expectations+0x32/0x90 [nf_conntrack]
         _raw_spin_lock_bh+0x3f/0x50
         ? nf_ct_remove_expectations+0x32/0x90 [nf_conntrack]
         nf_ct_remove_expectations+0x32/0x90 [nf_conntrack]
         ctnetlink_change_helper+0xc6/0x190 [nf_conntrack_netlink]
         ctnetlink_new_conntrack+0x1b2/0x408 [nf_conntrack_netlink]
         nfnetlink_rcv_msg+0x60a/0x6a9 [nfnetlink]
         ? nfnetlink_rcv_msg+0x1b9/0x6a9 [nfnetlink]
         ? nfnetlink_bind+0x1a0/0x1a0 [nfnetlink]
         netlink_rcv_skb+0xa4/0xc0
         nfnetlink_rcv+0x87/0x770 [nfnetlink]
      
      Since the operations are unrelated to nf_ct_expect, so we can drop the
      _expect_lock. Also note, after removing the _expect_lock protection,
      another CPU may invoke nf_conntrack_helper_unregister, so we should
      use rcu_read_lock to protect __nf_conntrack_helper_find invoked by
      ctnetlink_change_helper.
      
      Fixes: ca7433df ("netfilter: conntrack: seperate expect locking from nf_conntrack_lock")
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      [bwh: Backported to 3.16:
       - ctnetlink_change_helper() still auto-loads modules, so update the unlocking
         and re-locking there
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e40bd023
    • Tyrel Datwyler's avatar
      powerpc/sysfs: Fix reference leak of cpu device_nodes present at boot · f0be7fe7
      Tyrel Datwyler authored
      commit e76ca277 upstream.
      
      For CPUs present at boot each logical CPU acquires a reference to the
      associated device node of the core. This happens in register_cpu() which
      is called by topology_init(). The result of this is that we end up with
      a reference held by each thread of the core. However, these references
      are never freed if the CPU core is DLPAR removed.
      
      This patch fixes the reference leaks by acquiring and releasing the references
      in the CPU hotplug callbacks un/register_cpu_online(). With this patch symmetric
      reference counting is observed with both CPUs present at boot, and those DLPAR
      added after boot.
      
      Fixes: f86e4718 ("driver/core: cpu: initialize of_node in cpu's device struture")
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f0be7fe7
    • Tyrel Datwyler's avatar
      powerpc/pseries: Fix of_node_put() underflow during DLPAR remove · e733d462
      Tyrel Datwyler authored
      commit 68baf692 upstream.
      
      Historically struct device_node references were tracked using a kref embedded as
      a struct field. Commit 75b57ecf ("of: Make device nodes kobjects so they
      show up in sysfs") (Mar 2014) refactored device_nodes to be kobjects such that
      the device tree could by more simply exposed to userspace using sysfs.
      
      Commit 0829f6d1 ("of: device_node kobject lifecycle fixes") (Mar 2014)
      followed up these changes to better control the kobject lifecycle and in
      particular the referecne counting via of_node_get(), of_node_put(), and
      of_node_init().
      
      A result of this second commit was that it introduced an of_node_put() call when
      a dynamic node is detached, in of_node_remove(), that removes the initial kobj
      reference created by of_node_init().
      
      Traditionally as the original dynamic device node user the pseries code had
      assumed responsibilty for releasing this final reference in its platform
      specific DLPAR detach code.
      
      This patch fixes a refcount underflow introduced by commit 0829f6d1, and
      recently exposed by the upstreaming of the recount API.
      
      Messages like the following are no longer seen in the kernel log with this
      patch following DLPAR remove operations of cpus and pci devices.
      
        rpadlpar_io: slot PHB 72 removed
        refcount_t: underflow; use-after-free.
        ------------[ cut here ]------------
        WARNING: CPU: 5 PID: 3335 at lib/refcount.c:128 refcount_sub_and_test+0xf4/0x110
      
      Fixes: 0829f6d1 ("of: device_node kobject lifecycle fixes")
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      [mpe: Make change log commit references more verbose]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e733d462
    • Jack Morgenstein's avatar
      IB/mlx4: Fix ib device initialization error flow · 1f3d0ed6
      Jack Morgenstein authored
      commit 99e68909 upstream.
      
      In mlx4_ib_add, procedure mlx4_ib_alloc_eqs is called to allocate EQs.
      
      However, in the mlx4_ib_add error flow, procedure mlx4_ib_free_eqs is not
      called to free the allocated EQs.
      
      Fixes: e605b743 ("IB/mlx4: Increase the number of vectors (EQs) available for ULPs")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1f3d0ed6
    • Dan Carpenter's avatar
      HSI: ssi_protocol: double free in ssip_pn_xmit() · 28bc3299
      Dan Carpenter authored
      commit 30260501 upstream.
      
      If skb_pad() fails then it frees skb and we don't need to free it again
      at the end of the function.
      
      Fixes: dc7bf5d7 ("HSI: Introduce driver for SSI Protocol")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      28bc3299
    • Feras Daoud's avatar
      IB/ipoib: Update broadcast object if PKey value was changed in index 0 · 971609e1
      Feras Daoud authored
      commit 9a9b8112 upstream.
      
      Update the broadcast address in the priv->broadcast object when the
      Pkey value changes in index 0, otherwise the multicast GID value will
      keep the previous value of the PKey, and will not be updated.
      This leads to interface state down because the interface will keep the
      old PKey value.
      
      For example, in SR-IOV environment, if the PF changes the value of PKey
      index 0 for one of the VFs, then the VF receives PKey change event that
      triggers heavy flush. This flush calls update_parent_pkey that update the
      broadcast object and its relevant members. If in this case the multicast
      GID will not be updated, the interface state will be down.
      
      Fixes: c2904141 ("IPoIB: Fix pkey change flow for virtualization environments")
      Signed-off-by: default avatarFeras Daoud <ferasda@mellanox.com>
      Signed-off-by: default avatarErez Shitrit <erezsh@mellanox.com>
      Reviewed-by: default avatarAlex Vesker <valex@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      971609e1
    • Benjamin Coddington's avatar
      NFS: Use GFP_NOIO for two allocations in writeback · a078aea0
      Benjamin Coddington authored
      commit ae97aa52 upstream.
      
      Prevent a deadlock that can occur if we wait on allocations
      that try to write back our pages.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Fixes: 00bfa30a ("NFS: Create a common pgio_alloc and pgio_release...")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      [bwh: Backported to 3.16:
       - Drop changes in nfs_pageio_init()
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a078aea0
    • Ashish Kalra's avatar
      x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup · 3ec4f40c
      Ashish Kalra authored
      commit d594aa02 upstream.
      
      The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
      when the bootloader does not setup/provide a stack for the early boot components
      is not "enough".
      
      The setup code executing as part of early kernel startup code, uses the stack
      beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
      section. This is exposed mostly in the early video setup code, where
      it was corrupting BSS variables like force_x, force_y, which in-turn affected
      kernel parameters such as screen_info (screen_info.orig_video_cols) and
      later caused an exception/panic in console_init().
      
      Most recent boot loaders setup the stack for early boot components, so this
      stack overwriting into BSS section issue has not been exposed.
      Signed-off-by: default avatarAshish Kalra <ashish@bluestacks.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.localSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3ec4f40c
    • Brian Norris's avatar
      mwifiex: pcie: fix cmd_buf use-after-free in remove/reset · 3e42a214
      Brian Norris authored
      commit 3c8cb9ad upstream.
      
      Command buffers (skb's) are allocated by the main driver, and freed upon
      the last use. That last use is often in mwifiex_free_cmd_buffer(). In
      the meantime, if the command buffer gets used by the PCI driver, we map
      it as DMA-able, and store the mapping information in the 'cb' memory.
      
      However, if a command was in-flight when resetting the device (and
      therefore was still mapped), we don't get a chance to unmap this memory
      until after the core has cleaned up its command handling.
      
      Let's keep a refcount within the PCI driver, so we ensure the memory
      only gets freed after we've finished unmapping it.
      
      Noticed by KASAN when forcing a reset via:
      
        echo 1 > /sys/bus/pci/.../reset
      
      The same code path can presumably be exercised in remove() and
      shutdown().
      
      [  205.390377] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex...
      [  205.400393] ==================================================================
      [  205.407719] BUG: KASAN: use-after-free in mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr ffffffc0ad471b28
      [  205.419040] Read of size 16 by task bash/1913
      [  205.423421] =============================================================================
      [  205.431625] BUG skbuff_head_cache (Tainted: G    B          ): kasan: bad access detected
      [  205.439815] -----------------------------------------------------------------------------
      [  205.439815]
      [  205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913
      [  205.456709] 	alloc_debug_processing+0x124/0x178
      [  205.461282] 	___slab_alloc.constprop.58+0x528/0x608
      [  205.466196] 	__slab_alloc.isra.54.constprop.57+0x44/0x54
      [  205.471542] 	kmem_cache_alloc+0xcc/0x278
      [  205.475497] 	__build_skb+0x48/0x114
      [  205.479019] 	__netdev_alloc_skb+0xe0/0x170
      [  205.483244] 	mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex]
      [  205.488759] 	mwifiex_init_fw+0x40/0x6cc [mwifiex]
      [  205.493584] 	_mwifiex_fw_dpc+0x158/0x520 [mwifiex]
      [  205.498491] 	mwifiex_reinit_sw+0x2c4/0x398 [mwifiex]
      [  205.503510] 	mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie]
      [  205.509643] 	pci_reset_notify+0x5c/0x6c
      [  205.513519] 	pci_reset_function+0x6c/0x7c
      [  205.517567] 	reset_store+0x68/0x98
      [  205.521003] 	dev_attr_store+0x54/0x60
      [  205.524705] 	sysfs_kf_write+0x9c/0xb0
      [  205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913
      [  205.535064] 	free_debug_processing+0x264/0x370
      [  205.539550] 	__slab_free+0x84/0x40c
      [  205.543075] 	kmem_cache_free+0x1c8/0x2a0
      [  205.547030] 	__kfree_skb+0xb0/0xbc
      [  205.550465] 	consume_skb+0x164/0x178
      [  205.554079] 	__dev_kfree_skb_any+0x58/0x64
      [  205.558304] 	mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex]
      [  205.563817] 	mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex]
      [  205.569164] 	mwifiex_shutdown_sw+0x178/0x310 [mwifiex]
      [  205.574353] 	mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
      [  205.580398] 	pci_reset_notify+0x5c/0x6c
      [  205.584274] 	pci_dev_save_and_disable+0x24/0x6c
      [  205.588837] 	pci_reset_function+0x30/0x7c
      [  205.592885] 	reset_store+0x68/0x98
      [  205.596324] 	dev_attr_store+0x54/0x60
      [  205.600017] 	sysfs_kf_write+0x9c/0xb0
      ...
      [  205.800488] Call trace:
      [  205.802980] [<ffffffc00020a69c>] dump_backtrace+0x0/0x190
      [  205.808415] [<ffffffc00020a96c>] show_stack+0x20/0x28
      [  205.813506] [<ffffffc0005d020c>] dump_stack+0xa4/0xcc
      [  205.818598] [<ffffffc0003be44c>] print_trailer+0x158/0x168
      [  205.824120] [<ffffffc0003be5f0>] object_err+0x4c/0x5c
      [  205.829210] [<ffffffc0003c45bc>] kasan_report+0x334/0x500
      [  205.834641] [<ffffffc0003c3994>] check_memory_region+0x20/0x14c
      [  205.840593] [<ffffffc0003c3b14>] __asan_loadN+0x14/0x1c
      [  205.845879] [<ffffffbffc46171c>] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie]
      [  205.854282] [<ffffffbffc461864>] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie]
      [  205.862421] [<ffffffbffc462028>] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie]
      [  205.870302] [<ffffffbffc4620d4>] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie]
      [  205.877736] [<ffffffbffc1397a8>] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
      [  205.884658] [<ffffffbffc4606b4>] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
      [  205.892446] [<ffffffc000635f54>] pci_reset_notify+0x5c/0x6c
      [  205.898048] [<ffffffc00063a044>] pci_dev_save_and_disable+0x24/0x6c
      [  205.904350] [<ffffffc00063cf0c>] pci_reset_function+0x30/0x7c
      [  205.910134] [<ffffffc000641118>] reset_store+0x68/0x98
      [  205.915312] [<ffffffc000771588>] dev_attr_store+0x54/0x60
      [  205.920750] [<ffffffc00046f53c>] sysfs_kf_write+0x9c/0xb0
      [  205.926182] [<ffffffc00046dfb0>] kernfs_fop_write+0x184/0x1f8
      [  205.931963] [<ffffffc0003d64f4>] __vfs_write+0x6c/0x17c
      [  205.937221] [<ffffffc0003d7164>] vfs_write+0xf0/0x1c4
      [  205.942310] [<ffffffc0003d7da0>] SyS_write+0x78/0xd8
      [  205.947312] [<ffffffc000204634>] el0_svc_naked+0x24/0x28
      ...
      [  205.998268] ==================================================================
      
      This bug has been around in different forms for a while. It was sort of
      noticed in commit 955ab095 ("mwifiex: Do not kfree cmd buf while
      unregistering PCIe"), but it just fixed the double-free, without
      acknowledging the potential for use-after-free.
      
      Fixes: fc331460 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3e42a214
    • Peter Chen's avatar
      usb: host: xhci: print correct command ring address · 518bb4f2
      Peter Chen authored
      commit 6fc091fb upstream.
      
      Print correct command ring address using 'val_64'.
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      518bb4f2
    • Andrew Jones's avatar
      KVM: arm/arm64: fix races in kvm_psci_vcpu_on · 7c2173a8
      Andrew Jones authored
      commit 6c7a5dce upstream.
      
      Fix potential races in kvm_psci_vcpu_on() by taking the kvm->lock
      mutex.  In general, it's a bad idea to allow more than one PSCI_CPU_ON
      to process the same target VCPU at the same time.  One such problem
      that may arise is that one PSCI_CPU_ON could be resetting the target
      vcpu, which fills the entire sys_regs array with a temporary value
      including the MPIDR register, while another looks up the VCPU based
      on the MPIDR value, resulting in no target VCPU found.  Resolves both
      races found with the kvm-unit-tests/arm/psci unit test.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: default avatarChristoffer Dall <cdall@linaro.org>
      Reported-by: default avatarLevente Kurusa <lkurusa@redhat.com>
      Suggested-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7c2173a8
    • Dan Carpenter's avatar
      ath9k: off by one in ath9k_hw_nvram_read_array() · 2c30708e
      Dan Carpenter authored
      commit b7dcf68f upstream.
      
      The > should be >= or we read one space beyond the end of the array.
      
      Fixes: ab5c4f71 ("ath9k: allow to load EEPROM content via firmware API")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2c30708e
    • Frank Schaefer's avatar
      ov2640: fix vflip control · 3881e59f
      Frank Schaefer authored
      commit 7f140fc2 upstream.
      
      Enabling vflip currently causes wrong colors.
      It seems that (at least with the current sensor setup) REG04_VFLIP_IMG only
      changes the vertical readout direction.
      Because pixels are arranged RGRG... in odd lines and GBGB... in even lines,
      either a one line shift or even/odd line swap is required, too, but
      apparently this doesn't happen.
      
      I finally figured out that this can be done manually by setting
      REG04_VREF_EN.
      Looking at hflip, it turns out that bit REG04_HREF_EN is set there
      permanetly, but according to my tests has no effect on the pixel readout
      order.
      So my conclusion is that the current documentation of sensor register 0x04
      is wrong (has changed after preliminary datasheet version 2.2).
      
      I'm pretty sure that automatic vertical line shift/switch can be enabled,
      too, but until anyone finds ot how this works, we have to stick with manual
      switching.
      Signed-off-by: default avatarFrank Schäfer <fschaefer.oss@googlemail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3881e59f
    • Alyssa Milburn's avatar
      dw2102: limit messages to buffer size · 044c45f3
      Alyssa Milburn authored
      commit 950e252c upstream.
      
      Otherwise the i2c transfer functions can read or write beyond the end of
      stack or heap buffers.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 3.16:
       - Use obuf instead of state->data
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      044c45f3
    • Alyssa Milburn's avatar
      ttusb2: limit messages to buffer size · 28616936
      Alyssa Milburn authored
      commit a12b8ab8 upstream.
      
      Otherwise ttusb2_i2c_xfer can read or write beyond the end of static and
      heap buffers.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      28616936