1. 11 Dec, 2018 13 commits
  2. 09 Dec, 2018 20 commits
  3. 08 Dec, 2018 7 commits
    • Linus Torvalds's avatar
      Merge tag 'asm-generic-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic · 8214bdf7
      Linus Torvalds authored
      Pull asm-generic fix from Arnd Bergmann:
       "Multiple people reported a bug I introduced in asm-generic/unistd.h in
        4.20, this is the obvious bugfix to get glibc and others to correctly
        build again on new architectures that no longer provide the old
        fstatat64() family of system calls"
      
      * tag 'asm-generic-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
        asm-generic: unistd.h: fixup broken macro include.
      8214bdf7
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 570c9139
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "A few clk driver fixes this time:
      
         - Introduce protected-clock DT binding to fix breakage on qcom
           sdm845-mtp boards where the qspi clks introduced this merge window
           cause the firmware on those boards to take down the system if we
           try to read the clk registers
      
         - Fix a couple off-by-one errors found by Dan Carpenter
      
         - Handle failure in zynq fixed factor clk driver to avoid using
           uninitialized data"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: zynqmp: Off by one in zynqmp_is_valid_clock()
        clk: mmp: Off by one in mmp_clk_add()
        clk: mvebu: Off by one bugs in cp110_of_clk_get()
        arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks
        clk: qcom: Support 'protected-clocks' property
        dt-bindings: clk: Introduce 'protected-clocks' property
        clk: zynqmp: handle fixed factor param query error
      570c9139
    • Linus Torvalds's avatar
      Merge tag 'xfs-4.20-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · f896adc4
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
       "Here are hopefully the last set of fixes for 4.20.
      
        There's a fix for a longstanding statfs reporting problem with project
        quotas, a correction for page cache invalidation behaviors when
        fallocating near EOF, and a fix for a broken metadata verifier return
        code.
      
        Finally, the most important fix is to the pipe splicing code (aka the
        generic copy_file_range fallback) to avoid pointless short directio
        reads by only asking the filesystem for as much data as there are
        available pages in the pipe buffer. Our previous fix (simulated short
        directio reads because the number of pages didn't match the length of
        the read requested) caused subtle problems on overlayfs, so that part
        is reverted.
      
        Anyhow, this series passes fstests -g all on xfs and overlay+xfs, and
        has passed 17 billion fsx operations problem-free since I started
        testing
      
        Summary:
      
         - Fix broken project quota inode counts
      
         - Fix incorrect PAGE_MASK/PAGE_SIZE usage
      
         - Fix incorrect return value in btree verifier
      
         - Fix WARN_ON remap flags false positive
      
         - Fix splice read overflows"
      
      * tag 'xfs-4.20-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        iomap: partially revert 4721a601 (simulated directio short read on EFAULT)
        splice: don't read more than available pipe space
        vfs: allow some remap flags to be passed to vfs_clone_file_range
        xfs: fix inverted return from xfs_btree_sblock_verify_crc
        xfs: fix PAGE_MASK usage in xfs_free_file_space
        fs/xfs: fix f_ffree value for statfs when project quota is set
      f896adc4
    • David Rientjes's avatar
      Revert "mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask" · 356ff8a9
      David Rientjes authored
      This reverts commit 89c83fb5.
      
      This should have been done as part of 2f0799a0 ("mm, thp: restore
      node-local hugepage allocations").  The movement of the thp allocation
      policy from alloc_pages_vma() to alloc_hugepage_direct_gfpmask() was
      intended to only set __GFP_THISNODE for mempolicies that are not
      MPOL_BIND whereas the revert could set this regardless of mempolicy.
      
      While the check for MPOL_BIND between alloc_hugepage_direct_gfpmask()
      and alloc_pages_vma() was racy, that has since been removed since the
      revert.  What is left is the possibility to use __GFP_THISNODE in
      policy_node() when it is unexpected because the special handling for
      hugepages in alloc_pages_vma()  was removed as part of the consolidation.
      
      Secondly, prior to 89c83fb5, alloc_pages_vma() implemented a somewhat
      different policy for hugepage allocations, which were allocated through
      alloc_hugepage_vma().  For hugepage allocations, if the allocating
      process's node is in the set of allowed nodes, allocate with
      __GFP_THISNODE for that node (for MPOL_PREFERRED, use that node with
      __GFP_THISNODE instead).  This was changed for shmem_alloc_hugepage() to
      allow fallback to other nodes in 89c83fb5 as it did for new_page() in
      mm/mempolicy.c which is functionally different behavior and removes the
      requirement to only allocate hugepages locally.
      
      So this commit does a full revert of 89c83fb5 instead of the partial
      revert that was done in 2f0799a0.  The result is the same thp
      allocation policy for 4.20 that was in 4.19.
      
      Fixes: 89c83fb5 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask")
      Fixes: 2f0799a0
      
       ("mm, thp: restore node-local hugepage allocations")
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      356ff8a9
    • Benjamin Herrenschmidt's avatar
      Revert "net/ibm/emac: wrong bit is used for STA control" · 5b3279e2
      Benjamin Herrenschmidt authored
      This reverts commit 624ca9c3
      
      .
      
      This commit is completely bogus. The STACR register has two formats, old
      and new, depending on the version of the IP block used. There's a pair of
      device-tree properties that can be used to specify the format used:
      
      	has-inverted-stacr-oc
      	has-new-stacr-staopc
      
      What this commit did was to change the bit definition used with the old
      parts to match the new parts. This of course breaks the driver on all
      the old ones.
      
      Instead, the author should have set the appropriate properties in the
      device-tree for the variant used on his board.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b3279e2
    • David S. Miller's avatar
      Merge branch 'skb-headroom-slab-out-of-bounds' · 8b78903b
      David S. Miller authored
      
      Stefano Brivio says:
      
      ====================
      Fix slab out-of-bounds on insufficient headroom for IPv6 packets
      
      Patch 1/2 fixes a slab out-of-bounds occurring with short SCTP packets over
      IPv4 over L2TP over IPv6 on a configuration with relatively low HEADER_MAX.
      
      Patch 2/2 makes sure we avoid writing before the allocated buffer in
      neigh_hh_output() in case the headroom is enough for the unaligned hardware
      header size, but not enough for the aligned one, and that we warn if we hit
      this condition.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b78903b
    • Stefano Brivio's avatar
      neighbour: Avoid writing before skb->head in neigh_hh_output() · e6ac64d4
      Stefano Brivio authored
      
      While skb_push() makes the kernel panic if the skb headroom is less than
      the unaligned hardware header size, it will proceed normally in case we
      copy more than that because of alignment, and we'll silently corrupt
      adjacent slabs.
      
      In the case fixed by the previous patch,
      "ipv6: Check available headroom in ip6_xmit() even without options", we
      end up in neigh_hh_output() with 14 bytes headroom, 14 bytes hardware
      header and write 16 bytes, starting 2 bytes before the allocated buffer.
      
      Always check we're not writing before skb->head and, if the headroom is
      not enough, warn and drop the packet.
      
      v2:
       - instead of panicking with BUG_ON(), WARN_ON_ONCE() and drop the packet
         (Eric Dumazet)
       - if we avoid the panic, though, we need to explicitly check the headroom
         before the memcpy(), otherwise we'll have corrupted slabs on a running
         kernel, after we warn
       - use __skb_push() instead of skb_push(), as the headroom check is
         already implemented here explicitly (Eric Dumazet)
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6ac64d4