1. 23 Feb, 2017 40 commits
    • Marc Zyngier's avatar
      arm64: kernel: Init MDCR_EL2 even in the absence of a PMU · f81f51bd
      Marc Zyngier authored
      commit 85054035 upstream.
      
      Commit f436b2ac ("arm64: kernel: fix architected PMU registers
      unconditional access") made sure we wouldn't access unimplemented
      PMU registers, but also left MDCR_EL2 uninitialized in that case,
      leading to trap bits being potentially left set.
      
      Make sure we always write something in that register.
      
      Fixes: f436b2ac ("arm64: kernel: fix architected PMU registers unconditional access")
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f81f51bd
    • Stefan Tauner's avatar
      USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7 · 0e5ecaa4
      Stefan Tauner authored
      commit ca006f78 upstream.
      
      This adds support to ftdi_sio for the Infineon TriBoard TC2X7
      engineering board for first-generation Aurix SoCs with Tricore CPUs.
      Mere addition of the device IDs does the job.
      Signed-off-by: default avatarStefan Tauner <stefan.tauner@technikum-wien.at>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0e5ecaa4
    • Ulf Hansson's avatar
      memstick: rtsx_usb_ms: Manage runtime PM when accessing the device · b9836e6a
      Ulf Hansson authored
      commit 9158cb29 upstream.
      
      Accesses to the rtsx usb device, which is the parent of the rtsx memstick
      device, must not be done unless it's runtime resumed. This is currently not
      the case and it could trigger various errors.
      
      Fix this by properly deal with runtime PM in this regards. This means
      making sure the device is runtime resumed, when serving requests via the
      ->request() callback or changing settings via the ->set_param() callbacks.
      
      Cc: Ritesh Raj Sarraf <rrs@researchut.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b9836e6a
    • Alan Stern's avatar
      memstick: rtsx_usb_ms: Runtime resume the device when polling for cards · f276b441
      Alan Stern authored
      commit 796aa46a upstream.
      
      Accesses to the rtsx usb device, which is the parent of the rtsx memstick
      device, must not be done unless it's runtime resumed.
      
      Therefore when the rtsx_usb_ms driver polls for inserted memstick cards,
      let's add pm_runtime_get|put*() to make sure accesses is done when the
      rtsx usb device is runtime resumed.
      Reported-by: default avatarRitesh Raj Sarraf <rrs@researchut.com>
      Tested-by: default avatarRitesh Raj Sarraf <rrs@researchut.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f276b441
    • Ulf Hansson's avatar
      mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led · f099ba58
      Ulf Hansson authored
      commit 4f48aa7a upstream.
      
      Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
      must be done when it's runtime resumed. Currently this isn't case when
      changing the led, so let's fix this by adding a pm_runtime_get_sync() and
      a pm_runtime_put() around those operations.
      Reported-by: default avatarRitesh Raj Sarraf <rrs@researchut.com>
      Tested-by: default avatarRitesh Raj Sarraf <rrs@researchut.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f099ba58
    • Ulf Hansson's avatar
      mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused · 640060a9
      Ulf Hansson authored
      commit 31cf742f upstream.
      
      The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no
      SD card is inserted. This is wrong, as it could cause the device to remain
      runtime resumed when it's unused. Fix this behaviour.
      Tested-by: default avatarRitesh Raj Sarraf <rrs@researchut.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      640060a9
    • Haibo Chen's avatar
      mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error · 4288c31a
      Haibo Chen authored
      commit 02265cd6 upstream.
      
      Potentially overflowing expression 1000000 * data->timeout_clks with
      type unsigned int is evaluated using 32-bit arithmetic, and then used
      in a context that expects an expression of type unsigned long long.
      
      To avoid overflow, cast 1000000U to type unsigned long long.
      Special thanks to Coverity.
      
      Fixes: 7f05538a ("mmc: sdhci: fix data timeout (part 2)")
      Signed-off-by: default avatarHaibo Chen <haibo.chen@nxp.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4288c31a
    • Dan Carpenter's avatar
      scsi: zfcp: spin_lock_irqsave() is not nestable · 512f4d83
      Dan Carpenter authored
      commit e7cb08e8 upstream.
      
      We accidentally overwrite the original saved value of "flags" so that we
      can't re-enable IRQs at the end of the function.  Presumably this
      function is mostly called with IRQs disabled or it would be obvious in
      testing.
      
      Fixes: aceeffbb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      512f4d83
    • Nicolas Dichtel's avatar
      ipv6: correctly add local routes when lo goes up · 5dd09f87
      Nicolas Dichtel authored
      commit a220445f upstream.
      
      The goal of the patch is to fix this scenario:
       ip link add dummy1 type dummy
       ip link set dummy1 up
       ip link set lo down ; ip link set lo up
      
      After that sequence, the local route to the link layer address of dummy1 is
      not there anymore.
      
      When the loopback is set down, all local routes are deleted by
      addrconf_ifdown()/rt6_ifdown(). At this time, the rt6_info entry still
      exists, because the corresponding idev has a reference on it. After the rcu
      grace period, dst_rcu_free() is called, and thus ___dst_free(), which will
      set obsolete to DST_OBSOLETE_DEAD.
      
      In this case, init_loopback() is called before dst_rcu_free(), thus
      obsolete is still sets to something <= 0. So, the function doesn't add the
      route again. To avoid that race, let's check the rt6 refcnt instead.
      
      Fixes: 25fb6ca4 ("net IPv6 : Fix broken IPv6 routing table after loopback down-up")
      Fixes: a881ae1f ("ipv6: don't call addrconf_dst_alloc again when enable lo")
      Fixes: 33d99113 ("ipv6: reallocate addrconf router for ipv6 address when lo device up")
      Reported-by: default avatarFrancesco Santoro <francesco.santoro@6wind.com>
      Reported-by: default avatarSamuel Gauthier <samuel.gauthier@6wind.com>
      CC: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
      CC: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
      CC: Sabrina Dubroca <sd@queasysnail.net>
      CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
      CC: Weilong Chen <chenweilong@huawei.com>
      CC: Gao feng <gaofeng@cn.fujitsu.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5dd09f87
    • Alex Deucher's avatar
      drm/radeon: change vblank_time's calculation method to reduce computational error. · c4529dec
      Alex Deucher authored
      commit 02cfb5fc upstream.
      
      Ported from Rex's amdgpu change.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c4529dec
    • Taesoo Kim's avatar
      jbd2: fix incorrect unlock on j_list_lock · 22508742
      Taesoo Kim authored
      commit 559cce69 upstream.
      
      When 'jh->b_transaction == transaction' (asserted by below)
      
        J_ASSERT_JH(jh, (jh->b_transaction == transaction || ...
      
      'journal->j_list_lock' will be incorrectly unlocked, since
      the the lock is aquired only at the end of if / else-if
      statements (missing the else case).
      Signed-off-by: default avatarTaesoo Kim <tsgatesv@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Fixes: 6e4862a5Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      22508742
    • Johannes Berg's avatar
      mac80211: discard multicast and 4-addr A-MSDUs · 7bbb3c6c
      Johannes Berg authored
      commit ea720935 upstream.
      
      In mac80211, multicast A-MSDUs are accepted in many cases that
      they shouldn't be accepted in:
       * drop A-MSDUs with a multicast A1 (RA), as required by the
         spec in 9.11 (802.11-2012 version)
       * drop A-MSDUs with a 4-addr header, since the fourth address
         can't actually be useful for them; unless 4-address frame
         format is actually requested, even though the fourth address
         is still not useful in this case, but ignored
      
      Accepting the first case, in particular, is very problematic
      since it allows anyone else with possession of a GTK to send
      unicast frames encapsulated in a multicast A-MSDU, even when
      the AP has client isolation enabled.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7bbb3c6c
    • Ming Lei's avatar
      scsi: Fix use-after-free · 7c40fa13
      Ming Lei authored
      commit bcd8f2e9 upstream.
      
      This patch fixes one use-after-free report[1] by KASAN.
      
      In __scsi_scan_target(), when a type 31 device is probed,
      SCSI_SCAN_TARGET_PRESENT is returned and the target will be scanned
      again.
      
      Inside the following scsi_report_lun_scan(), one new scsi_device
      instance is allocated, and scsi_probe_and_add_lun() is called again to
      probe the target and still see type 31 device, finally
      __scsi_remove_device() is called to remove & free the device at the end
      of scsi_probe_and_add_lun(), so cause use-after-free in
      scsi_report_lun_scan().
      
      And the following SCSI log can be observed:
      
      	scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
      	scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
      	scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
      	scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
      	scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
      	scsi 0:0:2:0: scsi scan: REPORT LUN scan
      	scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
      	scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
      	scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
      	BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr ffff88007b44a104
      
      This patch fixes the issue by moving the putting reference at
      the end of scsi_report_lun_scan().
      
      [1] KASAN report
      ==================================================================
      [    3.274597] PM: Adding info for serio:serio1
      [    3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at addr ffff880254d8c304
      [    3.275653] Read of size 4 by task kworker/u10:0/27
      [    3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
      [    3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [    3.276797] Workqueue: events_unbound async_run_entry_fn
      [    3.277083]  ffff880254d8c380 ffff880259a37870 ffffffff94bbc6c1 ffff880078402d80
      [    3.277532]  ffff880254d8bb80 ffff880259a37898 ffffffff9459fec1 ffff880259a37930
      [    3.277989]  ffff880254d8bb80 ffff880078402d80 ffff880259a37920 ffffffff945a0165
      [    3.278436] Call Trace:
      [    3.278528]  [<ffffffff94bbc6c1>] dump_stack+0x65/0x84
      [    3.278797]  [<ffffffff9459fec1>] kasan_object_err+0x21/0x70
      [    3.279063] device: 'psaux': device_add
      [    3.279616]  [<ffffffff945a0165>] kasan_report_error+0x205/0x500
      [    3.279651] PM: Adding info for No Bus:psaux
      [    3.280202]  [<ffffffff944ecd22>] ? kfree_const+0x22/0x30
      [    3.280486]  [<ffffffff94bc2dc9>] ? kobject_release+0x119/0x370
      [    3.280805]  [<ffffffff945a0543>] __asan_report_load4_noabort+0x43/0x50
      [    3.281170]  [<ffffffff9507e1f7>] ? __scsi_scan_target+0xd87/0xdf0
      [    3.281506]  [<ffffffff9507e1f7>] __scsi_scan_target+0xd87/0xdf0
      [    3.281848]  [<ffffffff9507d470>] ? scsi_add_device+0x30/0x30
      [    3.282156]  [<ffffffff94f7f660>] ? pm_runtime_autosuspend_expiration+0x60/0x60
      [    3.282570]  [<ffffffff956ddb07>] ? _raw_spin_lock+0x17/0x40
      [    3.282880]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.283200]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.283563]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.283882]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.284173]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.284492]  [<ffffffff941a8954>] ? pwq_dec_nr_in_flight+0x124/0x2a0
      [    3.284876]  [<ffffffff941d1770>] ? preempt_count_add+0x130/0x160
      [    3.285207]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.285526]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.285844]  [<ffffffff941aa810>] ? process_one_work+0x12d0/0x12d0
      [    3.286182]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.286443]  [<ffffffff940855cd>] ? __switch_to+0x88d/0x1430
      [    3.286745]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
      [    3.287085]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.287368]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
      [    3.287697] Object at ffff880254d8bb80, in cache kmalloc-2048 size: 2048
      [    3.288064] Allocated:
      [    3.288147] PID = 27
      [    3.288218]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
      [    3.288531]  [<ffffffff9459f246>] save_stack+0x46/0xd0
      [    3.288806]  [<ffffffff9459f4bd>] kasan_kmalloc+0xad/0xe0
      [    3.289098]  [<ffffffff9459c07e>] __kmalloc+0x13e/0x250
      [    3.289378]  [<ffffffff95078e5a>] scsi_alloc_sdev+0xea/0xcf0
      [    3.289701]  [<ffffffff9507de76>] __scsi_scan_target+0xa06/0xdf0
      [    3.290034]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.290362]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.290724]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.291055]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.291354]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.291695]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.292022]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.292325]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.292594]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.292886] Freed:
      [    3.292945] PID = 27
      [    3.293016]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
      [    3.293327]  [<ffffffff9459f246>] save_stack+0x46/0xd0
      [    3.293600]  [<ffffffff9459fa61>] kasan_slab_free+0x71/0xb0
      [    3.293916]  [<ffffffff9459bac2>] kfree+0xa2/0x1f0
      [    3.294168]  [<ffffffff9508158a>] scsi_device_dev_release_usercontext+0x50a/0x730
      [    3.294598]  [<ffffffff941ace9a>] execute_in_process_context+0xda/0x130
      [    3.294974]  [<ffffffff9508107c>] scsi_device_dev_release+0x1c/0x20
      [    3.295322]  [<ffffffff94f566f6>] device_release+0x76/0x1e0
      [    3.295626]  [<ffffffff94bc2db7>] kobject_release+0x107/0x370
      [    3.295942]  [<ffffffff94bc29ce>] kobject_put+0x4e/0xa0
      [    3.296222]  [<ffffffff94f56e17>] put_device+0x17/0x20
      [    3.296497]  [<ffffffff9505201c>] scsi_device_put+0x7c/0xa0
      [    3.296801]  [<ffffffff9507e1bc>] __scsi_scan_target+0xd4c/0xdf0
      [    3.297132]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.297458]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.297829]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.298156]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.298453]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.298777]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.299105]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.299408]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.299676]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.299967] Memory state around the buggy address:
      [    3.300209]  ffff880254d8c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.300608]  ffff880254d8c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.300986] >ffff880254d8c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.301408]                    ^
      [    3.301550]  ffff880254d8c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [    3.301987]  ffff880254d8c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [    3.302396]
      ==================================================================
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7c40fa13
    • murray foster's avatar
      ASoC: cs4270: fix DAPM stream name mismatch · 383eeaf9
      murray foster authored
      commit aa5f9209 upstream.
      
      Mismatching stream names in DAPM route and widget definitions are
      causing compilation errors. Fixing these names allows the cs4270
      driver to compile and function.
      
      [Errors must be at probe time not compile time -- broonie]
      Signed-off-by: default avatarMurray Foster <mrafoster@gmail.com>
      Acked-by: default avatarPaul Handrigan <Paul.Handrigan@cirrus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      383eeaf9
    • Jiri Slaby's avatar
      mmc: core: Annotate cmd_hdr as __le32 · 8258908d
      Jiri Slaby authored
      commit 3f2d2664 upstream.
      
      Commit f68381a7 (mmc: block: fix packed command header endianness)
      correctly fixed endianness handling of packed_cmd_hdr in
      mmc_blk_packed_hdr_wrq_prep.
      
      But now, sparse complains about incorrect types:
      drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
      drivers/mmc/card/block.c:1613:27:    expected unsigned int [unsigned] [usertype] <noident>
      drivers/mmc/card/block.c:1613:27:    got restricted __le32 [usertype] <noident>
      ...
      
      So annotate cmd_hdr properly using __le32 to make everyone happy.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Fixes: f68381a7 (mmc: block: fix packed command header endianness)
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8258908d
    • Oleg Nesterov's avatar
      fs/super.c: fix race between freeze_super() and thaw_super() · 777c9de7
      Oleg Nesterov authored
      commit 89f39af1 upstream.
      
      Change thaw_super() to check frozen != SB_FREEZE_COMPLETE rather than
      frozen == SB_UNFROZEN, otherwise it can race with freeze_super() which
      drops sb->s_umount after SB_FREEZE_WRITE to preserve the lock ordering.
      
      In this case thaw_super() will wrongly call s_op->unfreeze_fs() before
      it was actually frozen, and call sb_freeze_unlock() which leads to the
      unbalanced percpu_up_write(). Unfortunately lockdep can't detect this,
      so this triggers misc BUG_ON()'s in kernel/rcu/sync.c.
      Reported-and-tested-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      777c9de7
    • Steve French's avatar
      Cleanup missing frees on some ioctls · 1b40078c
      Steve French authored
      commit 24df1483 upstream.
      
      Cleanup some missing mem frees on some cifs ioctls, and
      clarify others to make more obvious that no data is returned.
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Acked-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      [bwh: Backported to 3.16:
       - Drop changes to smb2_duplicate_extents(), smb3_set_integrity()
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1b40078c
    • Steve French's avatar
      Do not send SMB3 SET_INFO request if nothing is changing · 5731ddb7
      Steve French authored
      commit 18dd8e1a upstream.
      
      [CIFS] We had cases where we sent a SMB2/SMB3 setinfo request with all
      timestamp (and DOS attribute) fields marked as 0 (ie do not change)
      e.g. on chmod or chown.
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5731ddb7
    • Steve French's avatar
      Clarify locking of cifs file and tcon structures and make more granular · d02e327b
      Steve French authored
      commit 3afca265 upstream.
      
      Remove the global file_list_lock to simplify cifs/smb3 locking and
      have spinlocks that more closely match the information they are
      protecting.
      
      Add new tcon->open_file_lock and file->file_info_lock spinlocks.
      Locks continue to follow a heirachy,
      	cifs_socket --> cifs_ses --> cifs_tcon --> cifs_file
      where global tcp_ses_lock still protects socket and cifs_ses, while the
      the newer locks protect the lower level structure's information
      (tcon and cifs_file respectively).
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Reviewed-by: default avatarGermano Percossi <germano.percossi@citrix.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d02e327b
    • Steve French's avatar
      SMB3: GUIDs should be constructed as random but valid uuids · 37ed7e2d
      Steve French authored
      commit fa70b87c upstream.
      
      GUIDs although random, and 16 bytes, need to be generated as
      proper uuids.
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Reported-by: default avatarDavid Goebels <davidgoe@microsoft.com>
      [bwh: Backported to 3.16: drop changes to create_durable_v2_buf()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      37ed7e2d
    • Steve French's avatar
      Set previous session id correctly on SMB3 reconnect · d7c93170
      Steve French authored
      commit c2afb814 upstream.
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Reported-by: default avatarDavid Goebel <davidgoe@microsoft.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d7c93170
    • Ross Lagerwall's avatar
      cifs: Limit the overall credit acquired · 47aa7c01
      Ross Lagerwall authored
      commit 7d414f39 upstream.
      
      The kernel client requests 2 credits for many operations even though
      they only use 1 credit (presumably to build up a buffer of credit).
      Some servers seem to give the client as much credit as is requested.  In
      this case, the amount of credit the client has continues increasing to
      the point where (server->credits * MAX_BUFFER_SIZE) overflows in
      smb2_wait_mtu_credits().
      
      Fix this by throttling the credit requests if an set limit is reached.
      For async requests where the credit charge may be > 1, request as much
      credit as what is charged.
      The limit is chosen somewhat arbitrarily. The Windows client
      defaults to 128 credits, the Windows server allows clients up to
      512 credits (or 8192 for Windows 2016), and the NetApp server
      (and at least one other) does not limit clients at all.
      Choose a high enough value such that the client shouldn't limit
      performance.
      
      This behavior was seen with a NetApp filer (NetApp Release 9.0RC2).
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      [bwh: Backported to 3.16: drop changes to smb2_async_{read,write}v()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      47aa7c01
    • Steve French's avatar
      Display number of credits available · a8c71496
      Steve French authored
      commit 9742805d upstream.
      
      In debugging smb3, it is useful to display the number
      of credits available, so we can see when the server has not granted
      sufficient operations for the client to make progress, or alternatively
      the client has requested too many credits (as we saw in a recent bug)
      so we can compare with the number of credits the server thinks
      we have.
      
      Add a /proc/fs/cifs/DebugData line to display the client view
      on how many credits are available.
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Reported-by: default avatarGermano Percossi <germano.percossi@citrix.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a8c71496
    • Marcin Nowakowski's avatar
      MIPS: ptrace: Fix regs_return_value for kernel context · 9de05bce
      Marcin Nowakowski authored
      commit 74f1077b upstream.
      
      Currently regs_return_value always negates reg[2] if it determines
      the syscall has failed, but when called in kernel context this check is
      invalid and may result in returning a wrong value.
      
      This fixes errors reported by CONFIG_KPROBES_SANITY_TEST
      
      Fixes: d7e7528b ("Audit: push audit success and retcode into arch ptrace.h")
      Signed-off-by: default avatarMarcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14381/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9de05bce
    • Manfred Spraul's avatar
      ipc/sem.c: fix complex_count vs. simple op race · accb9f16
      Manfred Spraul authored
      commit 5864a2fd upstream.
      
      Commit 6d07b68c ("ipc/sem.c: optimize sem_lock()") introduced a
      race:
      
      sem_lock has a fast path that allows parallel simple operations.
      There are two reasons why a simple operation cannot run in parallel:
       - a non-simple operations is ongoing (sma->sem_perm.lock held)
       - a complex operation is sleeping (sma->complex_count != 0)
      
      As both facts are stored independently, a thread can bypass the current
      checks by sleeping in the right positions.  See below for more details
      (or kernel bugzilla 105651).
      
      The patch fixes that by creating one variable (complex_mode)
      that tracks both reasons why parallel operations are not possible.
      
      The patch also updates stale documentation regarding the locking.
      
      With regards to stable kernels:
      The patch is required for all kernels that include the
      commit 6d07b68c ("ipc/sem.c: optimize sem_lock()") (3.10?)
      
      The alternative is to revert the patch that introduced the race.
      
      The patch is safe for backporting, i.e. it makes no assumptions
      about memory barriers in spin_unlock_wait().
      
      Background:
      Here is the race of the current implementation:
      
      Thread A: (simple op)
      - does the first "sma->complex_count == 0" test
      
      Thread B: (complex op)
      - does sem_lock(): This includes an array scan. But the scan can't
        find Thread A, because Thread A does not own sem->lock yet.
      - the thread does the operation, increases complex_count,
        drops sem_lock, sleeps
      
      Thread A:
      - spin_lock(&sem->lock), spin_is_locked(sma->sem_perm.lock)
      - sleeps before the complex_count test
      
      Thread C: (complex op)
      - does sem_lock (no array scan, complex_count==1)
      - wakes up Thread B.
      - decrements complex_count
      
      Thread A:
      - does the complex_count test
      
      Bug:
      Now both thread A and thread C operate on the same array, without
      any synchronization.
      
      Fixes: 6d07b68c ("ipc/sem.c: optimize sem_lock()")
      Link: http://lkml.kernel.org/r/1469123695-5661-1-git-send-email-manfred@colorfullife.com
      Reported-by: <felixh@informatik.uni-bremen.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <1vier1@web.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16:
       - We missed out on some earlier memory barrier changes
       - Use set_mb instead of smp_store_mb]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      accb9f16
    • Joe Perches's avatar
      ipc: remove use of seq_printf return value · 5b11c133
      Joe Perches authored
      commit 7f032d6e upstream.
      
      The seq_printf return value, because it's frequently misused,
      will eventually be converted to void.
      
      See: commit 1f33c41c ("seq_file: Rename seq_overflow() to
           seq_has_overflowed() and make public")
      Signed-off-by: default avatarJoe Perches <joe@perches.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>
      5b11c133
    • Paul E. McKenney's avatar
      compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release() · 6b454ee1
      Paul E. McKenney authored
      commit 536fa402 upstream.
      
      CPUs without single-byte and double-byte loads and stores place some
      "interesting" requirements on concurrent code.  For example (adapted
      from Peter Hurley's test code), suppose we have the following structure:
      
      	struct foo {
      		spinlock_t lock1;
      		spinlock_t lock2;
      		char a; /* Protected by lock1. */
      		char b; /* Protected by lock2. */
      	};
      	struct foo *foop;
      
      Of course, it is common (and good) practice to place data protected
      by different locks in separate cache lines.  However, if the locks are
      rarely acquired (for example, only in rare error cases), and there are
      a great many instances of the data structure, then memory footprint can
      trump false-sharing concerns, so that it can be better to place them in
      the same cache cache line as above.
      
      But if the CPU does not support single-byte loads and stores, a store
      to foop->a will do a non-atomic read-modify-write operation on foop->b,
      which will come as a nasty surprise to someone holding foop->lock2.  So we
      now require CPUs to support single-byte and double-byte loads and stores.
      Therefore, this commit adjusts the definition of __native_word() to allow
      these sizes to be used by smp_load_acquire() and smp_store_release().
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6b454ee1
    • Hidehiro Kawai's avatar
      mips/panic: replace smp_send_stop() with kdump friendly version in panic path · fd5c3e14
      Hidehiro Kawai authored
      commit 54c721b8 upstream.
      
      Daniel Walker reported problems which happens when
      crash_kexec_post_notifiers kernel option is enabled
      (https://lkml.org/lkml/2015/6/24/44).
      
      In that case, smp_send_stop() is called before entering kdump routines
      which assume other CPUs are still online.  As the result, kdump
      routines fail to save other CPUs' registers.  Additionally for MIPS
      OCTEON, it misses to stop the watchdog timer.
      
      To fix this problem, call a new kdump friendly function,
      crash_smp_send_stop(), instead of the smp_send_stop() when
      crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
      weak function, and it just call smp_send_stop().  Architecture
      codes should override it so that kdump can work appropriately.
      This patch provides MIPS version.
      
      Fixes: f06e5153 (kernel/panic.c: add "crash_kexec_post_notifiers" option)
      Link: http://lkml.kernel.org/r/20160810080950.11028.28000.stgit@sysi4-13.yrl.intra.hitachi.co.jpSigned-off-by: default avatarHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Reported-by: default avatarDaniel Walker <dwalker@fifo99.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Cc: Xunlei Pang <xpang@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: "Steven J. Hill" <steven.hill@cavium.com>
      Cc: Corey Minyard <cminyard@mvista.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>
      fd5c3e14
    • Hidehiro Kawai's avatar
      x86/panic: replace smp_send_stop() with kdump friendly version in panic path · ed1d3436
      Hidehiro Kawai authored
      commit 0ee59413 upstream.
      
      Daniel Walker reported problems which happens when
      crash_kexec_post_notifiers kernel option is enabled
      (https://lkml.org/lkml/2015/6/24/44).
      
      In that case, smp_send_stop() is called before entering kdump routines
      which assume other CPUs are still online.  As the result, for x86, kdump
      routines fail to save other CPUs' registers and disable virtualization
      extensions.
      
      To fix this problem, call a new kdump friendly function,
      crash_smp_send_stop(), instead of the smp_send_stop() when
      crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a weak
      function, and it just call smp_send_stop().  Architecture codes should
      override it so that kdump can work appropriately.  This patch only
      provides x86-specific version.
      
      For Xen's PV kernel, just keep the current behavior.
      
      NOTES:
      
      - Right solution would be to place crash_smp_send_stop() before
        __crash_kexec() invocation in all cases and remove smp_send_stop(), but
        we can't do that until all architectures implement own
        crash_smp_send_stop()
      
      - crash_smp_send_stop()-like work is still needed by
        machine_crash_shutdown() because crash_kexec() can be called without
        entering panic()
      
      Fixes: f06e5153 (kernel/panic.c: add "crash_kexec_post_notifiers" option)
      Link: http://lkml.kernel.org/r/20160810080948.11028.15344.stgit@sysi4-13.yrl.intra.hitachi.co.jpSigned-off-by: default avatarHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Reported-by: default avatarDaniel Walker <dwalker@fifo99.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Cc: Xunlei Pang <xpang@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: "Steven J. Hill" <steven.hill@cavium.com>
      Cc: Corey Minyard <cminyard@mvista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ed1d3436
    • Paul Mackerras's avatar
      powerpc/64: Fix incorrect return value from __copy_tofrom_user · 4aa22b89
      Paul Mackerras authored
      commit 1a34439e upstream.
      
      Debugging a data corruption issue with virtio-net/vhost-net led to
      the observation that __copy_tofrom_user was occasionally returning
      a value 16 larger than it should.  Since the return value from
      __copy_tofrom_user is the number of bytes not copied, this means
      that __copy_tofrom_user can occasionally return a value larger
      than the number of bytes it was asked to copy.  In turn this can
      cause higher-level copy functions such as copy_page_to_iter_iovec
      to corrupt memory by copying data into the wrong memory locations.
      
      It turns out that the failing case involves a fault on the store
      at label 79, and at that point the first unmodified byte of the
      destination is at R3 + 16.  Consequently the exception handler
      for that store needs to add 16 to R3 before using it to work out
      how many bytes were not copied, but in this one case it was not
      adding the offset to R3.  To fix it, this moves the label 179 to
      the point where we add 16 to R3.  I have checked manually all the
      exception handlers for the loads and stores in this code and the
      rest of them are correct (it would be excellent to have an
      automated test of all the exception cases).
      
      This bug has been present since this code was initially
      committed in May 2002 to Linux version 2.5.20.
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4aa22b89
    • Laurent Dufour's avatar
      powerpc/pseries: Fix stack corruption in htpe code · 0d86a59a
      Laurent Dufour authored
      commit 05af40e8 upstream.
      
      This commit fixes a stack corruption in the pseries specific code dealing
      with the huge pages.
      
      In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments
      to the hypervisor is not large enough. This leads to a stack corruption
      where a previously saved register could be corrupted leading to unexpected
      result in the caller, like the following panic:
      
        Oops: Kernel access of bad area, sig: 11 [#1]
        SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: virtio_balloon ip_tables x_tables autofs4
        virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio
        CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76
        task: c000000005394880 task.stack: c000000005570000
        NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000
        REGS: c000000005573820 TRAP: 0300   Not tainted  (4.8.0)
        MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 84822884  XER: 20000000
        CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1
        GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964
        GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104
        GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5
        GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000
        GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000
        GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000
        GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964
        GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0
        NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470
        LR [c00000000027bf64] zap_huge_pmd+0x44/0x470
        Call Trace:
        [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable)
        [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0
        [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120
        [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0
        [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0
        [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0
        [c000000005573e30] [c000000000009560] system_call+0x38/0x108
        Instruction dump:
        fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1
        7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378
      
      Most of the time, the bug is surfacing in a caller up in the stack from
      __pSeries_lpar_hugepage_invalidate() which is quite confusing.
      
      This bug is pending since v3.11 but was hidden if a caller of the
      caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped
      register (r18 in this case) in the stack and is not using it until
      restoring it. GCC 6.2.0 seems to raise it more frequently.
      
      This commit also change the definition of the parameter buffer in
      pSeries_lpar_flush_hash_range() to rely on the global define
      PLPAR_HCALL9_BUFSIZE (no functional change here).
      
      Fixes: 1a527286 ("powerpc: Optimize hugepage invalidate")
      Signed-off-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0d86a59a
    • Wei Fang's avatar
      vfs,mm: fix a dead loop in truncate_inode_pages_range() · 27283035
      Wei Fang authored
      commit c2a9737f upstream.
      
      We triggered a deadloop in truncate_inode_pages_range() on 32 bits
      architecture with the test case bellow:
      
      	...
      	fd = open();
      	write(fd, buf, 4096);
      	preadv64(fd, &iovec, 1, 0xffffffff000);
      	ftruncate(fd, 0);
      	...
      
      Then ftruncate() will not return forever.
      
      The filesystem used in this case is ubifs, but it can be triggered on
      many other filesystems.
      
      When preadv64() is called with offset=0xffffffff000, a page with
      index=0xffffffff will be added to the radix tree of ->mapping.  Then
      this page can be found in ->mapping with pagevec_lookup().  After that,
      truncate_inode_pages_range(), which is called in ftruncate(), will fall
      into an infinite loop:
      
       - find a page with index=0xffffffff, since index>=end, this page won't
         be truncated
      
       - index++, and index become 0
      
       - the page with index=0xffffffff will be found again
      
      The data type of index is unsigned long, so index won't overflow to 0 on
      64 bits architecture in this case, and the dead loop won't happen.
      
      Since truncate_inode_pages_range() is executed with holding lock of
      inode->i_rwsem, any operation related with this lock will be blocked,
      and a hung task will happen, e.g.:
      
        INFO: task truncate_test:3364 blocked for more than 120 seconds.
        ...
           call_rwsem_down_write_failed+0x17/0x30
           generic_file_write_iter+0x32/0x1c0
           ubifs_write_iter+0xcc/0x170
           __vfs_write+0xc4/0x120
           vfs_write+0xb2/0x1b0
           SyS_write+0x46/0xa0
      
      The page with index=0xffffffff added to ->mapping is useless.  Fix this
      by checking the read position before allocating pages.
      
      Link: http://lkml.kernel.org/r/1475151010-40166-1-git-send-email-fangwei1@huawei.comSigned-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      27283035
    • Gerald Schaefer's avatar
      mm/hugetlb: check for reserved hugepages during memory offline · 4428f3bd
      Gerald Schaefer authored
      commit 082d5b6b upstream.
      
      In dissolve_free_huge_pages(), free hugepages will be dissolved without
      making sure that there are enough of them left to satisfy hugepage
      reservations.
      
      Fix this by adding a return value to dissolve_free_huge_pages() and
      checking h->free_huge_pages vs.  h->resv_huge_pages.  Note that this may
      lead to the situation where dissolve_free_huge_page() returns an error
      and all free hugepages that were dissolved before that error are lost,
      while the memory block still cannot be set offline.
      
      Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
      Link: http://lkml.kernel.org/r/20160926172811.94033-3-gerald.schaefer@de.ibm.comSigned-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4428f3bd
    • Gerald Schaefer's avatar
      mm/hugetlb: fix memory offline with hugepage size > memory block size · 23ac701d
      Gerald Schaefer authored
      commit 2247bb33 upstream.
      
      Patch series "mm/hugetlb: memory offline issues with hugepages", v4.
      
      This addresses several issues with hugepages and memory offline.  While
      the first patch fixes a panic, and is therefore rather important, the
      last patch is just a performance optimization.
      
      The second patch fixes a theoretical issue with reserved hugepages,
      while still leaving some ugly usability issue, see description.
      
      This patch (of 3):
      
      dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
      list corruption and addressing exception when trying to set a memory
      block offline that is part (but not the first part) of a "gigantic"
      hugetlb page with a size > memory block size.
      
      When no other smaller hugetlb page sizes are present, the VM_BUG_ON()
      will trigger directly.  In the other case we will run into an addressing
      exception later, because dissolve_free_huge_page() will not work on the
      head page of the compound hugetlb page which will result in a NULL
      hstate from page_hstate().
      
      To fix this, first remove the VM_BUG_ON() because it is wrong, and then
      use the compound head page in dissolve_free_huge_page().  This means
      that an unused pre-allocated gigantic page that has any part of itself
      inside the memory block that is going offline will be dissolved
      completely.  Losing an unused gigantic hugepage is preferable to failing
      the memory offline, for example in the situation where a (possibly
      faulty) memory DIMM needs to go offline.
      
      Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
      Link: http://lkml.kernel.org/r/20160926172811.94033-2-gerald.schaefer@de.ibm.comSigned-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      23ac701d
    • Dmitry Torokhov's avatar
      Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled · 95b17cb3
      Dmitry Torokhov authored
      commit 62837b3c upstream.
      
      Another Lifebook machine that needs the same quirk as other similar
      models to make the driver working.
      
      Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries
      are in alphabetical order.
      Reported-by: default avatarWilliam Linna <william.linna@gmail.com>
      Tested-by: default avatarWilliam Linna <william.linna@gmail.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      95b17cb3
    • Bart Van Assche's avatar
      IB/srp: Fix infinite loop when FMR sg[0].offset != 0 · 00a05de9
      Bart Van Assche authored
      commit 681cc360 upstream.
      
      Avoid that mapping an sg-list in which the first element has a
      non-zero offset triggers an infinite loop when using FMR. This
      patch makes the FMR mapping code similar to that of ib_sg_to_pages().
      
      Note: older Mellanox HCAs do not support non-zero offsets for FMR.
      See also commit 8c4037b5 ("IB/srp: always avoid non-zero offsets
      into an FMR").
      Reported-by: default avatarAlex Estrin <alex.estrin@intel.com>
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.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>
      00a05de9
    • Guenter Roeck's avatar
      metag: Only define atomic_dec_if_positive conditionally · 3c54629c
      Guenter Roeck authored
      commit 35d04077 upstream.
      
      The definition of atomic_dec_if_positive() assumes that
      atomic_sub_if_positive() exists, which is only the case if
      metag specific atomics are used. This results in the following
      build error when trying to build metag1_defconfig.
      
      kernel/ucount.c: In function 'dec_ucount':
      kernel/ucount.c:211: error:
      	implicit declaration of function 'atomic_sub_if_positive'
      
      Moving the definition of atomic_dec_if_positive() into the metag
      conditional code fixes the problem.
      
      Fixes: 6006c0d8 ("metag: Atomics, locks and bitops")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3c54629c
    • Eric Dumazet's avatar
      netlink: do not enter direct reclaim from netlink_dump() · 8647e797
      Eric Dumazet authored
      commit d35c99ff upstream.
      
      Since linux-3.15, netlink_dump() can use up to 16384 bytes skb
      allocations.
      
      Due to struct skb_shared_info ~320 bytes overhead, we end up using
      order-3 (on x86) page allocations, that might trigger direct reclaim and
      add stress.
      
      The intent was really to attempt a large allocation but immediately
      fallback to a smaller one (order-1 on x86) in case of memory stress.
      
      On recent kernels (linux-4.4), we can remove __GFP_DIRECT_RECLAIM to
      meet the goal. Old kernels would need to remove __GFP_WAIT
      
      While we are at it, since we do an order-3 allocation, allow to use
      all the allocated bytes instead of 16384 to reduce syscalls during
      large dumps.
      
      iproute2 already uses 32KB recvmsg() buffer sizes.
      
      Alexei provided an initial patch downsizing to SKB_WITH_OVERHEAD(16384)
      
      Fixes: 9063e21f ("netlink: autosize skb lengthes")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Cc: Greg Thelen <gthelen@google.com>
      Reviewed-by: default avatarGreg Rose <grose@lightfleet.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16:
       - Adjust context
       - Mask out __GFP_WAIT, as suggested]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8647e797
    • Johannes Weiner's avatar
      mm: filemap: fix mapping->nrpages double accounting in fuse · 19cf51e7
      Johannes Weiner authored
      commit 3ddf40e8 upstream.
      
      Commit 22f2ac51 ("mm: workingset: fix crash in shadow node shrinker
      caused by replace_page_cache_page()") switched replace_page_cache() from
      raw radix tree operations to page_cache_tree_insert() but didn't take
      into account that the latter function, unlike the raw radix tree op,
      handles mapping->nrpages.  As a result, that counter is bumped for each
      page replacement rather than balanced out even.
      
      The mapping->nrpages counter is used to skip needless radix tree walks
      when invalidating, truncating, syncing inodes without pages, as well as
      statistics for userspace.  Since the error is positive, we'll do more
      page cache tree walks than necessary; we won't miss a necessary one.
      And we'll report more buffer pages to userspace than there are.  The
      error is limited to fuse inodes.
      
      Fixes: 22f2ac51 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()")
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      19cf51e7
    • Justin Maggard's avatar
      async_pq_val: fix DMA memory leak · c3fa800f
      Justin Maggard authored
      commit c8475090 upstream.
      
      Add missing dmaengine_unmap_put(), so we don't OOM during RAID6 sync.
      
      Fixes: 1786b943 ("async_pq_val: convert to dmaengine_unmap_data")
      Signed-off-by: default avatarJustin Maggard <jmaggard@netgear.com>
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c3fa800f