1. 28 Mar, 2018 24 commits
    • Toshi Kani's avatar
      mm/vmalloc: add interfaces to free unmapped page table · 9c7f7bdb
      Toshi Kani authored
      commit b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e upstream.
      
      On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
      create pud/pmd mappings.  A kernel panic was observed on arm64 systems
      with Cortex-A75 in the following steps as described by Hanjun Guo.
      
       1. ioremap a 4K size, valid page table will build,
       2. iounmap it, pte0 will set to 0;
       3. ioremap the same address with 2M size, pgd/pmd is unchanged,
          then set the a new value for pmd;
       4. pte0 is leaked;
       5. CPU may meet exception because the old pmd is still in TLB,
          which will lead to kernel panic.
      
      This panic is not reproducible on x86.  INVLPG, called from iounmap,
      purges all levels of entries associated with purged address on x86.  x86
      still has memory leak.
      
      The patch changes the ioremap path to free unmapped page table(s) since
      doing so in the unmap path has the following issues:
      
       - The iounmap() path is shared with vunmap(). Since vmap() only
         supports pte mappings, making vunmap() to free a pte page is an
         overhead for regular vmap users as they do not need a pte page freed
         up.
      
       - Checking if all entries in a pte page are cleared in the unmap path
         is racy, and serializing this check is expensive.
      
       - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
         Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
         purge.
      
      Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
      clear a given pud/pmd entry and free up a page for the lower level
      entries.
      
      This patch implements their stub functions on x86 and arm64, which work
      as workaround.
      
      [akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
      Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
      Fixes: e61ce6ad
      
       ("mm: change ioremap to set up huge I/O mappings")
      Reported-by: default avatarLei Li <lious.lilei@hisilicon.com>
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Wang Xuefeng <wxf.wang@hisilicon.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Chintan Pandya <cpandya@codeaurora.org>
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c7f7bdb
    • Jeff Layton's avatar
      nfsd: remove blocked locks on client teardown · e294c4c2
      Jeff Layton authored
      commit 68ef3bc3166468678d5e1fdd216628c35bd1186f upstream.
      
      We had some reports of panics in nfsd4_lm_notify, and that showed a
      nfs4_lockowner that had outlived its so_client.
      
      Ensure that we walk any leftover lockowners after tearing down all of
      the stateids, and remove any blocked locks that they hold.
      
      With this change, we also don't need to walk the nbl_lru on nfsd_net
      shutdown, as that will happen naturally when we tear down the clients.
      
      Fixes: 76d348fa
      
       (nfsd: have nfsd4_lock use blocking locks for v4.1+ locks)
      Reported-by: default avatarFrank Sorenson <fsorenso@redhat.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Cc: stable@vger.kernel.org # 4.9
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e294c4c2
    • Hans de Goede's avatar
      libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version · 8d7a2a6d
      Hans de Goede authored
      
      
      commit d418ff56b8f2d2b296daafa8da151fe27689b757 upstream.
      
      When commit 9c7be59fc519af ("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: 9c7be59fc519af ("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>
      8d7a2a6d
    • Hans de Goede's avatar
      libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions · ed57941c
      Hans de Goede authored
      commit 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f upstream.
      
      Commit b17e5729a630 ("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: b17e5729a630 ("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>
      ed57941c
    • Hans de Goede's avatar
      libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs · a7262d24
      Hans de Goede authored
      
      
      commit 62ac3f7305470e3f52f159de448bc1a771717e88 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>
      a7262d24
    • Ju Hyung Park's avatar
      libata: Enable queued TRIM for Samsung SSD 860 · db4a121a
      Ju Hyung Park authored
      
      
      commit ca6bfcb2f6d9deab3924bf901e73622a94900473 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>
      db4a121a
    • Kai-Heng Feng's avatar
      libata: disable LPM for Crucial BX100 SSD 500GB drive · 2bcfcae4
      Kai-Heng Feng authored
      commit b17e5729a630d8326a48ec34ef02e6b4464a6aef 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/1726930
      
      Signed-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>
      2bcfcae4
    • Hans de Goede's avatar
      libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs · a9f062b8
      Hans de Goede authored
      commit 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 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>
      a9f062b8
    • Eric Biggers's avatar
      libata: don't try to pass through NCQ commands to non-NCQ devices · 8b8524d7
      Eric Biggers authored
      commit 2c1ec6fda2d07044cda922ee25337cf5d4b429b3 upstream.
      
      syzkaller hit a WARN() in ata_bmdma_qc_issue() when writing to /dev/sg0.
      This happened because it issued an ATA pass-through command (ATA_16)
      where the protocol field indicated that NCQ should be used -- but the
      device did not support NCQ.
      
      We could just remove the WARN() from libata-sff.c, but the real problem
      seems to be that the SCSI -> ATA translation code passes through NCQ
      commands without verifying that the device actually supports NCQ.
      
      Fix this by adding the appropriate check to ata_scsi_pass_thru().
      
      Here's 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[53] = { 0 };
      
      	    buf[36] = 0x85;		/* ATA_16 */
      	    buf[37] = (12 << 1);	/* FPDMA */
      	    buf[38] = 0x1;		/* Has data */
      	    buf[51] = 0xC8;		/* ATA_CMD_READ */
                  write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
          }
      
      Fixes: ee7fb331
      
       ("libata: add support for NCQ commands for SG interface")
      Reported-by: syzbot+2f69ca28df61bdfc77cd36af2e789850355a221e@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org> # v4.4+
      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>
      8b8524d7
    • Eric Biggers's avatar
      libata: remove WARN() for DMA or PIO command without data · 195c71dc
      Eric Biggers authored
      commit 9173e5e80729c8434b8d27531527c5245f4a5594 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>
      195c71dc
    • Eric Biggers's avatar
      libata: fix length validation of ATAPI-relayed SCSI commands · 85f0fec1
      Eric Biggers authored
      commit 058f58e235cbe03e923b30ea7c49995a46a8725f 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>
      85f0fec1
    • Takashi Iwai's avatar
      Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 · dd62bc30
      Takashi Iwai authored
      commit f44cb4b19ed40b655c2d422c9021ab2c2625adb6 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=1082504
      
      Reported-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>
      dd62bc30
    • Chen-Yu Tsai's avatar
      clk: sunxi-ng: a31: Fix CLK_OUT_* clock ops · bdbd9153
      Chen-Yu Tsai authored
      commit 5682e268350f9eccdbb04006605c1b7068a7b323 upstream.
      
      When support for the A31/A31s CCU was first added, the clock ops for
      the CLK_OUT_* clocks was set to the wrong type. The clocks are MP-type,
      but the ops was set for div (M) clocks. This went unnoticed until now.
      This was because while they are different clocks, their data structures
      aligned in a way that ccu_div_ops would access the second ccu_div_internal
      and ccu_mux_internal structures, which were valid, if not incorrect.
      
      Furthermore, the use of these CLK_OUT_* was for feeding a precise 32.768
      kHz clock signal to the WiFi chip. This was achievable by using the parent
      with the same clock rate and no divider. So the incorrect divider setting
      did not affect this usage.
      
      Commit 946797aa
      
       ("clk: sunxi-ng: Support fixed post-dividers on MP
      style clocks") added a new field to the ccu_mp structure, which broke
      the aforementioned alignment. Now the system crashes as div_ops tries
      to look up a nonexistent table.
      Reported-by: default avatarPhilipp Rossak <embed3d@gmail.com>
      Tested-by: default avatarPhilipp Rossak <embed3d@gmail.com>
      Fixes: c6e6c96d
      
       ("clk: sunxi-ng: Add A31/A31s clocks")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: Maxime Ripard's avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdbd9153
    • Boris Brezillon's avatar
      clk: bcm2835: Protect sections updating shared registers · 8f0dd27b
      Boris Brezillon authored
      commit 7997f3b2df751aab0b8e60149b226a32966c41ac 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>
      8f0dd27b
    • Boris Brezillon's avatar
      clk: bcm2835: Fix ana->maskX definitions · beb9ece1
      Boris Brezillon authored
      commit 49012d1bf5f78782d398adb984a080a88ba42965 upstream.
      
      ana->maskX values are already '~'-ed in bcm2835_pll_set_rate(). Remove
      the '~' in the definition to fix ANA setup.
      
      Note that this commit fixes a long standing bug preventing one from
      using an HDMI display if it's plugged after the FW has booted Linux.
      This is because PLLH is used by the HDMI encoder to generate the pixel
      clock.
      
      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>
      beb9ece1
    • Hans de Goede's avatar
      ahci: Add PCI-id for the Highpoint Rocketraid 644L card · 3ba5143b
      Hans de Goede authored
      commit 28b2182dad43f6f8fcbd167539a26714fd12bd64 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=1534106
      
      Signed-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>
      3ba5143b
    • Hans de Goede's avatar
      PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L · d2327a25
      Hans de Goede authored
      commit 1903be8222b7c278ca897c129ce477c1dd6403a8 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=1534106
      
      Signed-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>
      d2327a25
    • Evgeniy Didin's avatar
      mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs · d8963938
      Evgeniy Didin authored
      commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 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>
      d8963938
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Always immediately update mute LED with pin VREF · ff0b03a4
      Takashi Iwai authored
      commit e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c 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>
      ff0b03a4
    • Takashi Iwai's avatar
      ALSA: aloop: Fix access to not-yet-ready substream via cable · 78969700
      Takashi Iwai authored
      
      
      commit 8e6b1a72a75bb5067ccb6b56d8ca4aa3a300a64e 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>
      78969700
    • Takashi Iwai's avatar
      ALSA: aloop: Sync stale timer before release · d44f3ad7
      Takashi Iwai authored
      
      
      commit 67a01afaf3d34893cf7d2ea19b34555d6abb7cb0 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>
      d44f3ad7
    • Kirill Marinushkin's avatar
      ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit · b1d25da5
      Kirill Marinushkin authored
      commit a6618f4aedb2b60932d766bd82ae7ce866e842aa 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>
      b1d25da5
    • Michael Nosthoff's avatar
      iio: st_pressure: st_accel: pass correct platform data to init · 055c49dc
      Michael Nosthoff authored
      commit 8b438686a001db64c21782d04ef68111e53c45d9 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>
      055c49dc
    • NeilBrown's avatar
      MIPS: ralink: Remove ralink_halt() · 3eaa5de1
      NeilBrown authored
      commit 891731f6a5dbe508d12443175a7e166a2fba616a 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>
      3eaa5de1
  2. 24 Mar, 2018 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.90 · 24f70aa8
      Greg Kroah-Hartman authored
      24f70aa8
    • Krzysztof Opasiak's avatar
      usb: gadget: f_hid: fix: Move IN request allocation to set_alt() · 8dd5c0c4
      Krzysztof Opasiak authored
      commit 749494b6 upstream.
      
      Since commit: ba1582f2 ("usb: gadget: f_hid: use alloc_ep_req()")
      we cannot allocate any requests in bind() as we check if we should
      align request buffer based on endpoint descriptor which is assigned
      in set_alt().
      
      Allocating request in bind() function causes a NULL pointer
      dereference.
      
      This commit moves allocation of IN request from bind() to set_alt()
      to prevent this issue.
      
      Fixes: ba1582f2
      
       ("usb: gadget: f_hid: use alloc_ep_req()")
      Cc: stable@vger.kernel.org
      Tested-by: default avatarDavid Lechner <david@lechnology.com>
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Cc: Bin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8dd5c0c4
    • Leon Romanovsky's avatar
      RDMA/ucma: Don't allow join attempts for unsupported AF family · 805cbd50
      Leon Romanovsky authored
      commit 0c81ffc60d5280991773d17e84bda605387148b1 upstream.
      
      Users can provide garbage while calling to ucma_join_ip_multicast(),
      it will indirectly cause to rdma_addr_size() return 0, making the
      call to ucma_process_join(), which had the right checks, but it is
      better to check the input as early as possible.
      
      The following crash from syzkaller revealed it.
      
      kernel BUG at lib/string.c:1052!
      invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 0 PID: 4113 Comm: syz-executor0 Not tainted 4.16.0-rc5+ #261
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:fortify_panic+0x13/0x20 lib/string.c:1051
      RSP: 0018:ffff8801ca81f8f0 EFLAGS: 00010286
      RAX: 0000000000000022 RBX: 1ffff10039503f23 RCX: 0000000000000000
      RDX: 0000000000000022 RSI: 1ffff10039503ed3 RDI: ffffed0039503f12
      RBP: ffff8801ca81f8f0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000006 R11: 0000000000000000 R12: ffff8801ca81f998
      R13: ffff8801ca81f938 R14: ffff8801ca81fa58 R15: 000000000000fa00
      FS:  0000000000000000(0000) GS:ffff8801db200000(0063) knlGS:000000000a12a900
      CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      CR2: 0000000008138024 CR3: 00000001cbb58004 CR4: 00000000001606f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       memcpy include/linux/string.h:344 [inline]
       ucma_join_ip_multicast+0x36b/0x3b0 drivers/infiniband/core/ucma.c:1421
       ucma_write+0x2d6/0x3d0 drivers/infiniband/core/ucma.c:1633
       __vfs_write+0xef/0x970 fs/read_write.c:480
       vfs_write+0x189/0x510 fs/read_write.c:544
       SYSC_write fs/read_write.c:589 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:581
       do_syscall_32_irqs_on arch/x86/entry/common.c:330 [inline]
       do_fast_syscall_32+0x3ec/0xf9f arch/x86/entry/common.c:392
       entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
      RIP: 0023:0xf7f9ec99
      RSP: 002b:00000000ff8172cc EFLAGS: 00000282 ORIG_RAX: 0000000000000004
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000020000100
      RDX: 0000000000000063 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      Code: 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 48 89 df e8 42 2c e3 fb eb de
      55 48 89 fe 48 c7 c7 80 75 98 86 48 89 e5 e8 85 95 94 fb <0f> 0b 90 90 90 90
      90 90 90 90 90 90 90 55 48 89 e5 41 57 41 56
      RIP: fortify_panic+0x13/0x20 lib/string.c:1051 RSP: ffff8801ca81f8f0
      
      Fixes: 5bc2b7b3
      
       ("RDMA/ucma: Allow user space to specify AF_IB when joining multicast")
      Reported-by: <syzbot+2287ac532caa81900a4e@syzkaller.appspotmail.com>
      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>
      805cbd50
    • Leon Romanovsky's avatar
      RDMA/ucma: Fix access to non-initialized CM_ID object · e3fb6525
      Leon Romanovsky authored
      commit 7688f2c3bbf55e52388e37ac5d63ca471a7712e1 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>
      e3fb6525
    • Jerome Brunet's avatar
      clk: migrate the count of orphaned clocks at init · bbdfb447
      Jerome Brunet authored
      commit 99652a469df19086d594e8e89757d4081a812789 upstream.
      
      The orphan clocks reparents should migrate any existing count from the
      orphan clock to its new acestor clocks, otherwise we may have
      inconsistent counts in the tree and end-up with gated critical clocks
      
      Assuming we have two clocks, A and B.
      * Clock A has CLK_IS_CRITICAL flag set.
      * Clock B is an ancestor of A which can gate. Clock B gate is left
        enabled by the bootloader.
      
      Step 1: Clock A is registered. Since it is a critical clock, it is
      enabled. The clock being still an orphan, no parent are enabled.
      
      Step 2: Clock B is registered and reparented to clock A (potentially
      through several other clocks). We are now in situation where the enable
      count of clock A is 1 while the enable count of its ancestors is 0, which
      is not good.
      
      Step 3: in lateinit, clk_disable_unused() is called, the enable_count of
      clock B being 0, clock B is gated and and critical clock A actually gets
      disabled.
      
      This situation was found while adding fdiv_clk gates to the meson8b
      platform.  These clocks parent clk81 critical clock, which is the mother
      of all peripheral clocks in this system. Because of the issue described
      here, the system is crashing when clk_disable_unused() is called.
      
      The situation is solved by reverting
      commit f8f8f1d0 ("clk: Don't touch hardware when reparenting during registration").
      To avoid breaking again the situation described in this commit
      description, enabling critical clock should be done before walking the
      orphan list. This way, a parent critical clock may not be accidentally
      disabled due to the CLK_OPS_PARENT_ENABLE mechanism.
      
      Fixes: f8f8f1d0
      
       ("clk: Don't touch hardware when reparenting during registration")
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Dong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bbdfb447
    • Boris Pismenny's avatar
      IB/mlx5: Fix out-of-bounds read in create_raw_packet_qp_rq · 971e09c7
      Boris Pismenny authored
      commit 2c292dbb398ee46fc1343daf6c3cf9715a75688e upstream.
      
      Add a check for the length of the qpin structure to prevent out-of-bounds reads
      
      BUG: KASAN: slab-out-of-bounds in create_raw_packet_qp+0x114c/0x15e2
      Read of size 8192 at addr ffff880066b99290 by task syz-executor3/549
      
      CPU: 3 PID: 549 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #27 Hardware
      name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
      Call Trace:
       dump_stack+0x8d/0xd4
       print_address_description+0x73/0x290
       kasan_report+0x25c/0x370
       ? create_raw_packet_qp+0x114c/0x15e2
       memcpy+0x1f/0x50
       create_raw_packet_qp+0x114c/0x15e2
       ? create_raw_packet_qp_tis.isra.28+0x13d/0x13d
       ? lock_acquire+0x370/0x370
       create_qp_common+0x2245/0x3b50
       ? destroy_qp_user.isra.47+0x100/0x100
       ? kasan_kmalloc+0x13d/0x170
       ? sched_clock_cpu+0x18/0x180
       ? fs_reclaim_acquire.part.15+0x5/0x30
       ? __lock_acquire+0xa11/0x1da0
       ? sched_clock_cpu+0x18/0x180
       ? kmem_cache_alloc_trace+0x17e/0x310
       ? mlx5_ib_create_qp+0x30e/0x17b0
       mlx5_ib_create_qp+0x33d/0x17b0
       ? sched_clock_cpu+0x18/0x180
       ? create_qp_common+0x3b50/0x3b50
       ? lock_acquire+0x370/0x370
       ? __radix_tree_lookup+0x180/0x220
       ? uverbs_try_lock_object+0x68/0xc0
       ? rdma_lookup_get_uobject+0x114/0x240
       create_qp.isra.5+0xce4/0x1e20
       ? ib_uverbs_ex_create_cq_cb+0xa0/0xa0
       ? copy_ah_attr_from_uverbs.isra.2+0xa00/0xa00
       ? ib_uverbs_cq_event_handler+0x160/0x160
       ? __might_fault+0x17c/0x1c0
       ib_uverbs_create_qp+0x21b/0x2a0
       ? ib_uverbs_destroy_cq+0x2e0/0x2e0
       ib_uverbs_write+0x55a/0xad0
       ? ib_uverbs_destroy_cq+0x2e0/0x2e0
       ? ib_uverbs_destroy_cq+0x2e0/0x2e0
       ? ib_uverbs_open+0x760/0x760
       ? futex_wake+0x147/0x410
       ? check_prev_add+0x1680/0x1680
       ? do_futex+0x3d3/0xa60
       ? sched_clock_cpu+0x18/0x180
       __vfs_write+0xf7/0x5c0
       ? ib_uverbs_open+0x760/0x760
       ? kernel_read+0x110/0x110
       ? lock_acquire+0x370/0x370
       ? __fget+0x264/0x3b0
       vfs_write+0x18a/0x460
       SyS_write+0xc7/0x1a0
       ? SyS_read+0x1a0/0x1a0
       ? trace_hardirqs_on_thunk+0x1a/0x1c
       entry_SYSCALL_64_fastpath+0x18/0x85
      RIP: 0033:0x4477b9
      RSP: 002b:00007f1822cadc18 EFLAGS: 00000292 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00000000004477b9
      RDX: 0000000000000070 RSI: 000000002000a000 RDI: 0000000000000005
      RBP: 0000000000708000 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000292 R12: 00000000ffffffff
      R13: 0000000000005d70 R14: 00000000006e6e30 R15: 0000000020010ff0
      
      Allocated by task 549:
       __kmalloc+0x15e/0x340
       kvmalloc_node+0xa1/0xd0
       create_user_qp.isra.46+0xd42/0x1610
       create_qp_common+0x2e63/0x3b50
       mlx5_ib_create_qp+0x33d/0x17b0
       create_qp.isra.5+0xce4/0x1e20
       ib_uverbs_create_qp+0x21b/0x2a0
       ib_uverbs_write+0x55a/0xad0
       __vfs_write+0xf7/0x5c0
       vfs_write+0x18a/0x460
       SyS_write+0xc7/0x1a0
       entry_SYSCALL_64_fastpath+0x18/0x85
      
      Freed by task 368:
       kfree+0xeb/0x2f0
       kernfs_fop_release+0x140/0x180
       __fput+0x266/0x700
       task_work_run+0x104/0x180
       exit_to_usermode_loop+0xf7/0x110
       syscall_return_slowpath+0x298/0x370
       entry_SYSCALL_64_fastpath+0x83/0x85
      
      The buggy address belongs to the object at ffff880066b99180  which
      belongs to the cache kmalloc-512 of size 512 The buggy address is
      located 272 bytes inside of  512-byte region [ffff880066b99180,
      ffff880066b99380) The buggy address belongs to the page:
      page:000000006040eedd count:1 mapcount:0 mapping:          (null)
      index:0x0 compound_mapcount: 0
      flags: 0x4000000000008100(slab|head)
      raw: 4000000000008100 0000000000000000 0000000000000000 0000000180190019
      raw: ffffea00019a7500 0000000b0000000b ffff88006c403080 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff880066b99180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff880066b99200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff880066b99280: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                               ^
       ffff880066b99300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880066b99380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Cc: syzkaller <syzkaller@googlegroups.com>
      Fixes: 0fb2ed66
      
       ("IB/mlx5: Add create and destroy functionality for Raw Packet QP")
      Signed-off-by: default avatarBoris Pismenny <borisp@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      971e09c7
    • Boris Pismenny's avatar
      IB/mlx5: Fix integer overflows in mlx5_ib_create_srq · e2ee1a18
      Boris Pismenny authored
      commit c2b37f76485f073f020e60b5954b6dc4e55f693c upstream.
      
      This patch validates user provided input to prevent integer overflow due
      to integer manipulation in the mlx5_ib_create_srq function.
      
      Cc: syzkaller <syzkaller@googlegroups.com>
      Fixes: e126ba97
      
       ("mlx5: Add driver for Mellanox Connect-IB adapters")
      Signed-off-by: default avatarBoris Pismenny <borisp@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2ee1a18
    • Vignesh R's avatar
      dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 · 559205f2
      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>
      559205f2
    • Sergej Sawazki's avatar
      clk: si5351: Rename internal plls to avoid name collisions · bc0e7313
      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>
      bc0e7313
    • Lars-Peter Clausen's avatar
      clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() · c53ae7d9
      Lars-Peter Clausen authored
      
      [ Upstream commit 063578dc
      
       ]
      
      If the nocount bit is set the divider is bypassed and the settings for the
      divider count should be ignored and a divider value of 1 should be assumed.
      Handle this correctly in the driver recalc_rate() callback.
      
      While the driver sets up the part so that the read back dividers values
      yield the correct result the power-on reset settings of the part might not
      reflect this and hence calling e.g. clk_get_rate() without prior calls to
      clk_set_rate() will yield the wrong result.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      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>
      c53ae7d9
    • Stephen Boyd's avatar
      clk: Don't touch hardware when reparenting during registration · 9fd65f85
      Stephen Boyd authored
      
      [ Upstream commit f8f8f1d0 ]
      
      The orphan clocks reparent operation shouldn't touch the hardware
      if clocks are enabled, otherwise it may get a chance to disable a
      newly registered critical clock which triggers the warning below.
      
      Assuming we have two clocks: A and B, B is the parent of A.
      Clock A has flag: CLK_OPS_PARENT_ENABLE
      Clock B has flag: CLK_IS_CRITICAL
      
      Step 1:
      Clock A is registered, then it becomes orphan.
      
      Step 2:
      Clock B is registered. Before clock B reach the critical clock enable
      operation, orphan A will find the newly registered parent B and do
      reparent operation, then parent B will be finally disabled in
      __clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's
      still no users of B which will then trigger the following warning.
      
      WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373
      Hardware name: Generic DT based system
      Backtrace:
      [<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c)
       r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000
      [<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8)
      [<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104)
       r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000
       r4:00000000 r3:c0e01d34
      [<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30)
       r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80
      [<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0)
      [<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c)
       r4:000000d3 r3:c0e0af00
      [<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28)
       r5:00000000 r4:ef00bf80
      [<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54)
       r4:ef00bd80 r3:000010a0
      [<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648)
       r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4
      [<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c)
       r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500
      [<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120)
      [<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54)
       r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001
       r4:f0810030
      [<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98)
       r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808
      [<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0)
       r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0
       r4:00000006
      [<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38)
       r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000
       r4:00000000
      [<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394)
      [<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c)
       r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918
       r4:c0e78294
      
      We know that the clk isn't enabled with any sort of prepare_count
      here so we don't need to enable anything to prevent a race. And
      we're holding the prepare mutex so set_rate/set_parent can't race
      here either. Based on an earlier patch by Dong Aisheng.
      
      Fixes: fc8726a2
      
       ("clk: core: support clocks which requires parents enable (part 2)")
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Reported-by: default avatarDong Aisheng <aisheng.dong@nxp.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>
      9fd65f85
    • Benjamin Coddington's avatar
      nfsd4: permit layoutget of executable-only files · eeed4cf8
      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>
      eeed4cf8
    • Joel Stanley's avatar
      ARM: dts: aspeed-evb: Add unit name to memory node · 64d5c600
      Joel Stanley authored
      
      [ Upstream commit e40ed274
      
       ]
      
      Fixes a warning when building with W=1.
      
      All of the ASPEED device trees build without warnings now.
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64d5c600
    • Anton Vasilyev's avatar
      RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS · dc445b38
      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>
      dc445b38
    • Alexey Kodanev's avatar
      ip6_vti: adjust vti mtu according to mtu of lower device · 1139d77d
      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>
      1139d77d
    • Jerry Snitselaar's avatar
      iommu/vt-d: clean up pr_irq if request_threaded_irq fails · 62088f53
      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>
      62088f53