1. 06 Mar, 2017 40 commits
    • Jeff Layton's avatar
      ceph: fix bad endianness handling in parse_reply_info_extra · af9c6633
      Jeff Layton authored
      [ Upstream commit 6df8c9d8 ]
      
      sparse says:
      
          fs/ceph/mds_client.c:291:23: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:293:28: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:294:28: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:296:28: warning: restricted __le32 degrades to integer
      
      The op value is __le32, so we need to convert it before comparing it.
      
      Cc: stable@vger.kernel.org # needs backporting for < 3.14
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      af9c6633
    • Yegor Yefremov's avatar
      can: ti_hecc: add missing prepare and unprepare of the clock · 23fdc77d
      Yegor Yefremov authored
      [ Upstream commit befa6011 ]
      
      In order to make the driver work with the common clock framework, this
      patch converts the clk_enable()/clk_disable() to
      clk_prepare_enable()/clk_disable_unprepare().
      
      Also add error checking for clk_prepare_enable().
      Signed-off-by: default avatarYegor Yefremov <yegorslists@googlemail.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      23fdc77d
    • Einar Jón's avatar
      can: c_can_pci: fix null-pointer-deref in c_can_start() - set device pointer · 656e7d39
      Einar Jón authored
      [ Upstream commit c97c52be ]
      
      The priv->device pointer for c_can_pci is never set, but it is used
      without a NULL check in c_can_start(). Setting it in c_can_pci_probe()
      like c_can_plat_probe() prevents c_can_pci.ko from crashing, with and
      without CONFIG_PM.
      
      This might also cause the pm_runtime_*() functions in c_can.c to
      actually be executed for c_can_pci devices - they are the only other
      place where priv->device is used, but they all contain a null check.
      Signed-off-by: default avatarEinar Jón <tolvupostur@gmail.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      656e7d39
    • Quinn Tran's avatar
      qla2xxx: Fix crash due to null pointer access · de99814c
      Quinn Tran authored
      [ Upstream commit fc1ffd6c ]
      
      During code inspection, while investigating following stack trace
      seen on one of the test setup, we found out there was possibility
      of memory leak becuase driver was not unwinding the stack properly.
      
      This issue has not been reproduced in a test environment or on a
      customer setup.
      
      Here's stack trace that was seen.
      
      [1469877.797315] Call Trace:
      [1469877.799940]  [<ffffffffa03ab6e9>] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
      [1469877.806980]  [<ffffffffa03ac50a>] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
      [1469877.814013]  [<ffffffff813b6d01>] ? __pm_runtime_resume+0x51/0xa0
      [1469877.820265]  [<ffffffff8157c1f5>] ? _raw_spin_lock_irqsave+0x25/0x90
      [1469877.826776]  [<ffffffff8157cd2d>] ? _raw_spin_unlock_irqrestore+0x6d/0x80
      [1469877.833720]  [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100
      [1469877.839885]  [<ffffffff8157cd0c>] ? _raw_spin_unlock_irqrestore+0x4c/0x80
      [1469877.846830]  [<ffffffff81319b9c>] local_pci_probe+0x4c/0xb0
      [1469877.852562]  [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100
      [1469877.858727]  [<ffffffff81319c89>] pci_call_probe+0x89/0xb0
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarQuinn Tran <quinn.tran@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      [ bvanassche: Fixed spelling in patch description ]
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      de99814c
    • Richard Weinberger's avatar
      ubifs: Fix journal replay wrt. xattr nodes · a01621bb
      Richard Weinberger authored
      [ Upstream commit 1cb51a15 ]
      
      When replaying the journal it can happen that a journal entry points to
      a garbage collected node.
      This is the case when a power-cut occurred between a garbage collect run
      and a commit. In such a case nodes have to be read using the failable
      read functions to detect whether the found node matches what we expect.
      
      One corner case was forgotten, when the journal contains an entry to
      remove an inode all xattrs have to be removed too. UBIFS models xattr
      like directory entries, so the TNC code iterates over
      all xattrs of the inode and removes them too. This code re-uses the
      functions for walking directories and calls ubifs_tnc_next_ent().
      ubifs_tnc_next_ent() expects to be used only after the journal and
      aborts when a node does not match the expected result. This behavior can
      render an UBIFS volume unmountable after a power-cut when xattrs are
      used.
      
      Fix this issue by using failable read functions in ubifs_tnc_next_ent()
      too when replaying the journal.
      Cc: stable@vger.kernel.org
      Fixes: 1e51764a ("UBIFS: add new flash file system")
      Reported-by: default avatarRock Lee <rockdotlee@gmail.com>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a01621bb
    • J. Bruce Fields's avatar
      svcrpc: don't leak contexts on PROC_DESTROY · f24447e6
      J. Bruce Fields authored
      [ Upstream commit 78794d18 ]
      
      Context expiry times are in units of seconds since boot, not unix time.
      
      The use of get_seconds() here therefore sets the expiry time decades in
      the future.  This prevents timely freeing of contexts destroyed by
      client RPC_GSS_PROC_DESTROY requests.  We'd still free them eventually
      (when the module is unloaded or the container shut down), but a lot of
      contexts could pile up before then.
      
      Cc: stable@vger.kernel.org
      Fixes: c5b29f88 "sunrpc: use seconds since boot in expiry cache"
      Reported-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f24447e6
    • David Matlack's avatar
      KVM: x86: flush pending lapic jump label updates on module unload · 73dc8655
      David Matlack authored
      [ Upstream commit cef84c30 ]
      
      KVM's lapic emulation uses static_key_deferred (apic_{hw,sw}_disabled).
      These are implemented with delayed_work structs which can still be
      pending when the KVM module is unloaded. We've seen this cause kernel
      panics when the kvm_intel module is quickly reloaded.
      
      Use the new static_key_deferred_flush() API to flush pending updates on
      module unload.
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      73dc8655
    • David Matlack's avatar
      jump_labels: API for flushing deferred jump label updates · 577c9c60
      David Matlack authored
      [ Upstream commit b6416e61 ]
      
      Modules that use static_key_deferred need a way to synchronize with
      any delayed work that is still pending when the module is unloaded.
      Introduce static_key_deferred_flush() which flushes any pending
      jump label updates.
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      577c9c60
    • Stefan Wahren's avatar
      mmc: mxs-mmc: Fix additional cycles after transmission stop · d51217ab
      Stefan Wahren authored
      [ Upstream commit 01167c7b ]
      
      According to the code the intention is to append 8 SCK cycles
      instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this
      will never happened because it's an AC command not an ADTC command.
      So fix this by moving the statement into the right function.
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Fixes: e4243f13 (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d51217ab
    • Takashi Iwai's avatar
      drm: Fix broken VT switch with video=1366x768 option · d4fa088d
      Takashi Iwai authored
      [ Upstream commit fdf35a6b ]
      
      I noticed that the VT switch doesn't work any longer with a Dell
      laptop with 1366x768 eDP when the machine is connected with a DP
      monitor.  It behaves as if VT were switched, but the graphics remain
      frozen.  Actually the keyboard works, so I could switch back to VT7
      again.
      
      I tried to track down the problem, and encountered a long story until
      we reach to this error:
      
      - The machine is booted with video=1366x768 option (the distro
        installer seems to add it as default).
      - Recently, drm_helper_probe_single_connector_modes() deals with
        cmdline modes, and it tries to create a new mode when no
        matching mode is found.
      - The drm_mode_create_from_cmdline_mode() creates a mode based on
        either CVT of GFT according to the given cmdline mode; in our case,
        it's 1366x768.
      - Since both CVT and GFT can't express the width 1366 due to
        alignment, the resultant mode becomes 1368x768, slightly larger than
        the given size.
      - Later on, the atomic commit is performed, and in
        drm_atomic_check_only(), the size of each plane is checked.
      - The size check of 1366x768 fails due to the above, and eventually
        the whole VT switch fails.
      
      Back in the history, we've had a manual fix-up of 1368x768 in various
      places via c09dedb7 ("drm/edid: Add a workaround for 1366x768 HD
      panel"), but they have been all in drm_edid.c at probing the modes
      from EDID.  For addressing the problem above, we need a similar hack
      to the mode newly created from cmdline, manually adjusting the width
      when the expected size is 1366 while we get 1368 instead.
      
      Fixes: eaf99c74 ("drm: Perform cmdline mode parsing during...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.deReviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d4fa088d
    • Mathias Nyman's avatar
      xhci: fix deadlock at host remove by running watchdog correctly · c068da47
      Mathias Nyman authored
      [ Upstream commit d6169d04 ]
      
      If a URB is killed while the host is removed we can end up in a situation
      where the hub thread takes the roothub device lock, and waits for
      the URB to be given back by xhci-hcd, blocking the host remove code.
      
      xhci-hcd tries to stop the endpoint and give back the urb, but can't
      as the host is removed from PCI bus at the same time, preventing the normal
      way of giving back urb.
      
      Instead we need to rely on the stop command timeout function to give back
      the urb. This xhci_stop_endpoint_command_watchdog() timeout function
      used a XHCI_STATE_DYING flag to indicate if the timeout function is already
      running, but later this flag has been taking into use in other places to
      mark that xhci is dying.
      
      Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
      checking that reading from pci state does not return 0xffffffff or that
      host is not halted before trying to stop the endpoint.
      
      This whole area of stopping endpoints, giving back URBs, and the wathdog
      timeout need rework, this fix focuses on solving a specific deadlock
      issue that we can then send to stable before any major rework.
      
      Cc: <stable@vger.kernel.org>
      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 avatarSasha Levin <alexander.levin@verizon.com>
      c068da47
    • Bjorn Helgaas's avatar
      PCI: Enumerate switches below PCI-to-PCIe bridges · ee21da30
      Bjorn Helgaas authored
      [ Upstream commit 51ebfc92 ]
      
      A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
      interface and a PCI Express secondary interface.  The PCIe interface is a
      Downstream Port that originates a Link.  See the "PCI Express to PCI/PCI-X
      Bridge Specification", rev 1.0, sections 1.2 and A.6.
      
      The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below
      the bridge:
      
        00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a]
        01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a]
        02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a]
        03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a]
      
      01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by
      lspci).  As we traverse a PCIe hierarchy, device connections alternate
      between PCIe Links and internal Switch logic.  Previously we did not
      recognize that 01:00.0 had a secondary link, so we thought the 02:00.0
      Upstream Port *did* have a secondary link.  In fact, it's the other way
      around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic
      on its secondary side.
      
      When we thought 02:00.0 had a secondary link, the pci_scan_slot() ->
      only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0
      was the only possible downstream device.  But 03:00.0 doesn't exist, so we
      didn't look for any other devices on bus 03.
      
      Booting with "pci=pcie_scan_all" is a workaround, but we don't want users
      to have to do that.
      
      Recognize that PCI-to-PCIe bridges originate links on their secondary
      interfaces.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361
      Fixes: d0751b98 ("PCI: Add dev->has_secondary_link to track downstream PCIe links")
      Tested-by: default avatarBlake Moore <blake.moore@men.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v4.2+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ee21da30
    • Bjorn Helgaas's avatar
      x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F · 61a16adb
      Bjorn Helgaas authored
      [ Upstream commit 89e9f7bc ]
      
      Martin reported that the Supermicro X8DTH-i/6/iF/6F advertises incorrect
      host bridge windows via _CRS:
      
        pci_root PNP0A08:00: host bridge window [io  0xf000-0xffff]
        pci_root PNP0A08:01: host bridge window [io  0xf000-0xffff]
      
      Both bridges advertise the 0xf000-0xffff window, which cannot be correct.
      
      Work around this by ignoring _CRS on this system.  The downside is that we
      may not assign resources correctly to hot-added PCI devices (if they are
      possible on this system).
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=42606Reported-by: default avatarMartin Burnicki <martin.burnicki@meinberg.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      61a16adb
    • Johan Hovold's avatar
      USB: serial: ch341: fix control-message error handling · a457dcb7
      Johan Hovold authored
      [ Upstream commit 2d5a9c72 ]
      
      A short control transfer would currently fail to be detected, something
      which could lead to stale buffer data being used as valid input.
      
      Check for short transfers, and make sure to log any transfer errors.
      
      Note that this also avoids leaking heap data to user space (TIOCMGET)
      and the remote device (break control).
      
      Fixes: 6ce76104 ("USB: Driver for CH341 USB-serial adaptor")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a457dcb7
    • Augusto Mecking Caringi's avatar
      vme: Fix wrong pointer utilization in ca91cx42_slave_get · 1fe63899
      Augusto Mecking Caringi authored
      [ Upstream commit c8a6a09c ]
      
      In ca91cx42_slave_get function, the value pointed by vme_base pointer is
      set through:
      
      *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]);
      
      So it must be dereferenced to be used in calculation of pci_base:
      
      *pci_base = (dma_addr_t)*vme_base + pci_offset;
      
      This bug was caught thanks to the following gcc warning:
      
      drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’:
      drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
      *pci_base = (dma_addr_t)vme_base + pci_offset;
      Signed-off-by: default avatarAugusto Mecking Caringi <augustocaringi@gmail.com>
      Acked-By: default avatarMartyn Welch <martyn@welchs.me.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1fe63899
    • Akinobu Mita's avatar
      sysrq: attach sysrq handler correctly for 32-bit kernel · dad7228d
      Akinobu Mita authored
      [ Upstream commit 802c0388 ]
      
      The sysrq input handler should be attached to the input device which has
      a left alt key.
      
      On 32-bit kernels, some input devices which has a left alt key cannot
      attach sysrq handler.  Because the keybit bitmap in struct input_device_id
      for sysrq is not correctly initialized.  KEY_LEFTALT is 56 which is
      greater than BITS_PER_LONG on 32-bit kernels.
      
      I found this problem when using a matrix keypad device which defines
      a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32).
      
      Cc: Jiri Slaby <jslaby@suse.com>
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      dad7228d
    • Mike Kravetz's avatar
      mm/hugetlb.c: fix reservation race when freeing surplus pages · 31126310
      Mike Kravetz authored
      [ Upstream commit e5bbc8a6 ]
      
      return_unused_surplus_pages() decrements the global reservation count,
      and frees any unused surplus pages that were backing the reservation.
      
      Commit 7848a4bf ("mm/hugetlb.c: add cond_resched_lock() in
      return_unused_surplus_pages()") added a call to cond_resched_lock in the
      loop freeing the pages.
      
      As a result, the hugetlb_lock could be dropped, and someone else could
      use the pages that will be freed in subsequent iterations of the loop.
      This could result in inconsistent global hugetlb page state, application
      api failures (such as mmap) failures or application crashes.
      
      When dropping the lock in return_unused_surplus_pages, make sure that
      the global reservation count (resv_huge_pages) remains sufficiently
      large to prevent someone else from claiming pages about to be freed.
      
      Analyzed by Paul Cassella.
      
      Fixes: 7848a4bf ("mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()")
      Link: http://lkml.kernel.org/r/1483991767-6879-1-git-send-email-mike.kravetz@oracle.comSigned-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reported-by: default avatarPaul Cassella <cassella@cray.com>
      Suggested-by: default avatarMichal Hocko <mhocko@kernel.org>
      Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
      Cc: <stable@vger.kernel.org>	[3.15+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      31126310
    • Eric Ren's avatar
      ocfs2: fix crash caused by stale lvb with fsdlm plugin · 257e62ac
      Eric Ren authored
      [ Upstream commit e7ee2c08 ]
      
      The crash happens rather often when we reset some cluster nodes while
      nodes contend fiercely to do truncate and append.
      
      The crash backtrace is below:
      
         dlm: C21CBDA5E0774F4BA5A9D4F317717495: dlm_recover_grant 1 locks on 971 resources
         dlm: C21CBDA5E0774F4BA5A9D4F317717495: dlm_recover 9 generation 5 done: 4 ms
         ocfs2: Begin replay journal (node 318952601, slot 2) on device (253,18)
         ocfs2: End replay journal (node 318952601, slot 2) on device (253,18)
         ocfs2: Beginning quota recovery on device (253,18) for slot 2
         ocfs2: Finishing quota recovery on device (253,18) for slot 2
         (truncate,30154,1):ocfs2_truncate_file:470 ERROR: bug expression: le64_to_cpu(fe->i_size) != i_size_read(inode)
         (truncate,30154,1):ocfs2_truncate_file:470 ERROR: Inode 290321, inode i_size = 732 != di i_size = 937, i_flags = 0x1
         ------------[ cut here ]------------
         kernel BUG at /usr/src/linux/fs/ocfs2/file.c:470!
         invalid opcode: 0000 [#1] SMP
         Modules linked in: ocfs2_stack_user(OEN) ocfs2(OEN) ocfs2_nodemanager ocfs2_stackglue(OEN) quota_tree dlm(OEN) configfs fuse sd_mod    iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi af_packet iscsi_ibft iscsi_boot_sysfs softdog xfs libcrc32c ppdev parport_pc pcspkr parport      joydev virtio_balloon virtio_net i2c_piix4 acpi_cpufreq button processor ext4 crc16 jbd2 mbcache ata_generic cirrus virtio_blk ata_piix               drm_kms_helper ahci syscopyarea libahci sysfillrect sysimgblt fb_sys_fops ttm floppy libata drm virtio_pci virtio_ring uhci_hcd virtio ehci_hcd       usbcore serio_raw usb_common sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
         Supported: No, Unsupported modules are loaded
         CPU: 1 PID: 30154 Comm: truncate Tainted: G           OE   N  4.4.21-69-default #1
         Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
         task: ffff88004ff6d240 ti: ffff880074e68000 task.ti: ffff880074e68000
         RIP: 0010:[<ffffffffa05c8c30>]  [<ffffffffa05c8c30>] ocfs2_truncate_file+0x640/0x6c0 [ocfs2]
         RSP: 0018:ffff880074e6bd50  EFLAGS: 00010282
         RAX: 0000000000000074 RBX: 000000000000029e RCX: 0000000000000000
         RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246
         RBP: ffff880074e6bda8 R08: 000000003675dc7a R09: ffffffff82013414
         R10: 0000000000034c50 R11: 0000000000000000 R12: ffff88003aab3448
         R13: 00000000000002dc R14: 0000000000046e11 R15: 0000000000000020
         FS:  00007f839f965700(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
         CR2: 00007f839f97e000 CR3: 0000000036723000 CR4: 00000000000006e0
         Call Trace:
           ocfs2_setattr+0x698/0xa90 [ocfs2]
           notify_change+0x1ae/0x380
           do_truncate+0x5e/0x90
           do_sys_ftruncate.constprop.11+0x108/0x160
           entry_SYSCALL_64_fastpath+0x12/0x6d
         Code: 24 28 ba d6 01 00 00 48 c7 c6 30 43 62 a0 8b 41 2c 89 44 24 08 48 8b 41 20 48 c7 c1 78 a3 62 a0 48 89 04 24 31 c0 e8 a0 97 f9 ff <0f> 0b 3d 00 fe ff ff 0f 84 ab fd ff ff 83 f8 fc 0f 84 a2 fd ff
         RIP  [<ffffffffa05c8c30>] ocfs2_truncate_file+0x640/0x6c0 [ocfs2]
      
      It's because ocfs2_inode_lock() get us stale LVB in which the i_size is
      not equal to the disk i_size.  We mistakenly trust the LVB because the
      underlaying fsdlm dlm_lock() doesn't set lkb_sbflags with
      DLM_SBF_VALNOTVALID properly for us.  But, why?
      
      The current code tries to downconvert lock without DLM_LKF_VALBLK flag
      to tell o2cb don't update RSB's LVB if it's a PR->NULL conversion, even
      if the lock resource type needs LVB.  This is not the right way for
      fsdlm.
      
      The fsdlm plugin behaves different on DLM_LKF_VALBLK, it depends on
      DLM_LKF_VALBLK to decide if we care about the LVB in the LKB.  If
      DLM_LKF_VALBLK is not set, fsdlm will skip recovering RSB's LVB from
      this lkb and set the right DLM_SBF_VALNOTVALID appropriately when node
      failure happens.
      
      The following diagram briefly illustrates how this crash happens:
      
      RSB1 is inode metadata lock resource with LOCK_TYPE_USES_LVB;
      
      The 1st round:
      
                   Node1                                    Node2
      RSB1: PR
                                                        RSB1(master): NULL->EX
      ocfs2_downconvert_lock(PR->NULL, set_lvb==0)
        ocfs2_dlm_lock(no DLM_LKF_VALBLK)
      
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      
      dlm_lock(no DLM_LKF_VALBLK)
        convert_lock(overwrite lkb->lkb_exflags
                     with no DLM_LKF_VALBLK)
      
      RSB1: NULL                                        RSB1: EX
                                                        reset Node2
      dlm_recover_rsbs()
        recover_lvb()
      
      /* The LVB is not trustable if the node with EX fails and
       * no lock >= PR is left. We should set RSB_VALNOTVALID for RSB1.
       */
      
       if(!(kb_exflags & DLM_LKF_VALBLK)) /* This means we miss the chance to
                 return;                   * to invalid the LVB here.
                                           */
      
      The 2nd round:
      
               Node 1                                Node2
      RSB1(become master from recovery)
      
      ocfs2_setattr()
        ocfs2_inode_lock(NULL->EX)
          /* dlm_lock() return the stale lvb without setting DLM_SBF_VALNOTVALID */
          ocfs2_meta_lvb_is_trustable() return 1 /* so we don't refresh inode from disk */
        ocfs2_truncate_file()
            mlog_bug_on_msg(disk isize != i_size_read(inode))  /* crash! */
      
      The fix is quite straightforward.  We keep to set DLM_LKF_VALBLK flag
      for dlm_lock() if the lock resource type needs LVB and the fsdlm plugin
      is uesed.
      
      Link: http://lkml.kernel.org/r/1481275846-6604-1-git-send-email-zren@suse.comSigned-off-by: default avatarEric Ren <zren@suse.com>
      Reviewed-by: default avatarJoseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      257e62ac
    • Mark Rutland's avatar
      ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs · d49de65c
      Mark Rutland authored
      [ Upstream commit ddc37832 ]
      
      On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
      undefined instruction trap within write_wb_reg. This is because Scorpion
      CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
      the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
      watchpoint registers are treated as undefined.
      
      It's possible to trigger similar crashes later on from userspace, by
      requesting the kernel to install a breakpoint or watchpoint, as we can
      go idle at any point between the reset of the debug registers and their
      later use. This has always been the case.
      
      Given that this has always been broken, no-one has complained until now,
      and there is no clear workaround, disable hardware breakpoints and
      watchpoints on Scorpion to avoid these issues.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d49de65c
    • Johan Hovold's avatar
      USB: serial: kl5kusb105: fix line-state error handling · 301242e3
      Johan Hovold authored
      [ Upstream commit 146cc8a1 ]
      
      The current implementation failed to detect short transfers when
      attempting to read the line state, and also, to make things worse,
      logged the content of the uninitialised heap transfer buffer.
      
      Fixes: abf492e7 ("USB: kl5kusb105: fix DMA buffers on stack")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      301242e3
    • Dennis Kadioglu's avatar
      ALSA: usb-audio: Add a quirk for Plantronics BT600 · 9b1f2ea4
      Dennis Kadioglu authored
      [ Upstream commit 2e40795c ]
      
      Plantronics BT600 does not support reading the sample rate which leads
      to many lines of "cannot get freq at ep 0x1" and "cannot get freq at
      ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and
      avoids those error messages.
      Signed-off-by: default avatarDennis Kadioglu <denk@post.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9b1f2ea4
    • Zhou Chengming's avatar
      sysctl: Drop reference added by grab_header in proc_sys_readdir · 13d7adf6
      Zhou Chengming authored
      [ Upstream commit 93362fa4 ]
      
      Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference
      added by grab_header when return from !dir_emit_dots path.
      It can cause any path called unregister_sysctl_table will
      wait forever.
      
      The calltrace of CVE-2016-9191:
      
      [ 5535.960522] Call Trace:
      [ 5535.963265]  [<ffffffff817cdaaf>] schedule+0x3f/0xa0
      [ 5535.968817]  [<ffffffff817d33fb>] schedule_timeout+0x3db/0x6f0
      [ 5535.975346]  [<ffffffff817cf055>] ? wait_for_completion+0x45/0x130
      [ 5535.982256]  [<ffffffff817cf0d3>] wait_for_completion+0xc3/0x130
      [ 5535.988972]  [<ffffffff810d1fd0>] ? wake_up_q+0x80/0x80
      [ 5535.994804]  [<ffffffff8130de64>] drop_sysctl_table+0xc4/0xe0
      [ 5536.001227]  [<ffffffff8130de17>] drop_sysctl_table+0x77/0xe0
      [ 5536.007648]  [<ffffffff8130decd>] unregister_sysctl_table+0x4d/0xa0
      [ 5536.014654]  [<ffffffff8130deff>] unregister_sysctl_table+0x7f/0xa0
      [ 5536.021657]  [<ffffffff810f57f5>] unregister_sched_domain_sysctl+0x15/0x40
      [ 5536.029344]  [<ffffffff810d7704>] partition_sched_domains+0x44/0x450
      [ 5536.036447]  [<ffffffff817d0761>] ? __mutex_unlock_slowpath+0x111/0x1f0
      [ 5536.043844]  [<ffffffff81167684>] rebuild_sched_domains_locked+0x64/0xb0
      [ 5536.051336]  [<ffffffff8116789d>] update_flag+0x11d/0x210
      [ 5536.057373]  [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450
      [ 5536.064186]  [<ffffffff81167acb>] ? cpuset_css_offline+0x1b/0x60
      [ 5536.070899]  [<ffffffff810fce3d>] ? trace_hardirqs_on+0xd/0x10
      [ 5536.077420]  [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450
      [ 5536.084234]  [<ffffffff8115a9f5>] ? css_killed_work_fn+0x25/0x220
      [ 5536.091049]  [<ffffffff81167ae5>] cpuset_css_offline+0x35/0x60
      [ 5536.097571]  [<ffffffff8115aa2c>] css_killed_work_fn+0x5c/0x220
      [ 5536.104207]  [<ffffffff810bc83f>] process_one_work+0x1df/0x710
      [ 5536.110736]  [<ffffffff810bc7c0>] ? process_one_work+0x160/0x710
      [ 5536.117461]  [<ffffffff810bce9b>] worker_thread+0x12b/0x4a0
      [ 5536.123697]  [<ffffffff810bcd70>] ? process_one_work+0x710/0x710
      [ 5536.130426]  [<ffffffff810c3f7e>] kthread+0xfe/0x120
      [ 5536.135991]  [<ffffffff817d4baf>] ret_from_fork+0x1f/0x40
      [ 5536.142041]  [<ffffffff810c3e80>] ? kthread_create_on_node+0x230/0x230
      
      One cgroup maintainer mentioned that "cgroup is trying to offline
      a cpuset css, which takes place under cgroup_mutex.  The offlining
      ends up trying to drain active usages of a sysctl table which apprently
      is not happening."
      The real reason is that proc_sys_readdir doesn't drop reference added
      by grab_header when return from !dir_emit_dots path. So this cpuset
      offline path will wait here forever.
      
      See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13
      
      Fixes: f0c3b509 ("[readdir] convert procfs")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarCAI Qian <caiqian@redhat.com>
      Tested-by: default avatarYang Shukui <yangshukui@huawei.com>
      Signed-off-by: default avatarZhou Chengming <zhouchengming1@huawei.com>
      Acked-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      13d7adf6
    • Eric W. Biederman's avatar
      mnt: Protect the mountpoint hashtable with mount_lock · 89aca6c9
      Eric W. Biederman authored
      [ Upstream commit 3895dbf8 ]
      
      Protecting the mountpoint hashtable with namespace_sem was sufficient
      until a call to umount_mnt was added to mntput_no_expire.  At which
      point it became possible for multiple calls of put_mountpoint on
      the same hash chain to happen on the same time.
      
      Kristen Johansen <kjlx@templeofstupid.com> reported:
      > This can cause a panic when simultaneous callers of put_mountpoint
      > attempt to free the same mountpoint.  This occurs because some callers
      > hold the mount_hash_lock, while others hold the namespace lock.  Some
      > even hold both.
      >
      > In this submitter's case, the panic manifested itself as a GP fault in
      > put_mountpoint() when it called hlist_del() and attempted to dereference
      > a m_hash.pprev that had been poisioned by another thread.
      
      Al Viro observed that the simple fix is to switch from using the namespace_sem
      to the mount_lock to protect the mountpoint hash table.
      
      I have taken Al's suggested patch moved put_mountpoint in pivot_root
      (instead of taking mount_lock an additional time), and have replaced
      new_mountpoint with get_mountpoint a function that does the hash table
      lookup and addition under the mount_lock.   The introduction of get_mounptoint
      ensures that only the mount_lock is needed to manipulate the mountpoint
      hashtable.
      
      d_set_mounted is modified to only set DCACHE_MOUNTED if it is not
      already set.  This allows get_mountpoint to use the setting of
      DCACHE_MOUNTED to ensure adding a struct mountpoint for a dentry
      happens exactly once.
      
      Cc: stable@vger.kernel.org
      Fixes: ce07d891 ("mnt: Honor MNT_LOCKED when detaching mounts")
      Reported-by: default avatarKrister Johansen <kjlx@templeofstupid.com>
      Suggested-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Acked-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      89aca6c9
    • Johan Hovold's avatar
      USB: serial: ch341: fix open error handling · f8969b94
      Johan Hovold authored
      [ Upstream commit f2950b78 ]
      
      Make sure to stop the interrupt URB before returning on errors during
      open.
      
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f8969b94
    • Johan Hovold's avatar
      USB: serial: ch341: fix modem-control and B0 handling · c72629ab
      Johan Hovold authored
      [ Upstream commit 030ee7ae ]
      
      The modem-control signals are managed by the tty-layer during open and
      should not be asserted prematurely when set_termios is called from
      driver open.
      
      Also make sure that the signals are asserted only when changing speed
      from B0.
      
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c72629ab
    • Johan Hovold's avatar
      USB: serial: ch341: fix open and resume after B0 · f7ee5552
      Johan Hovold authored
      [ Upstream commit a20047f3 ]
      
      The private baud_rate variable is used to configure the port at open and
      reset-resume and must never be set to (and left at) zero or reset-resume
      and all further open attempts will fail.
      
      Fixes: aa91def4 ("USB: ch341: set tty baud speed according to tty
      struct")
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f7ee5552
    • Johan Hovold's avatar
      USB: serial: ch341: fix initial modem-control state · 022104d5
      Johan Hovold authored
      [ Upstream commit 4e2da446 ]
      
      DTR and RTS will be asserted by the tty-layer when the port is opened
      and deasserted on close (if HUPCL is set). Make sure the initial state
      is not-asserted before the port is first opened as well.
      
      Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      022104d5
    • Alex Deucher's avatar
      drm/radeon: drop verde dpm quirks · 49d412ae
      Alex Deucher authored
      [ Upstream commit 8a08403b ]
      
      fixes:
      https://bugs.freedesktop.org/show_bug.cgi?id=98897
      https://bugs.launchpad.net/bugs/1651981Acked-by: default avatarEdward O'Callaghan <funfunctor@folklore1984.net>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Cc: Adrian Fiergolski <A.Fiergolski@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      49d412ae
    • Arvind Yadav's avatar
      ata: sata_mv:- Handle return value of devm_ioremap. · 1a472e4c
      Arvind Yadav authored
      [ Upstream commit 064c3db9 ]
      
      Here, If devm_ioremap will fail. It will return NULL.
      Then hpriv->base = NULL - 0x20000; Kernel can run into
      a NULL-pointer dereference. This error check will avoid
      NULL pointer dereference.
      Signed-off-by: default avatarArvind Yadav <arvind.yadav.cs@gmail.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1a472e4c
    • Damien Le Moal's avatar
      libata: Fix ATA request sense · 87f67424
      Damien Le Moal authored
      [ Upstream commit 2dae9955 ]
      
      For an ATA device supporting the sense data reporting feature set, a
      failed command will trigger the execution of ata_eh_request_sense if
      the result task file of the failed command has the ATA_SENSE bit set
      (sense data available bit). ata_eh_request_sense executes the REQUEST
      SENSE DATA EXT command to retrieve the sense data of the failed
      command. On success of REQUEST SENSE DATA EXT, the ATA_SENSE bit will
      NOT be set (the command succeeded) but ata_eh_request_sense
      nevertheless tests the availability of sense data by testing that bit
      presence in the result tf of the REQUEST SENSE DATA EXT command.  This
      leads us to falsely assume that request sense data failed and to the
      warning message:
      
      atax.xx: request sense failed stat 50 emask 0
      
      Upon success of REQUEST SENSE DATA EXT, set the ATA_SENSE bit in the
      result task file command so that sense data can be returned by
      ata_eh_request_sense.
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      87f67424
    • Dave Martin's avatar
      tile/ptrace: Preserve previous registers for short regset write · d6c83f56
      Dave Martin authored
      [ Upstream commit fd7c9914 ]
      
      Ensure that if userspace supplies insufficient data to
      PTRACE_SETREGSET to fill all the registers, the thread's old
      registers are preserved.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarChris Metcalf <cmetcalf@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d6c83f56
    • Tejun Heo's avatar
      libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices · f24c4f60
      Tejun Heo authored
      [ Upstream commit e0edc8c5 ]
      
      Marko reports that CX1-JB512-HP shows the same timeout issues as
      CX1-JB256-HP.  Let's apply MAX_SEC_128 to all devices in the series.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarMarko Koski-Vähälä <marko@koski-vahala.com>
      Cc: stable@vger.kernel.org # v3.19+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f24c4f60
    • Greg Kroah-Hartman's avatar
      HID: hid-cypress: validate length of report · e0fb4ae6
      Greg Kroah-Hartman authored
      [ Upstream commit 1ebb7114 ]
      
      Make sure we have enough of a report structure to validate before
      looking at it.
      Reported-by: default avatarBenoit Camredon <benoit.camredon@airbus.com>
      Tested-by: default avatarBenoit Camredon <benoit.camredon@airbus.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e0fb4ae6
    • Guenter Roeck's avatar
      Input: elants_i2c - avoid divide by 0 errors on bad touchscreen data · 63d75fa7
      Guenter Roeck authored
      [ Upstream commit 1c3415a0 ]
      
      The following crash may be seen if bad data is received from the
      touchscreen.
      
      [ 2189.425150] elants_i2c i2c-ELAN0001:00: unknown packet ff ff ff ff
      [ 2189.430738] divide error: 0000 [#1] PREEMPT SMP
      [ 2189.434679] gsmi: Log Shutdown Reason 0x03
      [ 2189.434689] Modules linked in: ip6t_REJECT nf_reject_ipv6 rfcomm evdi
      uinput uvcvideo cmac videobuf2_vmalloc videobuf2_memops snd_hda_codec_hdmi
      i2c_dev videobuf2_core snd_soc_sst_cht_bsw_rt5645 snd_hda_intel
      snd_intel_sst_acpi btusb btrtl btbcm btintel bluetooth snd_soc_sst_acpi
      snd_hda_codec snd_intel_sst_core snd_hwdep snd_soc_sst_mfld_platform
      snd_hda_core snd_soc_rt5645 memconsole_x86_legacy memconsole zram snd_soc_rl6231
      fuse ip6table_filter iwlmvm iwlwifi iwl7000_mac80211 cfg80211 iio_trig_sysfs
      joydev cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer
      kfifo_buf industrialio snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq
      snd_seq_device ppp_async ppp_generic slhc tun
      [ 2189.434866] CPU: 0 PID: 106 Comm: irq/184-ELAN000 Tainted: G        W
      3.18.0-13101-g57e8190 #1
      [ 2189.434883] Hardware name: GOOGLE Ultima, BIOS Google_Ultima.7287.131.43 07/20/2016
      [ 2189.434898] task: ffff88017a0b6d80 ti: ffff88017a2bc000 task.ti: ffff88017a2bc000
      [ 2189.434913] RIP: 0010:[<ffffffffbecc48d5>]  [<ffffffffbecc48d5>] elants_i2c_irq+0x190/0x200
      [ 2189.434937] RSP: 0018:ffff88017a2bfd98  EFLAGS: 00010293
      [ 2189.434948] RAX: 0000000000000000 RBX: ffff88017a967828 RCX: ffff88017a9678e8
      [ 2189.434962] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000
      [ 2189.434975] RBP: ffff88017a2bfdd8 R08: 00000000000003e8 R09: 0000000000000000
      [ 2189.434989] R10: 0000000000000000 R11: 000000000044a2bd R12: ffff88017a991800
      [ 2189.435001] R13: ffffffffbe8a2a53 R14: ffff88017a0b6d80 R15: ffff88017a0b6d80
      [ 2189.435011] FS:  0000000000000000(0000) GS:ffff88017fc00000(0000) knlGS:0000000000000000
      [ 2189.435022] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 2189.435030] CR2: 00007f678d94b000 CR3: 000000003f41a000 CR4: 00000000001007f0
      [ 2189.435039] Stack:
      [ 2189.435044]  ffff88017a2bfda8 ffff88017a9678e8 646464647a2bfdd8 0000000006e09574
      [ 2189.435060]  0000000000000000 ffff88017a088b80 ffff88017a921000 ffffffffbe8a2a53
      [ 2189.435074]  ffff88017a2bfe08 ffffffffbe8a2a73 ffff88017a0b6d80 0000000006e09574
      [ 2189.435089] Call Trace:
      [ 2189.435101]  [<ffffffffbe8a2a53>] ? irq_thread_dtor+0xa9/0xa9
      [ 2189.435112]  [<ffffffffbe8a2a73>] irq_thread_fn+0x20/0x40
      [ 2189.435123]  [<ffffffffbe8a2be1>] irq_thread+0x14e/0x222
      [ 2189.435135]  [<ffffffffbee8cbeb>] ? __schedule+0x3b3/0x57a
      [ 2189.435145]  [<ffffffffbe8a29aa>] ? wake_threads_waitq+0x2d/0x2d
      [ 2189.435156]  [<ffffffffbe8a2a93>] ? irq_thread_fn+0x40/0x40
      [ 2189.435168]  [<ffffffffbe87c385>] kthread+0x10e/0x116
      [ 2189.435178]  [<ffffffffbe87c277>] ? __kthread_parkme+0x67/0x67
      [ 2189.435189]  [<ffffffffbee900ac>] ret_from_fork+0x7c/0xb0
      [ 2189.435199]  [<ffffffffbe87c277>] ? __kthread_parkme+0x67/0x67
      [ 2189.435208] Code: ff ff eb 73 0f b6 bb c1 00 00 00 83 ff 03 7e 13 49 8d 7c
      24 20 ba 04 00 00 00 48 c7 c6 8a cd 21 bf eb 4d 0f b6 83 c2 00 00 00 99 <f7> ff
      83 f8 37 75 15 48 6b f7 37 4c 8d a3 c4 00 00 00 4c 8d ac
      [ 2189.435312] RIP  [<ffffffffbecc48d5>] elants_i2c_irq+0x190/0x200
      [ 2189.435323]  RSP <ffff88017a2bfd98>
      [ 2189.435350] ---[ end trace f4945345a75d96dd ]---
      [ 2189.443841] Kernel panic - not syncing: Fatal exception
      [ 2189.444307] Kernel Offset: 0x3d800000 from 0xffffffff81000000
      	(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      [ 2189.444519] gsmi: Log Shutdown Reason 0x02
      
      The problem was seen with a 3.18 based kernel, but there is no reason
      to believe that the upstream code is safe.
      
      Fixes: 66aee900 ("Input: add support for Elan eKTH I2C touchscreens")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      63d75fa7
    • Rolf Eike Beer's avatar
      selftests: do not require bash to run netsocktests testcase · eb7a3d89
      Rolf Eike Beer authored
      [ Upstream commit 3659f98b ]
      
      Nothing in this minimal script seems to require bash. We often run these
      tests on embedded devices where the only shell available is the busybox
      ash. Use sh instead.
      Signed-off-by: default avatarRolf Eike Beer <eb@emlix.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      eb7a3d89
    • Rolf Eike Beer's avatar
      selftests: do not require bash for the generated test · 6d5a0b3b
      Rolf Eike Beer authored
      [ Upstream commit a2b1e8a2 ]
      
      Nothing in this minimal script seems to require bash. We often run these
      tests on embedded devices where the only shell available is the busybox
      ash. Use sh instead.
      Signed-off-by: default avatarRolf Eike Beer <eb@emlix.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6d5a0b3b
    • Alan Stern's avatar
      USB: fix problems with duplicate endpoint addresses · b0de742a
      Alan Stern authored
      [ Upstream commit 0a8fd134 ]
      
      When checking a new device's descriptors, the USB core does not check
      for duplicate endpoint addresses.  This can cause a problem when the
      sysfs files for those endpoints are created; trying to create multiple
      files with the same name will provoke a WARNING:
      
      WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
      sysfs: cannot create duplicate filename
      '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05'
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
       ffff88006bee64c8 ffffffff81f96b8a ffffffff00000001 1ffff1000d7dcc2c
       ffffed000d7dcc24 0000000000000001 0000000041b58ab3 ffffffff8598b510
       ffffffff81f968f8 ffffffff850fee20 ffffffff85cff020 dffffc0000000000
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff8168c88e>] panic+0x1cb/0x3a9 kernel/panic.c:179
       [<ffffffff812b80b4>] __warn+0x1c4/0x1e0 kernel/panic.c:542
       [<ffffffff812b8195>] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
       [<ffffffff819e70ca>] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30
       [<ffffffff819e7308>] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59
       [<     inline     >] create_dir lib/kobject.c:71
       [<ffffffff81fa1b07>] kobject_add_internal+0x227/0xa60 lib/kobject.c:229
       [<     inline     >] kobject_add_varg lib/kobject.c:366
       [<ffffffff81fa2479>] kobject_add+0x139/0x220 lib/kobject.c:411
       [<ffffffff82737a63>] device_add+0x353/0x1660 drivers/base/core.c:1088
       [<ffffffff82738d8d>] device_register+0x1d/0x20 drivers/base/core.c:1206
       [<ffffffff82cb77d3>] usb_create_ep_devs+0x163/0x260 drivers/usb/core/endpoint.c:195
       [<ffffffff82c9f27b>] create_intf_ep_devs+0x13b/0x200 drivers/usb/core/message.c:1030
       [<ffffffff82ca39d3>] usb_set_configuration+0x1083/0x18d0 drivers/usb/core/message.c:1937
       [<ffffffff82cc9e2e>] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172
       [<ffffffff82caa7fa>] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263
      
      This patch prevents the problem by checking for duplicate endpoint
      addresses during enumeration and skipping any duplicates.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b0de742a
    • Oliver Neukum's avatar
      usb: storage: unusual_uas: Add JMicron JMS56x to unusual device · d3258941
      Oliver Neukum authored
      [ Upstream commit 674aea07 ]
      
      This device gives the following error on detection.
      xhci_hcd 0000:00:11.0: ERROR Transfer event for disabled endpoint or
      incorrect stream ring
      
      The same error is not seen when it is added to unusual_device
      list with US_FL_NO_REPORT_OPCODES passed.
      Signed-off-by: default avatarGeorge Cherian <george.cherian@cavium.com>
      Signed-off-by: default avatarOliver Neukum <oneukun@suse.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d3258941
    • Bin Liu's avatar
      usb: musb: dsps: implement clear_ep_rxintr() callback · 0f6b70a5
      Bin Liu authored
      [ Upstream commit c48400ba ]
      
      During dma teardown for dequque urb, if musb load is high, musb might
      generate bogus rx ep interrupt even when the rx fifo is flushed. In such
      case any of the follow log messages could happen.
      
          musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0
      
          musb_host_rx 1936: RX3 dma busy, csr 2020
      
      As mentioned in the current inline comment, clearing ep interrupt in the
      teardown path avoids the bogus interrupt, so implement clear_ep_rxintr()
      callback.
      
      This bug seems to be existing since the initial driver for musb support,
      but I only validated the fix back to v4.1, so only cc stable for v4.1+.
      
      cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0f6b70a5
    • Bin Liu's avatar
      usb: musb: core: add clear_ep_rxintr() to musb_platform_ops · 088f5497
      Bin Liu authored
      [ Upstream commit 6def85a3 ]
      
      During dma teardown for dequque urb, if musb load is high, musb might
      generate bogus rx ep interrupt even when the rx fifo is flushed. In such
      case any of the follow log messages could happen.
      
      	musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0
      
      	musb_host_rx 1936: RX3 dma busy, csr 2020
      
      As mentioned in the current inline comment, clearing ep interrupt in the
      teardown path avoids the bogus interrupt.
      
      Clearing ep interrupt is platform dependent, so this patch adds a
      platform callback to allow glue driver to clear the ep interrupt.
      
      This bug seems to be existing since the initial driver for musb support,
      but I only validated the fix back to v4.1, so only cc stable for v4.1+.
      
      cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      088f5497