1. 02 Mar, 2019 1 commit
  2. 01 Mar, 2019 5 commits
    • Linus Torvalds's avatar
      Merge tag 'iommu-fix-v5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · a215ce8f
      Linus Torvalds authored
      Pull IOMMU fix from Joerg Roedel:
       "One important fix for a memory corruption issue in the Intel VT-d
        driver that triggers on hardware with deep PCI hierarchies"
      
      * tag 'iommu-fix-v5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/dmar: Fix buffer overflow during PCI bus notification
      a215ce8f
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 2d28e01d
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "2 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        hugetlbfs: fix races and page leaks during migration
        kasan: turn off asan-stack for clang-8 and earlier
      2d28e01d
    • Mike Kravetz's avatar
      hugetlbfs: fix races and page leaks during migration · cb6acd01
      Mike Kravetz authored
      hugetlb pages should only be migrated if they are 'active'.  The
      routines set/clear_page_huge_active() modify the active state of hugetlb
      pages.
      
      When a new hugetlb page is allocated at fault time, set_page_huge_active
      is called before the page is locked.  Therefore, another thread could
      race and migrate the page while it is being added to page table by the
      fault code.  This race is somewhat hard to trigger, but can be seen by
      strategically adding udelay to simulate worst case scheduling behavior.
      Depending on 'how' the code races, various BUG()s could be triggered.
      
      To address this issue, simply delay the set_page_huge_active call until
      after the page is successfully added to the page table.
      
      Hugetlb pages can also be leaked at migration time if the pages are
      associated with a file in an explicitly mounted hugetlbfs filesystem.
      For example, consider a two node system with 4GB worth of huge pages
      available.  A program mmaps a 2G file in a hugetlbfs filesystem.  It
      then migrates the pages associated with the file from one node to
      another.  When the program exits, huge page counts are as follows:
      
        node0
        1024    free_hugepages
        1024    nr_hugepages
      
        node1
        0       free_hugepages
        1024    nr_hugepages
      
        Filesystem                         Size  Used Avail Use% Mounted on
        nodev                              4.0G  2.0G  2.0G  50% /var/opt/hugepool
      
      That is as expected.  2G of huge pages are taken from the free_hugepages
      counts, and 2G is the size of the file in the explicitly mounted
      filesystem.  If the file is then removed, the counts become:
      
        node0
        1024    free_hugepages
        1024    nr_hugepages
      
        node1
        1024    free_hugepages
        1024    nr_hugepages
      
        Filesystem                         Size  Used Avail Use% Mounted on
        nodev                              4.0G  2.0G  2.0G  50% /var/opt/hugepool
      
      Note that the filesystem still shows 2G of pages used, while there
      actually are no huge pages in use.  The only way to 'fix' the filesystem
      accounting is to unmount the filesystem
      
      If a hugetlb page is associated with an explicitly mounted filesystem,
      this information in contained in the page_private field.  At migration
      time, this information is not preserved.  To fix, simply transfer
      page_private from old to new page at migration time if necessary.
      
      There is a related race with removing a huge page from a file and
      migration.  When a huge page is removed from the pagecache, the
      page_mapping() field is cleared, yet page_private remains set until the
      page is actually freed by free_huge_page().  A page could be migrated
      while in this state.  However, since page_mapping() is not set the
      hugetlbfs specific routine to transfer page_private is not called and we
      leak the page count in the filesystem.
      
      To fix that, check for this condition before migrating a huge page.  If
      the condition is detected, return EBUSY for the page.
      
      Link: http://lkml.kernel.org/r/74510272-7319-7372-9ea6-ec914734c179@oracle.com
      Link: http://lkml.kernel.org/r/20190212221400.3512-1-mike.kravetz@oracle.com
      Fixes: bcc54222 ("mm: hugetlb: introduce page_huge_active")
      Signed-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: <stable@vger.kernel.org>
      [mike.kravetz@oracle.com: v2]
        Link: http://lkml.kernel.org/r/7534d322-d782-8ac6-1c8d-a8dc380eb3ab@oracle.com
      [mike.kravetz@oracle.com: update comment and changelog]
        Link: http://lkml.kernel.org/r/420bcfd6-158b-38e4-98da-26d0cd85bd01@oracle.comSigned-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cb6acd01
    • Arnd Bergmann's avatar
      kasan: turn off asan-stack for clang-8 and earlier · 6baec880
      Arnd Bergmann authored
      Building an arm64 allmodconfig kernel with clang results in over 140
      warnings about overly large stack frames, the worst ones being:
      
        drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame size of 20224 bytes in function 'st7789v_prepare'
        drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c:196:12: error: stack frame size of 13120 bytes in function 'td028ttec1_panel_enable'
        drivers/usb/host/max3421-hcd.c:1395:1: error: stack frame size of 10048 bytes in function 'max3421_spi_thread'
        drivers/net/wan/slic_ds26522.c:209:12: error: stack frame size of 9664 bytes in function 'slic_ds26522_probe'
        drivers/crypto/ccp/ccp-ops.c:2434:5: error: stack frame size of 8832 bytes in function 'ccp_run_cmd'
        drivers/media/dvb-frontends/stv0367.c:1005:12: error: stack frame size of 7840 bytes in function 'stv0367ter_algo'
      
      None of these happen with gcc today, and almost all of these are the
      result of a single known issue in llvm.  Hopefully it will eventually
      get fixed with the clang-9 release.
      
      In the meantime, the best idea I have is to turn off asan-stack for
      clang-8 and earlier, so we can produce a kernel that is safe to run.
      
      I have posted three patches that address the frame overflow warnings
      that are not addressed by turning off asan-stack, so in combination with
      this change, we get much closer to a clean allmodconfig build, which in
      turn is necessary to do meaningful build regression testing.
      
      It is still possible to turn on the CONFIG_ASAN_STACK option on all
      versions of clang, and it's always enabled for gcc, but when
      CONFIG_COMPILE_TEST is set, the option remains invisible, so
      allmodconfig and randconfig builds (which are normally done with a
      forced CONFIG_COMPILE_TEST) will still result in a mostly clean build.
      
      Link: http://lkml.kernel.org/r/20190222222950.3997333-1-arnd@arndb.de
      Link: https://bugs.llvm.org/show_bug.cgi?id=38809Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarQian Cai <cai@lca.pw>
      Reviewed-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6baec880
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2019-03-01' of git://anongit.freedesktop.org/drm/drm · 6357c812
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Three final fixes, one for a feature that is new in this kernel, one
        bochs fix for qemu riscv and one atomic modesetting fix.
      
        I've left a few of the other late fixes until next as I didn't want to
        throw in anything that wasn't really necessary"
      
      * tag 'drm-fixes-2019-03-01' of git://anongit.freedesktop.org/drm/drm:
        drm/bochs: Fix the ID mismatch error
        drm: Block fb changes for async plane updates
        drm/amd/display: Use vrr friendly pageflip throttling in DC.
      6357c812
  3. 28 Feb, 2019 13 commits
    • Linus Torvalds's avatar
      Merge tag 'mips_fixes_5.0_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux · bf23aba1
      Linus Torvalds authored
      Pull MIPS fixes from Paul Burton:
       "A few more MIPS fixes:
      
         - Fix 16b cmpxchg() operations which could erroneously fail if bits
           15:8 of the old value are non-zero. In practice I'm not aware of
           any actual users of 16b cmpxchg() on MIPS, but this fixes the
           support for it was was introduced in v4.13.
      
         - Provide a struct device to dma_alloc_coherent for Lantiq XWAY
           systems with a "Voice MIPS Macro Core" (VMMC) device.
      
         - Provide DMA masks for BCM63xx ethernet devices, fixing a regression
           introduced in v4.19.
      
         - Fix memblock reservation for the kernel when the system has a
           non-zero PHYS_OFFSET, correcting the memblock conversion performed
           in v4.20"
      
      * tag 'mips_fixes_5.0_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
        MIPS: fix memory setup for platforms with PHYS_OFFSET != 0
        MIPS: BCM63XX: provide DMA masks for ethernet devices
        MIPS: lantiq: pass struct device to DMA API functions
        MIPS: fix truncation in __cmpxchg_small for short values
      bf23aba1
    • Linus Torvalds's avatar
      Merge tag 'for-linus-5.0-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux · 3eb07d20
      Linus Torvalds authored
      Pull orangefs fixlet from Mike Marshall:
       "Remove two un-needed BUG_ONs"
      
      * tag 'for-linus-5.0-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
        orangefs: remove two un-needed BUG_ONs...
      3eb07d20
    • Linus Torvalds's avatar
      Merge tag 'mmc-v5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · 3a8ed368
      Linus Torvalds authored
      Pull MMC fixes from Ulf Hansson:
       "MMC core:
         - Fix NULL ptr crash for a special test case
         - Align max segment size with logical block size to prevent bugs in
           v5.1-rc1.
      
        MMC host:
         - cqhci: Minor fixes
         - tmio: Prevent interrupt storm
         - tmio: Fixup SD/MMC card initialization
         - spi: Allow card to be detected during probe
         - sdhci-esdhc-imx: Fixup fix for ERR004536"
      
      * tag 'mmc-v5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: sdhci-esdhc-imx: correct the fix of ERR004536
        mmc: core: align max segment size with logical block size
        mmc: cqhci: Fix a tiny potential memory leak on error condition
        mmc: cqhci: fix space allocated for transfer descriptor
        mmc: core: Fix NULL ptr crash from mmc_should_fail_request
        mmc: tmio: fix access width of Block Count Register
        mmc: tmio_mmc_core: don't claim spurious interrupts
        mmc: spi: Fix card detection during probe
      3a8ed368
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 3f25a599
      Linus Torvalds authored
      Pull crypto fixes from Herbert Xu:
       "This fixes a compiler warning introduced by a previous fix, as well as
        two crash bugs on ARM"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: sha512/arm - fix crash bug in Thumb2 build
        crypto: sha256/arm - fix crash bug in Thumb2 build
        crypto: ccree - add missing inline qualifier
      3f25a599
    • Greg Kroah-Hartman's avatar
      kvm: properly check debugfs dentry before using it · 8ed0579c
      Greg Kroah-Hartman authored
      debugfs can now report an error code if something went wrong instead of
      just NULL.  So if the return value is to be used as a "real" dentry, it
      needs to be checked if it is an error before dereferencing it.
      
      This is now happening because of ff9fb72b ("debugfs: return error
      values, not NULL").  syzbot has found a way to trigger multiple debugfs
      files attempting to be created, which fails, and then the error code
      gets passed to dentry_path_raw() which obviously does not like it.
      Reported-by: default avatarEric Biggers <ebiggers@kernel.org>
      Reported-and-tested-by: syzbot+7857962b4d45e602b8ad@syzkaller.appspotmail.com
      Cc: "Radim Krčmář" <rkrcmar@redhat.com>
      Cc: kvm@vger.kernel.org
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8ed0579c
    • BOUGH CHEN's avatar
      mmc: sdhci-esdhc-imx: correct the fix of ERR004536 · e30be063
      BOUGH CHEN authored
      Commit 18094430 ("mmc: sdhci-esdhc-imx: add ADMA Length
      Mismatch errata fix") involve the fix of ERR004536, but the
      fix is incorrect. Double confirm with IC, need to clear the
      bit 7 of register 0x6c rather than set this bit 7.
      Here is the definition of bit 7 of 0x6c:
          0: enable the new IC fix for ERR004536
          1: do not use the IC fix, keep the same as before
      
      Find this issue on i.MX845s-evk board when enable CMDQ, and
      let system in heavy loading.
      
      root@imx8mmevk:~# dd if=/dev/mmcblk2 of=/dev/null bs=1M &
      root@imx8mmevk:~# memtester 1000M > /dev/zero &
      root@imx8mmevk:~# [  139.897220] mmc2: cqhci: timeout for tag 16
      [  139.901417] mmc2: cqhci: ============ CQHCI REGISTER DUMP ===========
      [  139.907862] mmc2: cqhci: Caps:      0x0000310a | Version:  0x00000510
      [  139.914311] mmc2: cqhci: Config:    0x00001001 | Control:  0x00000000
      [  139.920753] mmc2: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
      [  139.927193] mmc2: cqhci: Int sig:   0x00000006 | Int Coal: 0x00000000
      [  139.933634] mmc2: cqhci: TDL base:  0x7809c000 | TDL up32: 0x00000000
      [  139.940073] mmc2: cqhci: Doorbell:  0x00030000 | TCN:      0x00000000
      [  139.946518] mmc2: cqhci: Dev queue: 0x00010000 | Dev Pend: 0x00010000
      [  139.952967] mmc2: cqhci: Task clr:  0x00000000 | SSC1:     0x00011000
      [  139.959411] mmc2: cqhci: SSC2:      0x00000001 | DCMD rsp: 0x00000000
      [  139.965857] mmc2: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
      [  139.972308] mmc2: cqhci: Resp idx:  0x0000002e | Resp arg: 0x00000900
      [  139.978761] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
      [  139.985214] mmc2: sdhci: Sys addr:  0xb2c19000 | Version:  0x00000002
      [  139.991669] mmc2: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000400
      [  139.998127] mmc2: sdhci: Argument:  0x40110400 | Trn mode: 0x00000033
      [  140.004618] mmc2: sdhci: Present:   0x01088a8f | Host ctl: 0x00000030
      [  140.011113] mmc2: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
      [  140.017583] mmc2: sdhci: Wake-up:   0x00000008 | Clock:    0x0000000f
      [  140.024039] mmc2: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
      [  140.030497] mmc2: sdhci: Int enab:  0x107f4000 | Sig enab: 0x107f4000
      [  140.036972] mmc2: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000502
      [  140.043426] mmc2: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
      [  140.049867] mmc2: sdhci: Cmd:       0x00002c1a | Max curr: 0x00ffffff
      [  140.056314] mmc2: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
      [  140.062755] mmc2: sdhci: Resp[2]:   0x328f5903 | Resp[3]:  0x00d00f00
      [  140.069195] mmc2: sdhci: Host ctl2: 0x00000008
      [  140.073640] mmc2: sdhci: ADMA Err:  0x00000007 | ADMA Ptr: 0x7809c108
      [  140.080079] mmc2: sdhci: ============================================
      [  140.086662] mmc2: running CQE recovery
      
      Fixes: 18094430 ("mmc: sdhci-esdhc-imx: add ADMA Length Mismatch errata fix")
      Signed-off-by: default avatarHaibo Chen <haibo.chen@nxp.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      e30be063
    • Eric Biggers's avatar
      crypto: arm64/chacha - fix hchacha_block_neon() for big endian · f86d17e9
      Eric Biggers authored
      On big endian arm64 kernels, the xchacha20-neon and xchacha12-neon
      self-tests fail because hchacha_block_neon() outputs little endian words
      but the C code expects native endianness.  Fix it to output the words in
      native endianness (which also makes it match the arm32 version).
      
      Fixes: cc7cf991 ("crypto: arm64/chacha20 - add XChaCha20 support")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f86d17e9
    • Eric Biggers's avatar
      crypto: arm64/chacha - fix chacha_4block_xor_neon() for big endian · 4b6d196c
      Eric Biggers authored
      The change to encrypt a fifth ChaCha block using scalar instructions
      caused the chacha20-neon, xchacha20-neon, and xchacha12-neon self-tests
      to start failing on big endian arm64 kernels.  The bug is that the
      keystream block produced in 32-bit scalar registers is directly XOR'd
      with the data words, which are loaded and stored in native endianness.
      Thus in big endian mode the data bytes end up XOR'd with the wrong
      bytes.  Fix it by byte-swapping the keystream words in big endian mode.
      
      Fixes: 2fe55987 ("crypto: arm64/chacha - use combined SIMD/ALU routine for more speed")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      4b6d196c
    • Alistair Francis's avatar
      drm/bochs: Fix the ID mismatch error · 17fb465f
      Alistair Francis authored
      When running RISC-V QEMU with the Bochs device attached via PCIe the
      probe of the Bochs device fails with:
          [drm:bochs_hw_init] *ERROR* ID mismatch
      
      This was introduced by this commit:
          7780eb9c bochs: convert to drm_dev_register
      
      To fix the error we ensure that pci_enable_device() is called before
      bochs_load().
      
      Fixes: 7780eb9c ("bochs: convert to drm_dev_register")
      Signed-off-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      Reported-by: default avatarDavid Abdurachmanov <david.abdurachmanov@gmail.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20190221003231.31625-1-alistair.francis@wdc.comSigned-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      17fb465f
    • Nicholas Kazlauskas's avatar
      drm: Block fb changes for async plane updates · 22163229
      Nicholas Kazlauskas authored
      The prepare_fb call always happens on new_plane_state.
      
      The drm_atomic_helper_cleanup_planes checks to see if
      plane state pointer has changed when deciding to call cleanup_fb on
      either the new_plane_state or the old_plane_state.
      
      For a non-async atomic commit the state pointer is swapped, so this
      helper calls prepare_fb on the new_plane_state and cleanup_fb on the
      old_plane_state. This makes sense, since we want to prepare the
      framebuffer we are going to use and cleanup the the framebuffer we are
      no longer using.
      
      For the async atomic update helpers this differs. The async atomic
      update helpers perform in-place updates on the existing state. They call
      drm_atomic_helper_cleanup_planes but the state pointer is not swapped.
      This means that prepare_fb is called on the new_plane_state and
      cleanup_fb is called on the new_plane_state (not the old).
      
      In the case where old_plane_state->fb == new_plane_state->fb then
      there should be no behavioral difference between an async update
      and a non-async commit. But there are issues that arise when
      old_plane_state->fb != new_plane_state->fb.
      
      The first is that the new_plane_state->fb is immediately cleaned up
      after it has been prepared, so we're using a fb that we shouldn't
      be.
      
      The second occurs during a sequence of async atomic updates and
      non-async regular atomic commits. Suppose there are two framebuffers
      being interleaved in a double-buffering scenario, fb1 and fb2:
      
      - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
      - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
      - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
      
      We call cleanup_fb on fb2 twice in this example scenario, and any
      further use will result in use-after-free.
      
      The simple fix to this problem is to block framebuffer changes
      in the drm_atomic_helper_async_check function for now.
      
      v2: Move check by itself, add a FIXME (Daniel)
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
      Cc: <stable@vger.kernel.org> # v4.14+
      Fixes: fef9df8b ("drm/atomic: initial support for asynchronous plane update")
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Acked-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Acked-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Link: https://patchwork.freedesktop.org/patch/275364/Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      22163229
    • Thomas Bogendoerfer's avatar
      MIPS: fix memory setup for platforms with PHYS_OFFSET != 0 · e0bf304e
      Thomas Bogendoerfer authored
      For platforms, which use a PHYS_OFFSET != 0, symbol _end also
      contains that offset. So when calling memblock_reserve() for
      reserving kernel the size argument needs to be adjusted.
      
      Fixes: bcec54bf ("mips: switch to NO_BOOTMEM")
      Acked-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tbogendoerfer@suse.de>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org # v4.20+
      e0bf304e
    • Dave Airlie's avatar
      90b5e58e
    • Jann Horn's avatar
      mm: enforce min addr even if capable() in expand_downwards() · 0a1d5299
      Jann Horn authored
      security_mmap_addr() does a capability check with current_cred(), but
      we can reach this code from contexts like a VFS write handler where
      current_cred() must not be used.
      
      This can be abused on systems without SMAP to make NULL pointer
      dereferences exploitable again.
      
      Fixes: 8869477a ("security: protect from stack expansion into low vm addresses")
      Cc: stable@kernel.org
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0a1d5299
  4. 27 Feb, 2019 5 commits
    • Mario Kleiner's avatar
      drm/amd/display: Use vrr friendly pageflip throttling in DC. · d6371665
      Mario Kleiner authored
      In VRR mode, keep track of the vblank count of the last
      completed pageflip in amdgpu_crtc->last_flip_vblank, as
      recorded in the pageflip completion handler after each
      completed flip.
      
      Use that count to prevent mmio programming a new pageflip
      within the same vblank in which the last pageflip completed,
      iow. to throttle pageflips to at most one flip per video
      frame, while at the same time allowing to request a flip
      not only before start of vblank, but also anywhere within
      vblank.
      
      The old logic did the same, and made sense for regular fixed
      refresh rate flipping, but in vrr mode it prevents requesting
      a flip anywhere inside the possibly huge vblank, thereby
      reducing framerate in vrr mode instead of improving it, by
      delaying a slightly delayed flip requests up to a maximum
      vblank duration + 1 scanout duration. This would limit VRR
      usefulness to only help applications with a very high GPU
      demand, which can submit the flip request before start of
      vblank, but then have to wait long for fences to complete.
      
      With this method a flip can be both requested and - after
      fences have completed - executed, ie. it doesn't matter if
      the request (amdgpu_dm_do_flip()) gets delayed until deep
      into the extended vblank due to cpu execution delays. This
      also allows clients which want to regulate framerate within
      the vrr range a much more fine-grained control of flip timing,
      a feature that might be useful for video playback, and is
      very useful for neuroscience/vision research applications.
      
      In regular non-VRR mode, retain the old flip submission
      behavior. This to keep flip scheduling for fullscreen X11/GLX
      OpenGL clients intact, if they use the GLX_OML_sync_control
      extensions glXSwapBufferMscOML(, ..., target_msc,...) function
      with a specific target_msc target vblank count.
      
      glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
      not flip at the proper target_msc for a non-zero target_msc
      if VRR mode is active with this patch. They'd often flip one
      frame too early. However, this limitation should not matter
      much in VRR mode, as scheduling based on vblank counts is
      pretty futile/unusable under variable refresh duration
      anyway, so no real extra harm is done.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Michel Dänzer <michel@daenzer.net>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      d6371665
    • Ming Lei's avatar
      mmc: core: align max segment size with logical block size · c53336c8
      Ming Lei authored
      Logical block size is the lowest possible block size that the storage
      device can address. Max segment size is often related with controller's
      DMA capability. And it is reasonable to align max segment size with
      logical block size.
      
      SDHCI sets un-aligned max segment size, and causes ADMA error, so
      fix it by aligning max segment size with logical block size.
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
      Cc: Faiz Abbas <faiz_abbas@ti.com>
      Cc: linux-block@vger.kernel.org
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c53336c8
    • Alamy Liu's avatar
      mmc: cqhci: Fix a tiny potential memory leak on error condition · d07e9fad
      Alamy Liu authored
      Free up the allocated memory in the case of error return
      
      The value of mmc_host->cqe_enabled stays 'false'. Thus, cqhci_disable
      (mmc_cqe_ops->cqe_disable) won't be called to free the memory.  Also,
      cqhci_disable() seems to be designed to disable and free all resources, not
      suitable to handle this corner case.
      
      Fixes: a4080225 ("mmc: cqhci: support for command queue enabled host")
      Signed-off-by: default avatarAlamy Liu <alamy.liu@gmail.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      d07e9fad
    • Alamy Liu's avatar
      mmc: cqhci: fix space allocated for transfer descriptor · 27ec9dc1
      Alamy Liu authored
      There is not enough space being allocated when DCMD is disabled.
      
      CQE_DCMD is not necessary to be enabled when CQE is enabled.
      (Software could halt CQE to send command)
      
      In the case that CQE_DCMD is not enabled, it still needs to allocate
      space for data transfer. For instance:
        CQE_DCMD is enabled:  31 slots space (one slot used by DCMD)
        CQE_DCMD is disabled: 32 slots space
      
      Fixes: a4080225 ("mmc: cqhci: support for command queue enabled host")
      Signed-off-by: default avatarAlamy Liu <alamy.liu@gmail.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      27ec9dc1
    • Ritesh Harjani's avatar
      mmc: core: Fix NULL ptr crash from mmc_should_fail_request · e5723f95
      Ritesh Harjani authored
      In case of CQHCI, mrq->cmd may be NULL for data requests (non DCMD).
      In such case mmc_should_fail_request is directly dereferencing
      mrq->cmd while cmd is NULL.
      Fix this by checking for mrq->cmd pointer.
      
      Fixes: 72a5af55 ("mmc: core: Add support for handling CQE requests")
      Signed-off-by: default avatarRitesh Harjani <riteshh@codeaurora.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      e5723f95
  5. 26 Feb, 2019 2 commits
    • Julia Cartwright's avatar
      iommu/dmar: Fix buffer overflow during PCI bus notification · cffaaf0c
      Julia Cartwright authored
      Commit 57384592 ("iommu/vt-d: Store bus information in RMRR PCI
      device path") changed the type of the path data, however, the change in
      path type was not reflected in size calculations.  Update to use the
      correct type and prevent a buffer overflow.
      
      This bug manifests in systems with deep PCI hierarchies, and can lead to
      an overflow of the static allocated buffer (dmar_pci_notify_info_buf),
      or can lead to overflow of slab-allocated data.
      
         BUG: KASAN: global-out-of-bounds in dmar_alloc_pci_notify_info+0x1d5/0x2e0
         Write of size 1 at addr ffffffff90445d80 by task swapper/0/1
         CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.14.87-rt49-02406-gd0a0e96 #1
         Call Trace:
          ? dump_stack+0x46/0x59
          ? print_address_description+0x1df/0x290
          ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
          ? kasan_report+0x256/0x340
          ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
          ? e820__memblock_setup+0xb0/0xb0
          ? dmar_dev_scope_init+0x424/0x48f
          ? __down_write_common+0x1ec/0x230
          ? dmar_dev_scope_init+0x48f/0x48f
          ? dmar_free_unused_resources+0x109/0x109
          ? cpumask_next+0x16/0x20
          ? __kmem_cache_create+0x392/0x430
          ? kmem_cache_create+0x135/0x2f0
          ? e820__memblock_setup+0xb0/0xb0
          ? intel_iommu_init+0x170/0x1848
          ? _raw_spin_unlock_irqrestore+0x32/0x60
          ? migrate_enable+0x27a/0x5b0
          ? sched_setattr+0x20/0x20
          ? migrate_disable+0x1fc/0x380
          ? task_rq_lock+0x170/0x170
          ? try_to_run_init_process+0x40/0x40
          ? locks_remove_file+0x85/0x2f0
          ? dev_prepare_static_identity_mapping+0x78/0x78
          ? rt_spin_unlock+0x39/0x50
          ? lockref_put_or_lock+0x2a/0x40
          ? dput+0x128/0x2f0
          ? __rcu_read_unlock+0x66/0x80
          ? __fput+0x250/0x300
          ? __rcu_read_lock+0x1b/0x30
          ? mntput_no_expire+0x38/0x290
          ? e820__memblock_setup+0xb0/0xb0
          ? pci_iommu_init+0x25/0x63
          ? pci_iommu_init+0x25/0x63
          ? do_one_initcall+0x7e/0x1c0
          ? initcall_blacklisted+0x120/0x120
          ? kernel_init_freeable+0x27b/0x307
          ? rest_init+0xd0/0xd0
          ? kernel_init+0xf/0x120
          ? rest_init+0xd0/0xd0
          ? ret_from_fork+0x1f/0x40
         The buggy address belongs to the variable:
          dmar_pci_notify_info_buf+0x40/0x60
      
      Fixes: 57384592 ("iommu/vt-d: Store bus information in RMRR PCI device path")
      Signed-off-by: default avatarJulia Cartwright <julia@ni.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      cffaaf0c
    • Takeshi Saito's avatar
      mmc: tmio: fix access width of Block Count Register · 5603731a
      Takeshi Saito authored
      In R-Car Gen2 or later, the maximum number of transfer blocks are
      changed from 0xFFFF to 0xFFFFFFFF. Therefore, Block Count Register
      should use iowrite32().
      
      If another system (U-boot, Hypervisor OS, etc) uses bit[31:16], this
      value will not be cleared. So, SD/MMC card initialization fails.
      
      So, check for the bigger register and use apropriate write. Also, mark
      the register as extended on Gen2.
      Signed-off-by: default avatarTakeshi Saito <takeshi.saito.xv@renesas.com>
      [wsa: use max_blk_count in if(), add Gen2, update commit message]
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Cc: stable@kernel.org
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      [Ulf: Fixed build error]
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      5603731a
  6. 25 Feb, 2019 7 commits
    • Jonas Gorski's avatar
      MIPS: BCM63XX: provide DMA masks for ethernet devices · 18836b48
      Jonas Gorski authored
      The switch to the generic dma ops made dma masks mandatory, breaking
      devices having them not set. In case of bcm63xx, it broke ethernet with
      the following warning when trying to up the device:
      
      [    2.633123] ------------[ cut here ]------------
      [    2.637949] WARNING: CPU: 0 PID: 325 at ./include/linux/dma-mapping.h:516 bcm_enetsw_open+0x160/0xbbc
      [    2.647423] Modules linked in: gpio_button_hotplug
      [    2.652361] CPU: 0 PID: 325 Comm: ip Not tainted 4.19.16 #0
      [    2.658080] Stack : 80520000 804cd3ec 00000000 00000000 804ccc00 87085bdc 87d3f9d4 804f9a17
      [    2.666707]         8049cf18 00000145 80a942a0 00000204 80ac0000 10008400 87085b90 eb3d5ab7
      [    2.675325]         00000000 00000000 80ac0000 000022b0 00000000 00000000 00000007 00000000
      [    2.683954]         0000007a 80500000 0013b381 00000000 80000000 00000000 804a1664 80289878
      [    2.692572]         00000009 00000204 80ac0000 00000200 00000002 00000000 00000000 80a90000
      [    2.701191]         ...
      [    2.703701] Call Trace:
      [    2.706244] [<8001f3c8>] show_stack+0x58/0x100
      [    2.710840] [<800336e4>] __warn+0xe4/0x118
      [    2.715049] [<800337d4>] warn_slowpath_null+0x48/0x64
      [    2.720237] [<80289878>] bcm_enetsw_open+0x160/0xbbc
      [    2.725347] [<802d1d4c>] __dev_open+0xf8/0x16c
      [    2.729913] [<802d20cc>] __dev_change_flags+0x100/0x1c4
      [    2.735290] [<802d21b8>] dev_change_flags+0x28/0x70
      [    2.740326] [<803539e0>] devinet_ioctl+0x310/0x7b0
      [    2.745250] [<80355fd8>] inet_ioctl+0x1f8/0x224
      [    2.749939] [<802af290>] sock_ioctl+0x30c/0x488
      [    2.754632] [<80112b34>] do_vfs_ioctl+0x740/0x7dc
      [    2.759459] [<80112c20>] ksys_ioctl+0x50/0x94
      [    2.763955] [<800240b8>] syscall_common+0x34/0x58
      [    2.768782] ---[ end trace fb1a6b14d74e28b6 ]---
      [    2.773544] bcm63xx_enetsw bcm63xx_enetsw.0: cannot allocate rx ring 512
      
      Fix this by adding appropriate DMA masks for the platform devices.
      
      Fixes: f8c55dc6 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms")
      Signed-off-by: default avatarJonas Gorski <jonas.gorski@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: stable@vger.kernel.org # v4.19+
      18836b48
    • David Howells's avatar
      afs: Fix manually set volume location server list · 7d762d69
      David Howells authored
      When a cell with a volume location server list is added manually by
      echoing the details into /proc/net/afs/cells, a record is added but the
      flag saying it has been looked up isn't set.
      
      This causes the VL server rotation code to wait forever, with the top of
      /proc/pid/stack looking like:
      
      	afs_select_vlserver+0x3a6/0x6f3
      	afs_vl_lookup_vldb+0x4b/0x92
      	afs_create_volume+0x25/0x1b9
      	...
      
      with the thread stuck in afs_start_vl_iteration() waiting for
      AFS_CELL_FL_NO_LOOKUP_YET to be cleared.
      
      Fix this by clearing AFS_CELL_FL_NO_LOOKUP_YET when setting up a record
      if that record's details were supplied manually.
      
      Fixes: 0a5143f2 ("afs: Implement VL server rotation")
      Reported-by: default avatarDave Botsch <dwb7@cornell.edu>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7d762d69
    • Darrick J. Wong's avatar
      tmpfs: fix uninitialized return value in shmem_link · 29b00e60
      Darrick J. Wong authored
      When we made the shmem_reserve_inode call in shmem_link conditional, we
      forgot to update the declaration for ret so that it always has a known
      value.  Dan Carpenter pointed out this deficiency in the original patch.
      
      Fixes: 1062af92 ("tmpfs: fix link accounting when a tmpfile is linked in")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Matej Kupljen <matej.kupljen@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      29b00e60
    • Linus Torvalds's avatar
      Revert "x86/fault: BUG() when uaccess helpers fault on kernel addresses" · 53a41cb7
      Linus Torvalds authored
      This reverts commit 9da3f2b7.
      
      It was well-intentioned, but wrong.  Overriding the exception tables for
      instructions for random reasons is just wrong, and that is what the new
      code did.
      
      It caused problems for tracing, and it caused problems for strncpy_from_user(),
      because the new checks made perfectly valid use cases break, rather than
      catch things that did bad things.
      
      Unchecked user space accesses are a problem, but that's not a reason to
      add invalid checks that then people have to work around with silly flags
      (in this case, that 'kernel_uaccess_faults_ok' flag, which is just an
      odd way to say "this commit was wrong" and was sprinked into random
      places to hide the wrongness).
      
      The real fix to unchecked user space accesses is to get rid of the
      special "let's not check __get_user() and __put_user() at all" logic.
      Make __{get|put}_user() be just aliases to the regular {get|put}_user()
      functions, and make it impossible to access user space without having
      the proper checks in places.
      
      The raison d'être of the special double-underscore versions used to be
      that the range check was expensive, and if you did multiple user
      accesses, you'd do the range check up front (like the signal frame
      handling code, for example).  But SMAP (on x86) and PAN (on ARM) have
      made that optimization pointless, because the _real_ expense is the "set
      CPU flag to allow user space access".
      
      Do let's not break the valid cases to catch invalid cases that shouldn't
      even exist.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tobin C. Harding <tobin@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Jann Horn <jannh@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      53a41cb7
    • Sergei Shtylyov's avatar
      mmc: tmio_mmc_core: don't claim spurious interrupts · 5c27ff5d
      Sergei Shtylyov authored
      I have encountered an interrupt storm during the eMMC chip probing (and
      the chip finally didn't get detected).  It turned out that U-Boot left
      the DMAC interrupts enabled while the Linux driver  didn't use those.
      The SDHI driver's interrupt handler somehow assumes that, even if an
      SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
      that if none of the enabled interrupts happened and got handled, we
      should return IRQ_NONE -- that way the kernel IRQ code recoginizes
      a spurious interrupt and masks it off pretty quickly...
      
      Fixes: 7729c7a2 ("mmc: tmio: Provide separate interrupt handlers")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Tested-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      5c27ff5d
    • Jonathan Neuschäfer's avatar
      mmc: spi: Fix card detection during probe · c9bd505d
      Jonathan Neuschäfer authored
      When using the mmc_spi driver with a card-detect pin, I noticed that the
      card was not detected immediately after probe, but only after it was
      unplugged and plugged back in (and the CD IRQ fired).
      
      The call tree looks something like this:
      
      mmc_spi_probe
        mmc_add_host
          mmc_start_host
            _mmc_detect_change
              mmc_schedule_delayed_work(&host->detect, 0)
                mmc_rescan
                  host->bus_ops->detect(host)
                    mmc_detect
                      _mmc_detect_card_removed
                        host->ops->get_cd(host)
                          mmc_gpio_get_cd -> -ENOSYS (ctx->cd_gpio not set)
        mmc_gpiod_request_cd
          ctx->cd_gpio = desc
      
      To fix this issue, call mmc_detect_change after the card-detect GPIO/IRQ
      is registered.
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c9bd505d
    • Linus Torvalds's avatar
      Linux 5.0-rc8 · 5908e6b7
      Linus Torvalds authored
      5908e6b7
  7. 24 Feb, 2019 7 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · c3619a48
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "Bug fixes"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: MMU: record maximum physical address width in kvm_mmu_extended_role
        kvm: x86: Return LA57 feature based on hardware capability
        x86/kvm/mmu: fix switch between root and guest MMUs
        s390: vsie: Use effective CRYCBD.31 to check CRYCBD validity
      c3619a48
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · c4eb1e18
      Linus Torvalds authored
      Pull networking fixes from David Miller:
       "Hopefully the last pull request for this release. Fingers crossed:
      
         1) Only refcount ESP stats on full sockets, from Martin Willi.
      
         2) Missing barriers in AF_UNIX, from Al Viro.
      
         3) RCU protection fixes in ipv6 route code, from Paolo Abeni.
      
         4) Avoid false positives in untrusted GSO validation, from Willem de
            Bruijn.
      
         5) Forwarded mesh packets in mac80211 need more tailroom allocated,
            from Felix Fietkau.
      
         6) Use operstate consistently for linkup in team driver, from George
            Wilkie.
      
         7) ThunderX bug fixes from Vadim Lomovtsev. Mostly races between VF
            and PF code paths.
      
         8) Purge ipv6 exceptions during netdevice removal, from Paolo Abeni.
      
         9) nfp eBPF code gen fixes from Jiong Wang.
      
        10) bnxt_en firmware timeout fix from Michael Chan.
      
        11) Use after free in udp/udpv6 error handlers, from Paolo Abeni.
      
        12) Fix a race in x25_bind triggerable by syzbot, from Eric Dumazet"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (65 commits)
        net: phy: realtek: Dummy IRQ calls for RTL8366RB
        tcp: repaired skbs must init their tso_segs
        net/x25: fix a race in x25_bind()
        net: dsa: Remove documentation for port_fdb_prepare
        Revert "bridge: do not add port to router list when receives query with source 0.0.0.0"
        selftests: fib_tests: sleep after changing carrier. again.
        net: set static variable an initial value in atl2_probe()
        net: phy: marvell10g: Fix Multi-G advertisement to only advertise 10G
        bpf, doc: add bpf list as secondary entry to maintainers file
        udp: fix possible user after free in error handler
        udpv6: fix possible user after free in error handler
        fou6: fix proto error handler argument type
        udpv6: add the required annotation to mib type
        mdio_bus: Fix use-after-free on device_register fails
        net: Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255
        bnxt_en: Wait longer for the firmware message response to complete.
        bnxt_en: Fix typo in firmware message timeout logic.
        nfp: bpf: fix ALU32 high bits clearance bug
        nfp: bpf: fix code-gen bug on BPF_ALU | BPF_XOR | BPF_K
        Documentation: networking: switchdev: Update port parent ID section
        ...
      c4eb1e18
    • Linus Walleij's avatar
      net: phy: realtek: Dummy IRQ calls for RTL8366RB · 4c8e0459
      Linus Walleij authored
      This fixes a regression introduced by
      commit 0d2e778e
      "net: phy: replace PHY_HAS_INTERRUPT with a check for
      config_intr and ack_interrupt".
      
      This assumes that a PHY cannot trigger interrupt unless
      it has .config_intr() or .ack_interrupt() implemented.
      A later patch makes the code assume both need to be
      implemented for interrupts to be present.
      
      But this PHY (which is inside a DSA) will happily
      fire interrupts without either callback.
      
      Implement dummy callbacks for .config_intr() and
      .ack_interrupt() in the phy header to fix this.
      
      Tested on the RTL8366RB on D-Link DIR-685.
      
      Fixes: 0d2e778e ("net: phy: replace PHY_HAS_INTERRUPT with a check for config_intr and ack_interrupt")
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c8e0459
    • Eric Dumazet's avatar
      tcp: repaired skbs must init their tso_segs · bf50b606
      Eric Dumazet authored
      syzbot reported a WARN_ON(!tcp_skb_pcount(skb))
      in tcp_send_loss_probe() [1]
      
      This was caused by TCP_REPAIR sent skbs that inadvertenly
      were missing a call to tcp_init_tso_segs()
      
      [1]
      WARNING: CPU: 1 PID: 0 at net/ipv4/tcp_output.c:2534 tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
      Kernel panic - not syncing: panic_on_warn set ...
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc7+ #77
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       panic+0x2cb/0x65c kernel/panic.c:214
       __warn.cold+0x20/0x45 kernel/panic.c:571
       report_bug+0x263/0x2b0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:178 [inline]
       fixup_bug arch/x86/kernel/traps.c:173 [inline]
       do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
       do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
      RIP: 0010:tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
      Code: 88 fc ff ff 4c 89 ef e8 ed 75 c8 fb e9 c8 fc ff ff e8 43 76 c8 fb e9 63 fd ff ff e8 d9 75 c8 fb e9 94 f9 ff ff e8 bf 03 91 fb <0f> 0b e9 7d fa ff ff e8 b3 03 91 fb 0f b6 1d 37 43 7a 03 31 ff 89
      RSP: 0018:ffff8880ae907c60 EFLAGS: 00010206
      RAX: ffff8880a989c340 RBX: 0000000000000000 RCX: ffffffff85dedbdb
      RDX: 0000000000000100 RSI: ffffffff85dee0b1 RDI: 0000000000000005
      RBP: ffff8880ae907c90 R08: ffff8880a989c340 R09: ffffed10147d1ae1
      R10: ffffed10147d1ae0 R11: ffff8880a3e8d703 R12: ffff888091b90040
      R13: ffff8880a3e8d540 R14: 0000000000008000 R15: ffff888091b90860
       tcp_write_timer_handler+0x5c0/0x8a0 net/ipv4/tcp_timer.c:583
       tcp_write_timer+0x10e/0x1d0 net/ipv4/tcp_timer.c:607
       call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
       expire_timers kernel/time/timer.c:1362 [inline]
       __run_timers kernel/time/timer.c:1681 [inline]
       __run_timers kernel/time/timer.c:1649 [inline]
       run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
       __do_softirq+0x266/0x95a kernel/softirq.c:292
       invoke_softirq kernel/softirq.c:373 [inline]
       irq_exit+0x180/0x1d0 kernel/softirq.c:413
       exiting_irq arch/x86/include/asm/apic.h:536 [inline]
       smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
       </IRQ>
      RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
      Code: ff ff ff 48 89 c7 48 89 45 d8 e8 59 0c a1 fa 48 8b 45 d8 e9 ce fe ff ff 48 89 df e8 48 0c a1 fa eb 82 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
      RSP: 0018:ffff8880a98afd78 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
      RAX: 1ffffffff1125061 RBX: ffff8880a989c340 RCX: 0000000000000000
      RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffff8880a989cbbc
      RBP: ffff8880a98afda8 R08: ffff8880a989c340 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
      R13: ffffffff889282f8 R14: 0000000000000001 R15: 0000000000000000
       arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:555
       default_idle_call+0x36/0x90 kernel/sched/idle.c:93
       cpuidle_idle_call kernel/sched/idle.c:153 [inline]
       do_idle+0x386/0x570 kernel/sched/idle.c:262
       cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:353
       start_secondary+0x404/0x5c0 arch/x86/kernel/smpboot.c:271
       secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
      Kernel Offset: disabled
      Rebooting in 86400 seconds..
      
      Fixes: 79861919 ("tcp: fix TCP_REPAIR xmit queue setup")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Andrey Vagin <avagin@openvz.org>
      Cc: Soheil Hassas Yeganeh <soheil@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf50b606
    • Eric Dumazet's avatar
      net/x25: fix a race in x25_bind() · 797a22bd
      Eric Dumazet authored
      syzbot was able to trigger another soft lockup [1]
      
      I first thought it was the O(N^2) issue I mentioned in my
      prior fix (f657d22ee1f "net/x25: do not hold the cpu
      too long in x25_new_lci()"), but I eventually found
      that x25_bind() was not checking SOCK_ZAPPED state under
      socket lock protection.
      
      This means that multiple threads can end up calling
      x25_insert_socket() for the same socket, and corrupt x25_list
      
      [1]
      watchdog: BUG: soft lockup - CPU#0 stuck for 123s! [syz-executor.2:10492]
      Modules linked in:
      irq event stamp: 27515
      hardirqs last  enabled at (27514): [<ffffffff81006673>] trace_hardirqs_on_thunk+0x1a/0x1c
      hardirqs last disabled at (27515): [<ffffffff8100668f>] trace_hardirqs_off_thunk+0x1a/0x1c
      softirqs last  enabled at (32): [<ffffffff8632ee73>] x25_get_neigh+0xa3/0xd0 net/x25/x25_link.c:336
      softirqs last disabled at (34): [<ffffffff86324bc3>] x25_find_socket+0x23/0x140 net/x25/af_x25.c:341
      CPU: 0 PID: 10492 Comm: syz-executor.2 Not tainted 5.0.0-rc7+ #88
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__sanitizer_cov_trace_pc+0x4/0x50 kernel/kcov.c:97
      Code: f4 ff ff ff e8 11 9f ea ff 48 c7 05 12 fb e5 08 00 00 00 00 e9 c8 e9 ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 <48> 8b 75 08 65 48 8b 04 25 40 ee 01 00 65 8b 15 38 0c 92 7e 81 e2
      RSP: 0018:ffff88806e94fc48 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
      RAX: 1ffff1100d84dac5 RBX: 0000000000000001 RCX: ffffc90006197000
      RDX: 0000000000040000 RSI: ffffffff86324bf3 RDI: ffff88806c26d628
      RBP: ffff88806e94fc48 R08: ffff88806c1c6500 R09: fffffbfff1282561
      R10: fffffbfff1282560 R11: ffffffff89412b03 R12: ffff88806c26d628
      R13: ffff888090455200 R14: dffffc0000000000 R15: 0000000000000000
      FS:  00007f3a107e4700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f3a107e3db8 CR3: 00000000a5544000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       __x25_find_socket net/x25/af_x25.c:327 [inline]
       x25_find_socket+0x7d/0x140 net/x25/af_x25.c:342
       x25_new_lci net/x25/af_x25.c:355 [inline]
       x25_connect+0x380/0xde0 net/x25/af_x25.c:784
       __sys_connect+0x266/0x330 net/socket.c:1662
       __do_sys_connect net/socket.c:1673 [inline]
       __se_sys_connect net/socket.c:1670 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1670
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457e29
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f3a107e3c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e29
      RDX: 0000000000000012 RSI: 0000000020000200 RDI: 0000000000000005
      RBP: 000000000073c040 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3a107e46d4
      R13: 00000000004be362 R14: 00000000004ceb98 R15: 00000000ffffffff
      Sending NMI from CPU 0 to CPUs 1:
      NMI backtrace for cpu 1
      CPU: 1 PID: 10493 Comm: syz-executor.3 Not tainted 5.0.0-rc7+ #88
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__read_once_size include/linux/compiler.h:193 [inline]
      RIP: 0010:queued_write_lock_slowpath+0x143/0x290 kernel/locking/qrwlock.c:86
      Code: 4c 8d 2c 01 41 83 c7 03 41 0f b6 45 00 41 38 c7 7c 08 84 c0 0f 85 0c 01 00 00 8b 03 3d 00 01 00 00 74 1a f3 90 41 0f b6 55 00 <41> 38 d7 7c eb 84 d2 74 e7 48 89 df e8 cc aa 4e 00 eb dd be 04 00
      RSP: 0018:ffff888085c47bd8 EFLAGS: 00000206
      RAX: 0000000000000300 RBX: ffffffff89412b00 RCX: 1ffffffff1282560
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff89412b00
      RBP: ffff888085c47c70 R08: 1ffffffff1282560 R09: fffffbfff1282561
      R10: fffffbfff1282560 R11: ffffffff89412b03 R12: 00000000000000ff
      R13: fffffbfff1282560 R14: 1ffff11010b88f7d R15: 0000000000000003
      FS:  00007fdd04086700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fdd04064db8 CR3: 0000000090be0000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       queued_write_lock include/asm-generic/qrwlock.h:104 [inline]
       do_raw_write_lock+0x1d6/0x290 kernel/locking/spinlock_debug.c:203
       __raw_write_lock_bh include/linux/rwlock_api_smp.h:204 [inline]
       _raw_write_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:312
       x25_insert_socket+0x21/0xe0 net/x25/af_x25.c:267
       x25_bind+0x273/0x340 net/x25/af_x25.c:703
       __sys_bind+0x23f/0x290 net/socket.c:1481
       __do_sys_bind net/socket.c:1492 [inline]
       __se_sys_bind net/socket.c:1490 [inline]
       __x64_sys_bind+0x73/0xb0 net/socket.c:1490
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457e29
      
      Fixes: 90c27297 ("X.25 remove bkl in bind")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: andrew hendry <andrew.hendry@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      797a22bd
    • Hauke Mehrtens's avatar
      net: dsa: Remove documentation for port_fdb_prepare · 99407d8f
      Hauke Mehrtens authored
      This callback was removed some time ago, also remove the documentation.
      
      Fixes: 1b6dd556 ("net: dsa: Remove prepare phase for FDB")
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99407d8f
    • Hangbin Liu's avatar
      Revert "bridge: do not add port to router list when receives query with source 0.0.0.0" · 278e2148
      Hangbin Liu authored
      This reverts commit 5a2de63f ("bridge: do not add port to router list
      when receives query with source 0.0.0.0") and commit 0fe5119e ("net:
      bridge: remove ipv6 zero address check in mcast queries")
      
      The reason is RFC 4541 is not a standard but suggestive. Currently we
      will elect 0.0.0.0 as Querier if there is no ip address configured on
      bridge. If we do not add the port which recives query with source
      0.0.0.0 to router list, the IGMP reports will not be about to forward
      to Querier, IGMP data will also not be able to forward to dest.
      
      As Nikolay suggested, revert this change first and add a boolopt api
      to disable none-zero election in future if needed.
      Reported-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Reported-by: default avatarSebastian Gottschall <s.gottschall@newmedia-net.de>
      Fixes: 5a2de63f ("bridge: do not add port to router list when receives query with source 0.0.0.0")
      Fixes: 0fe5119e ("net: bridge: remove ipv6 zero address check in mcast queries")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      278e2148