1. 28 Mar, 2018 19 commits
    • Hans de Goede's avatar
      libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version · fc0d81cf
      Hans de Goede authored
      commit d418ff56 upstream.
      
      When commit 9c7be59f ("libata: Apply NOLPM quirk to Crucial MX100
      512GB SSDs") was added it inherited the ATA_HORKAGE_NO_NCQ_TRIM quirk
      from the existing "Crucial_CT*MX100*" entry, but that entry sets model_rev
      to "MU01", where as the entry adding the NOLPM quirk sets it to NULL.
      
      This means that after this commit we no apply the NO_NCQ_TRIM quirk to
      all "Crucial_CT512MX100*" SSDs even if they have the fixed "MU02"
      firmware. This commit splits the "Crucial_CT512MX100*" quirk into 2
      quirks, one for the "MU01" firmware and one for all other firmware
      versions, so that we once again only apply the NO_NCQ_TRIM quirk to the
      "MU01" firmware version.
      
      Fixes: 9c7be59f ("libata: Apply NOLPM quirk to ... MX100 512GB SSDs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc0d81cf
    • Hans de Goede's avatar
      libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions · e32afd33
      Hans de Goede authored
      commit 3bf7b5d6 upstream.
      
      Commit b17e5729 ("libata: disable LPM for Crucial BX100 SSD 500GB
      drive"), introduced a ATA_HORKAGE_NOLPM quirk for Crucial BX100 500GB SSDs
      but limited this to the MU02 firmware version, according to:
      http://www.crucial.com/usa/en/support-ssd-firmware
      
      MU02 is the last version, so there are no newer possibly fixed versions
      and if the MU02 version has broken LPM then the MU01 almost certainly
      also has broken LPM, so this commit changes the quirk to apply to all
      firmware versions.
      
      Fixes: b17e5729 ("libata: disable LPM for Crucial BX100 SSD 500GB...")
      Cc: stable@vger.kernel.org
      Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e32afd33
    • Hans de Goede's avatar
      libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs · 4c1c7a82
      Hans de Goede authored
      commit 62ac3f73 upstream.
      
      There have been reports of the Crucial M500 480GB model not working
      with LPM set to min_power / med_power_with_dipm level.
      
      It has not been tested with medium_power, but that typically has no
      measurable power-savings.
      
      Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03
      and there is a MU05 update available, but that update does not mention any
      LPM fixes in its changelog, so the quirk matches all firmware versions.
      
      In my experience the LPM problems with (older) Crucial SSDs seem to be
      limited to higher capacity versions of the SSDs (different firmware?),
      so this commit adds a NOLPM quirk for the 480 and 960GB versions of the
      M500, to avoid LPM causing issues with these SSDs.
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: default avatarMartin Steigerwald <martin@lichtvoll.de>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c1c7a82
    • Ju Hyung Park's avatar
      libata: Enable queued TRIM for Samsung SSD 860 · f2e5f241
      Ju Hyung Park authored
      commit ca6bfcb2 upstream.
      
      Samsung explicitly states that queued TRIM is supported for Linux with
      860 PRO and 860 EVO.
      
      Make the previous blacklist to cover only 840 and 850 series.
      Signed-off-by: default avatarPark Ju Hyung <qkrwngud825@gmail.com>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2e5f241
    • Kai-Heng Feng's avatar
      libata: disable LPM for Crucial BX100 SSD 500GB drive · 6ebd126d
      Kai-Heng Feng authored
      commit b17e5729 upstream.
      
      After Laptop Mode Tools starts to use min_power for LPM, a user found
      out Crucial BX100 SSD can't get mounted.
      
      Crucial BX100 SSD 500GB drive don't work well with min_power. This also
      happens to med_power_with_dipm.
      
      So let's disable LPM for Crucial BX100 SSD 500GB drive.
      
      BugLink: https://bugs.launchpad.net/bugs/1726930Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ebd126d
    • Hans de Goede's avatar
      libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs · 2b69573c
      Hans de Goede authored
      commit 9c7be59f upstream.
      
      Various people have reported the Crucial MX100 512GB model not working
      with LPM set to min_power. I've now received a report that it also does
      not work with the new med_power_with_dipm level.
      
      It does work with medium_power, but that has no measurable power-savings
      and given the amount of people being bitten by the other levels not
      working, this commit just disables LPM altogether.
      
      Note all reporters of this have either the 512GB model (max capacity), or
      are not specifying their SSD's size. So for now this quirk assumes this is
      a problem with the 512GB model only.
      
      Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=89261
      Buglink: https://github.com/linrunner/TLP/issues/84
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b69573c
    • Eric Biggers's avatar
      libata: remove WARN() for DMA or PIO command without data · 5442db31
      Eric Biggers authored
      commit 9173e5e8 upstream.
      
      syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0.  This
      happened because it issued a READ_6 command with no data buffer.
      
      Just remove the WARN(), as it doesn't appear indicate a kernel bug.  The
      expected behavior is to fail the command, which the code does.
      
      Here's a reproducer that works in QEMU when /dev/sg0 refers to a disk of
      the default type ("82371SB PIIX3 IDE"):
      
          #include <fcntl.h>
          #include <unistd.h>
      
          int main()
          {
                  char buf[42] = { [36] = 0x8 /* READ_6 */ };
      
                  write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
          }
      
      Fixes: f92a2636 ("libata: change ATA_QCFLAG_DMAMAP semantics")
      Reported-by: syzbot+f7b556d1766502a69d85071d2ff08bd87be53d0f@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org> # v2.6.25+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5442db31
    • Eric Biggers's avatar
      libata: fix length validation of ATAPI-relayed SCSI commands · e80ce18a
      Eric Biggers authored
      commit 058f58e2 upstream.
      
      syzkaller reported a crash in ata_bmdma_fill_sg() when writing to
      /dev/sg1.  The immediate cause was that the ATA command's scatterlist
      was not DMA-mapped, which causes 'pi - 1' to underflow, resulting in a
      write to 'qc->ap->bmdma_prd[0xffffffff]'.
      
      Strangely though, the flag ATA_QCFLAG_DMAMAP was set in qc->flags.  The
      root cause is that when __ata_scsi_queuecmd() is preparing to relay a
      SCSI command to an ATAPI device, it doesn't correctly validate the CDB
      length before copying it into the 16-byte buffer 'cdb' in 'struct
      ata_queued_cmd'.  Namely, it validates the fixed CDB length expected
      based on the SCSI opcode but not the actual CDB length, which can be
      larger due to the use of the SG_NEXT_CMD_LEN ioctl.  Since 'flags' is
      the next member in ata_queued_cmd, a buffer overflow corrupts it.
      
      Fix it by requiring that the actual CDB length be <= 16 (ATAPI_CDB_LEN).
      
      [Really it seems the length should be required to be <= dev->cdb_len,
      but the current behavior seems to have been intentionally introduced by
      commit 607126c2 ("libata-scsi: be tolerant of 12-byte ATAPI commands
      in 16-byte CDBs") to work around a userspace bug in mplayer.  Probably
      the workaround is no longer needed (mplayer was fixed in 2007), but
      continuing to allow lengths to up 16 appears harmless for now.]
      
      Here's a reproducer that works in QEMU when /dev/sg1 refers to the
      CD-ROM drive that qemu-system-x86_64 creates by default:
      
          #include <fcntl.h>
          #include <sys/ioctl.h>
          #include <unistd.h>
      
          #define SG_NEXT_CMD_LEN 0x2283
      
          int main()
          {
      	    char buf[53] = { [36] = 0x7e, [52] = 0x02 };
      	    int fd = open("/dev/sg1", O_RDWR);
      	    ioctl(fd, SG_NEXT_CMD_LEN, &(int){ 17 });
      	    write(fd, buf, sizeof(buf));
          }
      
      The crash was:
      
          BUG: unable to handle kernel paging request at ffff8cb97db37ffc
          IP: ata_bmdma_fill_sg drivers/ata/libata-sff.c:2623 [inline]
          IP: ata_bmdma_qc_prep+0xa4/0xc0 drivers/ata/libata-sff.c:2727
          PGD fb6c067 P4D fb6c067 PUD 0
          Oops: 0002 [#1] SMP
          CPU: 1 PID: 150 Comm: syz_ata_bmdma_q Not tainted 4.15.0-next-20180202 #99
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
          [...]
          Call Trace:
           ata_qc_issue+0x100/0x1d0 drivers/ata/libata-core.c:5421
           ata_scsi_translate+0xc9/0x1a0 drivers/ata/libata-scsi.c:2024
           __ata_scsi_queuecmd drivers/ata/libata-scsi.c:4326 [inline]
           ata_scsi_queuecmd+0x8c/0x210 drivers/ata/libata-scsi.c:4375
           scsi_dispatch_cmd+0xa2/0xe0 drivers/scsi/scsi_lib.c:1727
           scsi_request_fn+0x24c/0x530 drivers/scsi/scsi_lib.c:1865
           __blk_run_queue_uncond block/blk-core.c:412 [inline]
           __blk_run_queue+0x3a/0x60 block/blk-core.c:432
           blk_execute_rq_nowait+0x93/0xc0 block/blk-exec.c:78
           sg_common_write.isra.7+0x272/0x5a0 drivers/scsi/sg.c:806
           sg_write+0x1ef/0x340 drivers/scsi/sg.c:677
           __vfs_write+0x31/0x160 fs/read_write.c:480
           vfs_write+0xa7/0x160 fs/read_write.c:544
           SYSC_write fs/read_write.c:589 [inline]
           SyS_write+0x4d/0xc0 fs/read_write.c:581
           do_syscall_64+0x5e/0x110 arch/x86/entry/common.c:287
           entry_SYSCALL_64_after_hwframe+0x21/0x86
      
      Fixes: 607126c2 ("libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs")
      Reported-by: syzbot+1ff6f9fcc3c35f1c72a95e26528c8e7e3276e4da@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org> # v2.6.24+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e80ce18a
    • Takashi Iwai's avatar
      Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 · b5533179
      Takashi Iwai authored
      commit f44cb4b1 upstream.
      
      The Atheros 1525/QCA6174 BT doesn't seem working properly on the
      recent kernels, as it tries to load a wrong firmware
      ar3k/AthrBT_0x00000200.dfu and it fails.
      
      This seems to have been a problem for some time, and the known
      workaround is to apply BTUSB_QCA_ROM quirk instead of BTUSB_ATH3012.
      
      The device in question is:
      
      T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#=  4 Spd=12   MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P: Vendor=0cf3 ProdID=3004 Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E: Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E: Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      
      Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504Reported-by: default avatarIvan Levshin <ivan.levshin@microfocus.com>
      Tested-by: default avatarIvan Levshin <ivan.levshin@microfocus.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5533179
    • Boris Brezillon's avatar
      clk: bcm2835: Protect sections updating shared registers · 0ff60326
      Boris Brezillon authored
      commit 7997f3b2 upstream.
      
      CM_PLLx and A2W_XOSC_CTRL registers are accessed by different clock
      handlers and must be accessed with ->regs_lock held.
      Update the sections where this protection is missing.
      
      Fixes: 41691b88 ("clk: bcm2835: Add support for programming the audio domain clocks")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ff60326
    • Hans de Goede's avatar
      ahci: Add PCI-id for the Highpoint Rocketraid 644L card · e298da75
      Hans de Goede authored
      commit 28b2182d upstream.
      
      Like the Highpoint Rocketraid 642L and cards using a Marvel 88SE9235
      controller in general, this RAID card also supports AHCI mode and short
      of a custom driver, this is the only way to make it work under Linux.
      
      Note that even though the card is called to 644L, it has a product-id
      of 0x0645.
      
      Cc: stable@vger.kernel.org
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e298da75
    • Hans de Goede's avatar
      PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L · 494644c5
      Hans de Goede authored
      commit 1903be82 upstream.
      
      The Highpoint RocketRAID 644L uses a Marvel 88SE9235 controller, as with
      other Marvel controllers this needs a function 1 DMA alias quirk.
      
      Note the RocketRAID 642L uses the same Marvel 88SE9235 controller and
      already is listed with a function 1 DMA alias quirk.
      
      Cc: stable@vger.kernel.org
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      494644c5
    • Evgeniy Didin's avatar
      mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs · aaf6dfbd
      Evgeniy Didin authored
      commit 47b7de2f upstream.
      
      It was found that in IDMAC mode after soft-reset driver switches
      to PIO mode.
      
      That's what happens in case of DTO timeout overflow calculation failure:
      1. soft-reset is called
      2. driver restarts dma
      3. descriptors states are checked, one of descriptor is owned by the IDMAC.
      4. driver can't use DMA and then switches to PIO mode.
      
      Failure was already fixed in:
      https://www.spinics.net/lists/linux-mmc/msg48125.html.
      
      Behaviour while soft-reset is not something we except or
      even want to happen. So we switch from dw_mci_idmac_reset
      to dw_mci_idmac_init, so descriptors are cleaned before starting dma.
      
      And while at it explicitly zero des0 which otherwise might
      contain garbage as being allocated by dmam_alloc_coherent().
      Signed-off-by: default avatarEvgeniy Didin <Evgeniy.Didin@synopsys.com>
      Cc: Jaehoon Chung <jh80.chung@samsung.com>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
      Cc: Shawn Lin <shawn.lin@rock-chips.com>
      Cc: Alexey Brodkin <abrodkin@synopsys.com>
      Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: <stable@vger.kernel.org> # 4.4+
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aaf6dfbd
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Always immediately update mute LED with pin VREF · ae5b1417
      Takashi Iwai authored
      commit e40bdb03 upstream.
      
      Some HP laptops have a mute mute LED controlled by a pin VREF.  The
      Realtek codec driver updates the VREF via vmaster hook by calling
      snd_hda_set_pin_ctl_cache().
      
      This works fine as long as the driver is running in a normal mode.
      However, when the VREF change happens during the codec being in
      runtime PM suspend, the regmap access will skip and postpone the
      actual register change.  This ends up with the unchanged LED status
      until the next runtime PM resume even if you change the Master mute
      switch.  (Interestingly, the machine keeps the LED status even after
      the codec goes into D3 -- but it's another story.)
      
      For improving this usability, let the driver temporarily powering up /
      down only during the pin VREF change.  This can be achieved easily by
      wrapping the call with snd_hda_power_up_pm() / *_down_pm().
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae5b1417
    • Takashi Iwai's avatar
      ALSA: aloop: Fix access to not-yet-ready substream via cable · 5e6d308f
      Takashi Iwai authored
      commit 8e6b1a72 upstream.
      
      In loopback_open() and loopback_close(), we assign and release the
      substream object to the corresponding cable in a racy way.  It's
      neither locked nor done in the right position.  The open callback
      assigns the substream before its preparation finishes, hence the other
      side of the cable may pick it up, which may lead to the invalid memory
      access.
      
      This patch addresses these: move the assignment to the end of the open
      callback, and wrap with cable->lock for avoiding concurrent accesses.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e6d308f
    • Takashi Iwai's avatar
      ALSA: aloop: Sync stale timer before release · eba92f15
      Takashi Iwai authored
      commit 67a01afa upstream.
      
      The aloop driver tries to stop the pending timer via timer_del() in
      the trigger callback and in the close callback.  The former is
      correct, as it's an atomic operation, while the latter expects that
      the timer gets really removed and proceeds the resource releases after
      that.  But timer_del() doesn't synchronize, hence the running timer
      may still access the released resources.
      
      A similar situation can be also seen in the prepare callback after
      trigger(STOP) where the prepare tries to re-initialize the things
      while a timer is still running.
      
      The problems like the above are seen indirectly in some syzkaller
      reports (although it's not 100% clear whether this is the only cause,
      as the race condition is quite narrow and not always easy to
      trigger).
      
      For addressing these issues, this patch adds the explicit alls of
      timer_del_sync() in some places, so that the pending timer is properly
      killed / synced.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eba92f15
    • Kirill Marinushkin's avatar
      ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit · 87eccc3c
      Kirill Marinushkin authored
      commit a6618f4a upstream.
      
      Currently, the offsets in the UAC2 processing unit descriptor are
      calculated incorrectly. It causes an issue when connecting the device which
      provides such a feature:
      
      ~~~~
      [84126.724420] usb 1-1.3.1: invalid Processing Unit descriptor (id 18)
      ~~~~
      
      After this patch is applied, the UAC2 processing unit inits w/o this error.
      
      Fixes: 23caaf19 ("ALSA: usb-mixer: Add support for Audio Class v2.0")
      Signed-off-by: default avatarKirill Marinushkin <k.marinushkin@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87eccc3c
    • Michael Nosthoff's avatar
      iio: st_pressure: st_accel: pass correct platform data to init · 8e1f1062
      Michael Nosthoff authored
      commit 8b438686 upstream.
      
      Commit 7383d44b added a pointer pdata which get set to the default
      platform_data when non was defined in the device. But it did not
      pass this pointer to the st_sensors_init_sensor call but still
      used the maybe uninitialized platform_data from dev.
      
      This breaks initialization when no platform_data is given and
      the optional st,drdy-int-pin devicetree option is not set.
      
      This commit fixes this.
      
      Cc: stable@vger.kernel.org
      Fixes: 7383d44b ("iio: st_pressure: st_accel: Initialise sensor platform data properly")
      Signed-off-by: default avatarMichael Nosthoff <committed@heine.so>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e1f1062
    • NeilBrown's avatar
      MIPS: ralink: Remove ralink_halt() · f56bf442
      NeilBrown authored
      commit 891731f6 upstream.
      
      ralink_halt() does nothing that machine_halt() doesn't already do, so it
      adds no value.
      
      It actually causes incorrect behaviour due to the "unreachable()" at the
      end. This tells the compiler that the end of the function will never be
      reached, which isn't true. The compiler responds by not adding a
      'return' instruction, so control simply moves on to whatever bytes come
      afterwards in memory. In my tested, that was the ralink_restart()
      function. This means that an attempt to 'halt' the machine would
      actually cause a reboot.
      
      So remove ralink_halt() so that a 'halt' really does halt.
      
      Fixes: c06e836a ("MIPS: ralink: adds reset code")
      Signed-off-by: default avatarNeilBrown <neil@brown.name>
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.9+
      Patchwork: https://patchwork.linux-mips.org/patch/18851/Signed-off-by: default avatarJames Hogan <jhogan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f56bf442
  2. 24 Mar, 2018 21 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.124 · b766b14a
      Greg Kroah-Hartman authored
      b766b14a
    • Leon Romanovsky's avatar
      RDMA/ucma: Fix access to non-initialized CM_ID object · 0211db68
      Leon Romanovsky authored
      commit 7688f2c3 upstream.
      
      The attempt to join multicast group without ensuring that CMA device
      exists will lead to the following crash reported by syzkaller.
      
      [   64.076794] BUG: KASAN: null-ptr-deref in rdma_join_multicast+0x26e/0x12c0
      [   64.076797] Read of size 8 at addr 00000000000000b0 by task join/691
      [   64.076797]
      [   64.076800] CPU: 1 PID: 691 Comm: join Not tainted 4.16.0-rc1-00219-gb97853b65b93 #23
      [   64.076802] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-proj4
      [   64.076803] Call Trace:
      [   64.076809]  dump_stack+0x5c/0x77
      [   64.076817]  kasan_report+0x163/0x380
      [   64.085859]  ? rdma_join_multicast+0x26e/0x12c0
      [   64.086634]  rdma_join_multicast+0x26e/0x12c0
      [   64.087370]  ? rdma_disconnect+0xf0/0xf0
      [   64.088579]  ? __radix_tree_replace+0xc3/0x110
      [   64.089132]  ? node_tag_clear+0x81/0xb0
      [   64.089606]  ? idr_alloc_u32+0x12e/0x1a0
      [   64.090517]  ? __fprop_inc_percpu_max+0x150/0x150
      [   64.091768]  ? tracing_record_taskinfo+0x10/0xc0
      [   64.092340]  ? idr_alloc+0x76/0xc0
      [   64.092951]  ? idr_alloc_u32+0x1a0/0x1a0
      [   64.093632]  ? ucma_process_join+0x23d/0x460
      [   64.094510]  ucma_process_join+0x23d/0x460
      [   64.095199]  ? ucma_migrate_id+0x440/0x440
      [   64.095696]  ? futex_wake+0x10b/0x2a0
      [   64.096159]  ucma_join_multicast+0x88/0xe0
      [   64.096660]  ? ucma_process_join+0x460/0x460
      [   64.097540]  ? _copy_from_user+0x5e/0x90
      [   64.098017]  ucma_write+0x174/0x1f0
      [   64.098640]  ? ucma_resolve_route+0xf0/0xf0
      [   64.099343]  ? rb_erase_cached+0x6c7/0x7f0
      [   64.099839]  __vfs_write+0xc4/0x350
      [   64.100622]  ? perf_syscall_enter+0xe4/0x5f0
      [   64.101335]  ? kernel_read+0xa0/0xa0
      [   64.103525]  ? perf_sched_cb_inc+0xc0/0xc0
      [   64.105510]  ? syscall_exit_register+0x2a0/0x2a0
      [   64.107359]  ? __switch_to+0x351/0x640
      [   64.109285]  ? fsnotify+0x899/0x8f0
      [   64.111610]  ? fsnotify_unmount_inodes+0x170/0x170
      [   64.113876]  ? __fsnotify_update_child_dentry_flags+0x30/0x30
      [   64.115813]  ? ring_buffer_record_is_on+0xd/0x20
      [   64.117824]  ? __fget+0xa8/0xf0
      [   64.119869]  vfs_write+0xf7/0x280
      [   64.122001]  SyS_write+0xa1/0x120
      [   64.124213]  ? SyS_read+0x120/0x120
      [   64.126644]  ? SyS_read+0x120/0x120
      [   64.128563]  do_syscall_64+0xeb/0x250
      [   64.130732]  entry_SYSCALL_64_after_hwframe+0x21/0x86
      [   64.132984] RIP: 0033:0x7f5c994ade99
      [   64.135699] RSP: 002b:00007f5c99b97d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [   64.138740] RAX: ffffffffffffffda RBX: 00000000200001e4 RCX: 00007f5c994ade99
      [   64.141056] RDX: 00000000000000a0 RSI: 00000000200001c0 RDI: 0000000000000015
      [   64.143536] RBP: 00007f5c99b97ec0 R08: 0000000000000000 R09: 0000000000000000
      [   64.146017] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5c99b97fc0
      [   64.148608] R13: 0000000000000000 R14: 00007fff660e1c40 R15: 00007f5c99b989c0
      [   64.151060]
      [   64.153703] Disabling lock debugging due to kernel taint
      [   64.156032] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
      [   64.159066] IP: rdma_join_multicast+0x26e/0x12c0
      [   64.161451] PGD 80000001d0298067 P4D 80000001d0298067 PUD 1dea39067 PMD 0
      [   64.164442] Oops: 0000 [#1] SMP KASAN PTI
      [   64.166817] CPU: 1 PID: 691 Comm: join Tainted: G    B 4.16.0-rc1-00219-gb97853b65b93 #23
      [   64.170004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-proj4
      [   64.174985] RIP: 0010:rdma_join_multicast+0x26e/0x12c0
      [   64.177246] RSP: 0018:ffff8801c8207860 EFLAGS: 00010282
      [   64.179901] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff94789522
      [   64.183344] RDX: 1ffffffff2d50fa5 RSI: 0000000000000297 RDI: 0000000000000297
      [   64.186237] RBP: ffff8801c8207a50 R08: 0000000000000000 R09: ffffed0039040ea7
      [   64.189328] R10: 0000000000000001 R11: ffffed0039040ea6 R12: 0000000000000000
      [   64.192634] R13: 0000000000000000 R14: ffff8801e2022800 R15: ffff8801d4ac2400
      [   64.196105] FS:  00007f5c99b98700(0000) GS:ffff8801e5d00000(0000) knlGS:0000000000000000
      [   64.199211] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   64.202046] CR2: 00000000000000b0 CR3: 00000001d1c48004 CR4: 00000000003606a0
      [   64.205032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   64.208221] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   64.211554] Call Trace:
      [   64.213464]  ? rdma_disconnect+0xf0/0xf0
      [   64.216124]  ? __radix_tree_replace+0xc3/0x110
      [   64.219337]  ? node_tag_clear+0x81/0xb0
      [   64.222140]  ? idr_alloc_u32+0x12e/0x1a0
      [   64.224422]  ? __fprop_inc_percpu_max+0x150/0x150
      [   64.226588]  ? tracing_record_taskinfo+0x10/0xc0
      [   64.229763]  ? idr_alloc+0x76/0xc0
      [   64.232186]  ? idr_alloc_u32+0x1a0/0x1a0
      [   64.234505]  ? ucma_process_join+0x23d/0x460
      [   64.237024]  ucma_process_join+0x23d/0x460
      [   64.240076]  ? ucma_migrate_id+0x440/0x440
      [   64.243284]  ? futex_wake+0x10b/0x2a0
      [   64.245302]  ucma_join_multicast+0x88/0xe0
      [   64.247783]  ? ucma_process_join+0x460/0x460
      [   64.250841]  ? _copy_from_user+0x5e/0x90
      [   64.253878]  ucma_write+0x174/0x1f0
      [   64.257008]  ? ucma_resolve_route+0xf0/0xf0
      [   64.259877]  ? rb_erase_cached+0x6c7/0x7f0
      [   64.262746]  __vfs_write+0xc4/0x350
      [   64.265537]  ? perf_syscall_enter+0xe4/0x5f0
      [   64.267792]  ? kernel_read+0xa0/0xa0
      [   64.270358]  ? perf_sched_cb_inc+0xc0/0xc0
      [   64.272575]  ? syscall_exit_register+0x2a0/0x2a0
      [   64.275367]  ? __switch_to+0x351/0x640
      [   64.277700]  ? fsnotify+0x899/0x8f0
      [   64.280530]  ? fsnotify_unmount_inodes+0x170/0x170
      [   64.283156]  ? __fsnotify_update_child_dentry_flags+0x30/0x30
      [   64.286182]  ? ring_buffer_record_is_on+0xd/0x20
      [   64.288749]  ? __fget+0xa8/0xf0
      [   64.291136]  vfs_write+0xf7/0x280
      [   64.292972]  SyS_write+0xa1/0x120
      [   64.294965]  ? SyS_read+0x120/0x120
      [   64.297474]  ? SyS_read+0x120/0x120
      [   64.299751]  do_syscall_64+0xeb/0x250
      [   64.301826]  entry_SYSCALL_64_after_hwframe+0x21/0x86
      [   64.304352] RIP: 0033:0x7f5c994ade99
      [   64.306711] RSP: 002b:00007f5c99b97d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [   64.309577] RAX: ffffffffffffffda RBX: 00000000200001e4 RCX: 00007f5c994ade99
      [   64.312334] RDX: 00000000000000a0 RSI: 00000000200001c0 RDI: 0000000000000015
      [   64.315783] RBP: 00007f5c99b97ec0 R08: 0000000000000000 R09: 0000000000000000
      [   64.318365] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5c99b97fc0
      [   64.320980] R13: 0000000000000000 R14: 00007fff660e1c40 R15: 00007f5c99b989c0
      [   64.323515] Code: e8 e8 79 08 ff 4c 89 ff 45 0f b6 a7 b8 01 00 00 e8 68 7c 08 ff 49 8b 1f 4d 89 e5 49 c1 e4 04 48 8
      [   64.330753] RIP: rdma_join_multicast+0x26e/0x12c0 RSP: ffff8801c8207860
      [   64.332979] CR2: 00000000000000b0
      [   64.335550] ---[ end trace 0c00c17a408849c1 ]---
      
      Reported-by: <syzbot+e6aba77967bd72cbc9d6@syzkaller.appspotmail.com>
      Fixes: c8f6a362 ("RDMA/cma: Add multicast communication support")
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarSean Hefty <sean.hefty@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0211db68
    • Vignesh R's avatar
      dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 · 09b69e6f
      Vignesh R authored
      
      [ Upstream commit d087f157 ]
      
      Register layout of a typical TPCC_EVT_MUX_M_N register is such that the
      lowest numbered event is at the lowest byte address and highest numbered
      event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is
      different,  in that the lowest numbered event is at the highest address
      and highest numbered event is at the lowest address. Therefore, modify
      ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register
      accordingly.
      Signed-off-by: default avatarVignesh R <vigneshr@ti.com>
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09b69e6f
    • Sergej Sawazki's avatar
      clk: si5351: Rename internal plls to avoid name collisions · f6749758
      Sergej Sawazki authored
      
      [ Upstream commit cdba9a4f ]
      
      This drivers probe fails due to a clock name collision if a clock named
      'plla' or 'pllb' is already registered when registering this drivers
      internal plls.
      
      Fix it by renaming internal plls to avoid name collisions.
      
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Rabeeh Khoury <rabeeh@solid-run.com>
      Signed-off-by: default avatarSergej Sawazki <sergej@taudac.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6749758
    • Benjamin Coddington's avatar
      nfsd4: permit layoutget of executable-only files · 5c503ff4
      Benjamin Coddington authored
      
      [ Upstream commit 66282ec1 ]
      
      Clients must be able to read a file in order to execute it, and for pNFS
      that means the client needs to be able to perform a LAYOUTGET on the file.
      
      This behavior for executable-only files was added for OPEN in commit
      a043226b "nfsd4: permit read opens of executable-only files".
      
      This fixes up xfstests generic/126 on block/scsi layouts.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c503ff4
    • Anton Vasilyev's avatar
      RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS · 9bf0b8a6
      Anton Vasilyev authored
      
      [ Upstream commit 74482086 ]
      
      Debugfs file reset_stats is created with S_IRUSR permissions,
      but ocrdma_dbgfs_ops_read() doesn't support OCRDMA_RESET_STATS,
      whereas ocrdma_dbgfs_ops_write() supports only OCRDMA_RESET_STATS.
      
      The patch fixes misstype with permissions.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAnton Vasilyev <vasilyev@ispras.ru>
      Acked-by: default avatarSelvin Xavier <selvin.xavier@broadcom.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9bf0b8a6
    • Alexey Kodanev's avatar
      ip6_vti: adjust vti mtu according to mtu of lower device · 2fe832c6
      Alexey Kodanev authored
      
      [ Upstream commit 53c81e95 ]
      
      LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams over
      ip6_vti that require fragmentation and the underlying device has an
      MTU smaller than 1500 plus some extra space for headers. This happens
      because ip6_vti, by default, sets MTU to ETH_DATA_LEN and not updating
      it depending on a destination address or link parameter. Further
      attempts to send UDP packets may succeed because pmtu gets updated on
      ICMPV6_PKT_TOOBIG in vti6_err().
      
      In case the lower device has larger MTU size, e.g. 9000, ip6_vti works
      but not using the possible maximum size, output packets have 1500 limit.
      
      The above cases require manual MTU setup after ip6_vti creation. However
      ip_vti already updates MTU based on lower device with ip_tunnel_bind_dev().
      
      Here is the example when the lower device MTU is set to 9000:
      
        # ip a sh ltp_ns_veth2
            ltp_ns_veth2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 ...
              inet 10.0.0.2/24 scope global ltp_ns_veth2
              inet6 fd00::2/64 scope global
      
        # ip li add vti6 type vti6 local fd00::2 remote fd00::1
        # ip li show vti6
            vti6@NONE: <POINTOPOINT,NOARP> mtu 1500 ...
              link/tunnel6 fd00::2 peer fd00::1
      
      After the patch:
        # ip li add vti6 type vti6 local fd00::2 remote fd00::1
        # ip li show vti6
            vti6@NONE: <POINTOPOINT,NOARP> mtu 8832 ...
              link/tunnel6 fd00::2 peer fd00::1
      Reported-by: default avatarPetr Vorel <pvorel@suse.cz>
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2fe832c6
    • Jerry Snitselaar's avatar
      iommu/vt-d: clean up pr_irq if request_threaded_irq fails · fb4ff6c7
      Jerry Snitselaar authored
      
      [ Upstream commit 72d54811 ]
      
      It is unlikely request_threaded_irq will fail, but if it does for some
      reason we should clear iommu->pr_irq in the error path. Also
      intel_svm_finish_prq shouldn't try to clean up the page request
      interrupt if pr_irq is 0. Without these, if request_threaded_irq were
      to fail the following occurs:
      
      fail with no fixes:
      
      [    0.683147] ------------[ cut here ]------------
      [    0.683148] NULL pointer, cannot free irq
      [    0.683158] WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:1632 irq_domain_free_irqs+0x126/0x140
      [    0.683160] Modules linked in:
      [    0.683163] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #3
      [    0.683165] Hardware name:                  /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017
      [    0.683168] RIP: 0010:irq_domain_free_irqs+0x126/0x140
      [    0.683169] RSP: 0000:ffffc90000037ce8 EFLAGS: 00010292
      [    0.683171] RAX: 000000000000001d RBX: ffff880276283c00 RCX: ffffffff81c5e5e8
      [    0.683172] RDX: 0000000000000001 RSI: 0000000000000096 RDI: 0000000000000246
      [    0.683174] RBP: ffff880276283c00 R08: 0000000000000000 R09: 000000000000023c
      [    0.683175] R10: 0000000000000007 R11: 0000000000000000 R12: 000000000000007a
      [    0.683176] R13: 0000000000000001 R14: 0000000000000000 R15: 0000010010000000
      [    0.683178] FS:  0000000000000000(0000) GS:ffff88027ec80000(0000) knlGS:0000000000000000
      [    0.683180] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    0.683181] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0
      [    0.683182] Call Trace:
      [    0.683189]  intel_svm_finish_prq+0x3c/0x60
      [    0.683191]  free_dmar_iommu+0x1ac/0x1b0
      [    0.683195]  init_dmars+0xaaa/0xaea
      [    0.683200]  ? klist_next+0x19/0xc0
      [    0.683203]  ? pci_do_find_bus+0x50/0x50
      [    0.683205]  ? pci_get_dev_by_id+0x52/0x70
      [    0.683208]  intel_iommu_init+0x498/0x5c7
      [    0.683211]  pci_iommu_init+0x13/0x3c
      [    0.683214]  ? e820__memblock_setup+0x61/0x61
      [    0.683217]  do_one_initcall+0x4d/0x1a0
      [    0.683220]  kernel_init_freeable+0x186/0x20e
      [    0.683222]  ? set_debug_rodata+0x11/0x11
      [    0.683225]  ? rest_init+0xb0/0xb0
      [    0.683226]  kernel_init+0xa/0xff
      [    0.683229]  ret_from_fork+0x1f/0x30
      [    0.683259] Code: 89 ee 44 89 e7 e8 3b e8 ff ff 5b 5d 44 89 e7 44 89 ee 41 5c 41 5d 41 5e e9 a8 84 ff ff 48 c7 c7 a8 71 a7 81 31 c0 e8 6a d3 f9 ff <0f> ff 5b 5d 41 5c 41 5d 41 5
      e c3 0f 1f 44 00 00 66 2e 0f 1f 84
      [    0.683285] ---[ end trace f7650e42792627ca ]---
      
      with iommu->pr_irq = 0, but no check in intel_svm_finish_prq:
      
      [    0.669561] ------------[ cut here ]------------
      [    0.669563] Trying to free already-free IRQ 0
      [    0.669573] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1546 __free_irq+0xa4/0x2c0
      [    0.669574] Modules linked in:
      [    0.669577] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #4
      [    0.669579] Hardware name:                  /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017
      [    0.669581] RIP: 0010:__free_irq+0xa4/0x2c0
      [    0.669582] RSP: 0000:ffffc90000037cc0 EFLAGS: 00010082
      [    0.669584] RAX: 0000000000000021 RBX: 0000000000000000 RCX: ffffffff81c5e5e8
      [    0.669585] RDX: 0000000000000001 RSI: 0000000000000086 RDI: 0000000000000046
      [    0.669587] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000023c
      [    0.669588] R10: 0000000000000007 R11: 0000000000000000 R12: ffff880276253960
      [    0.669589] R13: ffff8802762538a4 R14: ffff880276253800 R15: ffff880276283600
      [    0.669593] FS:  0000000000000000(0000) GS:ffff88027ed80000(0000) knlGS:0000000000000000
      [    0.669594] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    0.669596] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0
      [    0.669602] Call Trace:
      [    0.669616]  free_irq+0x30/0x60
      [    0.669620]  intel_svm_finish_prq+0x34/0x60
      [    0.669623]  free_dmar_iommu+0x1ac/0x1b0
      [    0.669627]  init_dmars+0xaaa/0xaea
      [    0.669631]  ? klist_next+0x19/0xc0
      [    0.669634]  ? pci_do_find_bus+0x50/0x50
      [    0.669637]  ? pci_get_dev_by_id+0x52/0x70
      [    0.669639]  intel_iommu_init+0x498/0x5c7
      [    0.669642]  pci_iommu_init+0x13/0x3c
      [    0.669645]  ? e820__memblock_setup+0x61/0x61
      [    0.669648]  do_one_initcall+0x4d/0x1a0
      [    0.669651]  kernel_init_freeable+0x186/0x20e
      [    0.669653]  ? set_debug_rodata+0x11/0x11
      [    0.669656]  ? rest_init+0xb0/0xb0
      [    0.669658]  kernel_init+0xa/0xff
      [    0.669661]  ret_from_fork+0x1f/0x30
      [    0.669662] Code: 7a 08 75 0e e9 c3 01 00 00 4c 39 7b 08 74 57 48 89 da 48 8b 5a 18 48 85 db 75 ee 89 ee 48 c7 c7 78 67 a7 81 31 c0 e8 4c 37 fa ff <0f> ff 48 8b 34 24 4c 89 ef e
      8 0e 4c 68 00 49 8b 46 40 48 8b 80
      [    0.669688] ---[ end trace 58a470248700f2fc ]---
      
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarJerry Snitselaar <jsnitsel@redhat.com>
      Reviewed-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb4ff6c7
    • Florian Fainelli's avatar
      pinctrl: Really force states during suspend/resume · 3f0ad8ee
      Florian Fainelli authored
      
      [ Upstream commit 981ed1bf ]
      
      In case a platform only defaults a "default" set of pins, but not a
      "sleep" set of pins, and this particular platform suspends and resumes
      in a way that the pin states are not preserved by the hardware, when we
      resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
      -> pinctrl_select_state() and the first thing we do is check that the
      pins state is the same as before, and do nothing.
      
      In order to fix this, decouple the actual state change from
      pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
      the p->state == state check in pinctrl_select_state() not to change the
      caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
      are updated to bypass the state check by calling pinctrl_commit_state().
      
      [Linus Walleij]
      The forced pin control states are currently only used in some pin
      controller drivers that grab their own reference to their own pins.
      This is equal to the pin control hogs: pins taken by pin control
      devices since there are no corresponding device in the Linux device
      hierarchy, such as memory controller lines or unused GPIO lines,
      or GPIO lines that are used orthogonally from the GPIO subsystem
      but pincontrol-wise managed as hogs (non-strict mode, allowing
      simultaneous use by GPIO and pin control). For this case forcing
      the state from the drivers' suspend()/resume() callbacks makes
      sense and should semantically match the name of the function.
      
      Fixes: 6e5e959d ("pinctrl: API changes to support multiple states per device")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f0ad8ee
    • Robert Walker's avatar
      coresight: Fix disabling of CoreSight TPIU · b153ad5f
      Robert Walker authored
      
      [ Upstream commit 11595db8 ]
      
      The CoreSight TPIU should be disabled when tracing to other sinks to allow
      them to operate at full bandwidth.
      
      This patch fixes tpiu_disable_hw() to correctly disable the TPIU by
      configuring the TPIU to stop on flush, initiating a manual flush, waiting
      for the flush to complete and then waits for the TPIU to indicate it has
      stopped.
      Signed-off-by: default avatarRobert Walker <robert.walker@arm.com>
      Tested-by: default avatarMike Leach <mike.leach@linaro.org>
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b153ad5f
    • Sahara's avatar
      pty: cancel pty slave port buf's work in tty_release · d06bff35
      Sahara authored
      
      [ Upstream commit 2b022ab7 ]
      
      In case that CONFIG_SLUB_DEBUG is on and pty is used, races between
      release_one_tty and flush_to_ldisc work threads may happen and lead
      to use-after-free condition on tty->link->port. Because SLUB_DEBUG
      is turned on, freed tty->link->port is filled with POISON_FREE value.
      So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc
      could return without a problem by checking if tty is NULL.
      
      CPU 0                                 CPU 1
      -----                                 -----
      release_tty                           pty_write
         cancel_work_sync(tty)                 to = tty->link
         tty_kref_put(tty->link)               tty_schedule_flip(to->port)
            << workqueue >>                 ...
            release_one_tty                 ...
               pty_cleanup                  ...
                  kfree(tty->link->port)       << workqueue >>
                                               flush_to_ldisc
                                                  tty = READ_ONCE(port->itty)
                                                  tty is 0x6b6b6b6b6b6b6b6b
                                                  !!PANIC!! access tty->ldisc
      
       Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93
       pgd = ffffffc0eb1c3000
       [6b6b6b6b6b6b6b93] *pgd=0000000000000000, *pud=0000000000000000
       ------------[ cut here ]------------
       Kernel BUG at ffffff800851154c [verbose debug info unavailable]
       Internal error: Oops - BUG: 96000004 [#1] PREEMPT SMP
       CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G        W 3.18.31-g0a58eeb #1
       Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT)
       Workqueue: events_unbound flush_to_ldisc
       task: ffffffc0ed610ec0 ti: ffffffc0ed624000 task.ti: ffffffc0ed624000
       PC is at ldsem_down_read_trylock+0x0/0x4c
       LR is at tty_ldisc_ref+0x24/0x4c
       pc : [<ffffff800851154c>] lr : [<ffffff800850f6c0>] pstate: 80400145
       sp : ffffffc0ed627cd0
       x29: ffffffc0ed627cd0 x28: 0000000000000000
       x27: ffffff8009e05000 x26: ffffffc0d382cfa0
       x25: 0000000000000000 x24: ffffff800a012f08
       x23: 0000000000000000 x22: ffffffc0703fbc88
       x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93
       x19: 0000000000000000 x18: 0000000000000001
       x17: 00e80000f80d6f53 x16: 0000000000000001
       x15: 0000007f7d826fff x14: 00000000000000a0
       x13: 0000000000000000 x12: 0000000000000109
       x11: 0000000000000000 x10: 0000000000000000
       x9 : ffffffc0ed624000 x8 : ffffffc0ed611580
       x7 : 0000000000000000 x6 : ffffff800a42e000
       x5 : 00000000000003fc x4 : 0000000003bd1201
       x3 : 0000000000000001 x2 : 0000000000000001
       x1 : ffffff800851004c x0 : 6b6b6b6b6b6b6b93
      Signed-off-by: default avatarSahara <keun-o.park@darkmatter.ae>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d06bff35
    • Peter Ujfalusi's avatar
      drm/omap: DMM: Check for DMM readiness after successful transaction commit · 029c2cfd
      Peter Ujfalusi authored
      
      [ Upstream commit b7ea6b28 ]
      
      Check the status of the DMM engine after it is reported that the
      transaction was completed as in rare cases the engine might not reached a
      working state.
      
      The wait_status() will print information in case the DMM is not reached the
      expected state and the dmm_txn_commit() will return with an error code to
      make sure that we are not continuing with a broken setup.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      029c2cfd
    • Bjorn Helgaas's avatar
      vgacon: Set VGA struct resource types · aeea6c64
      Bjorn Helgaas authored
      
      [ Upstream commit c8208411 ]
      
      Set the resource type when we reserve VGA-related I/O port resources.
      
      The resource code doesn't actually look at the type, so it inserts
      resources without a type in the tree correctly even without this change.
      But if we ever print a resource without a type, it looks like this:
      
        vga+ [??? 0x000003c0-0x000003df flags 0x0]
      
      Setting the type means it will be printed correctly as:
      
        vga+ [io  0x000003c0-0x000003df]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aeea6c64
    • Artemy Kovalyov's avatar
      IB/umem: Fix use of npages/nmap fields · 5af22f14
      Artemy Kovalyov authored
      
      [ Upstream commit edf1a84f ]
      
      In ib_umem structure npages holds original number of sg entries, while
      nmap is number of DMA blocks returned by dma_map_sg.
      
      Fixes: c5d76f13 ('IB/core: Add umem function to read data from user-space')
      Signed-off-by: default avatarArtemy Kovalyov <artemyko@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5af22f14
    • Parav Pandit's avatar
      RDMA/cma: Use correct size when writing netlink stats · 99ee9243
      Parav Pandit authored
      
      [ Upstream commit 7baaa49a ]
      
      The code was using the src size when formatting the dst. They are almost
      certainly the same value but it reads wrong.
      
      Fixes: ce117ffa ("RDMA/cma: Export AF_IB statistics")
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Reviewed-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99ee9243
    • Erez Shitrit's avatar
      IB/ipoib: Avoid memory leak if the SA returns a different DGID · 64e3d455
      Erez Shitrit authored
      
      [ Upstream commit 43900089 ]
      
      The ipoib path database is organized around DGIDs from the LLADDR, but the
      SA is free to return a different GID when asked for path. This causes a
      bug because the SA's modified DGID is copied into the database key, even
      though it is no longer the correct lookup key, causing a memory leak and
      other malfunctions.
      
      Ensure the database key does not change after the SA query completes.
      
      Demonstration of the bug is as  follows
      ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it
      creates new record in the DB with that gid as a key, and issues a new
      request to the SM.
      Now, the SM from some reason returns path-record with other SGID (for
      example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local
      subnet prefix) now ipoib will overwrite the current entry with the new
      one, and if new request to the original GID arrives ipoib  will not find
      it in the DB (was overwritten) and will create new record that in its
      turn will also be overwritten by the response from the SM, and so on
      till the driver eats all the device memory.
      Signed-off-by: default avatarErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64e3d455
    • Daniel Drake's avatar
      mmc: avoid removing non-removable hosts during suspend · 3ed000cd
      Daniel Drake authored
      
      [ Upstream commit de8dcc3d ]
      
      The Weibu F3C MiniPC has an onboard AP6255 module, presenting
      two SDIO functions on a single MMC host (Bluetooth/btsdio and
      WiFi/brcmfmac), and the mmc layer correctly detects this as
      non-removable.
      
      After suspend/resume, the wifi and bluetooth interfaces disappear
      and do not get probed again.
      
      The conditions here are:
      
       1. During suspend, we reach mmc_pm_notify()
      
       2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
          suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
          -ENOSYS because btsdio_driver does not have a suspend method.
      
       3. mmc_pm_notify() proceeds to remove the card
      
       4. Upon resume, mmc_rescan() does nothing with this host, because of
          the rescan_entered check which aims to only scan a non-removable
          device a single time (i.e. during boot).
      
      Fix the loss of functionality by detecting that we are unable to
      suspend a non-removable host, so avoid the forced removal in that
      case. The comment above this function already indicates that this
      code was only intended for removable devices.
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ed000cd
    • Shawn Nematbakhsh's avatar
      platform/chrome: Use proper protocol transfer function · df9d1861
      Shawn Nematbakhsh authored
      
      [ Upstream commit d48b8c58 ]
      
      pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
      one instance of these functions correct, but not the second, fall-back
      case. We use the fall-back only when the first command returns an
      IN_PROGRESS status, which is only used on some EC firmwares where we
      don't want to constantly poll the bus, but instead back off and
      sleep/retry for a little while.
      
      Fixes: 2c7589af ("mfd: cros_ec: add proto v3 skeleton")
      Signed-off-by: default avatarShawn Nematbakhsh <shawnn@chromium.org>
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarBenson Leung <bleung@chromium.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df9d1861
    • Arnd Bergmann's avatar
      cros_ec: fix nul-termination for firmware build info · bcde6355
      Arnd Bergmann authored
      
      [ Upstream commit 50a0d71a ]
      
      As gcc-8 reports, we zero out the wrong byte:
      
      drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
      drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
      
      This changes the code back to what it did before changing to a
      zero-length array structure.
      
      Fixes: a8411784 ("mfd: cros_ec: Use a zero-length array for command data")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBenson Leung <bleung@chromium.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bcde6355
    • Ron Economos's avatar
      media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart · 17a660a3
      Ron Economos authored
      
      [ Upstream commit 380a6c86 ]
      
      On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart.
      
      Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem.
      Signed-off-by: default avatarRon Economos <w6rz@comcast.net>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17a660a3
    • Christophe JAILLET's avatar
      media: bt8xx: Fix err 'bt878_probe()' · 3e99ac9c
      Christophe JAILLET authored
      
      [ Upstream commit 45392ff6 ]
      
      This is odd to call 'pci_disable_device()' in an error path before a
      coresponding successful 'pci_enable_device()'.
      
      Return directly instead.
      
      Fixes: 77e0be12 ("V4L/DVB (4176): Bug-fix: Fix memory overflow")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e99ac9c