1. 15 Jun, 2021 6 commits
  2. 14 Jun, 2021 28 commits
  3. 13 Jun, 2021 4 commits
    • Linus Torvalds's avatar
      Linux 5.13-rc6 · 009c9aa5
      Linus Torvalds authored
      009c9aa5
    • Linus Torvalds's avatar
      Merge tag 'perf-tools-fixes-for-v5.13-2021-06-13' of... · e4e45343
      Linus Torvalds authored
      Merge tag 'perf-tools-fixes-for-v5.13-2021-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
      
      Pull perf tools fixes from Arnaldo Carvalho de Melo:
      
       - Correct buffer copying when peeking events
      
       - Sync cpufeatures/disabled-features.h header with the kernel sources
      
      * tag 'perf-tools-fixes-for-v5.13-2021-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
        tools headers cpufeatures: Sync with the kernel sources
        perf session: Correct buffer copying when peeking events
      e4e45343
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-5.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · 960f0716
      Linus Torvalds authored
      Pull NFS client bugfixes from Trond Myklebust:
       "Highlights include:
      
        Stable fixes:
      
         - Fix use-after-free in nfs4_init_client()
      
        Bugfixes:
      
         - Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode()
      
         - Fix second deadlock in nfs4_evict_inode()
      
         - nfs4_proc_set_acl should not change the value of NFS_CAP_UIDGID_NOMAP
      
         - Fix setting of the NFS_CAP_SECURITY_LABEL capability"
      
      * tag 'nfs-for-5.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
        NFSv4: Fix second deadlock in nfs4_evict_inode()
        NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode()
        NFS: FMODE_READ and friends are C macros, not enum types
        NFS: Fix a potential NULL dereference in nfs_get_client()
        NFS: Fix use-after-free in nfs4_init_client()
        NFS: Ensure the NFS_CAP_SECURITY_LABEL capability is set when appropriate
        NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error.
      960f0716
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 331a6edb
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Four reasonably small fixes to the core for scsi host allocation
        failure paths.
      
        The root problem is that we're not freeing the memory allocated by
        dev_set_name(), which involves a rejig of may of the free on error
        paths to do put_device() instead of kfree which, in turn, has several
        other knock on ramifications and inspection turned up a few other
        lurking bugs"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: core: Only put parent device if host state differs from SHOST_CREATED
        scsi: core: Put .shost_dev in failure path if host state changes to RUNNING
        scsi: core: Fix failure handling of scsi_add_host_with_dma()
        scsi: core: Fix error handling of scsi_host_alloc()
      331a6edb
  4. 12 Jun, 2021 2 commits
    • Linus Torvalds's avatar
      Merge tag 'riscv-for-linus-5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux · 8ecfa36c
      Linus Torvalds authored
      Pull RISC-V fixes from Palmer Dabbelt:
      
       - A pair of XIP fixes: one to fix alternatives, and one to turn off the
         rest of the features that require code modification
      
       - A fix to a type that was causing some alternatives to break
      
       - A build fix for BUILTIN_DTB
      
      * tag 'riscv-for-linus-5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
        riscv: Fix BUILTIN_DTB for sifive and microchip soc
        riscv: alternative: fix typo in macro name
        riscv: code patching only works on !XIP_KERNEL
        riscv: xip: support runtime trap patching
      8ecfa36c
    • Feng Tang's avatar
      mm: relocate 'write_protect_seq' in struct mm_struct · 2e302543
      Feng Tang authored
      0day robot reported a 9.2% regression for will-it-scale mmap1 test
      case[1], caused by commit 57efa1fe ("mm/gup: prevent gup_fast from
      racing with COW during fork").
      
      Further debug shows the regression is due to that commit changes the
      offset of hot fields 'mmap_lock' inside structure 'mm_struct', thus some
      cache alignment changes.
      
      From the perf data, the contention for 'mmap_lock' is very severe and
      takes around 95% cpu cycles, and it is a rw_semaphore
      
              struct rw_semaphore {
                      atomic_long_t count;	/* 8 bytes */
                      atomic_long_t owner;	/* 8 bytes */
                      struct optimistic_spin_queue osq; /* spinner MCS lock */
                      ...
      
      Before commit 57efa1fe adds the 'write_protect_seq', it happens to
      have a very optimal cache alignment layout, as Linus explained:
      
       "and before the addition of the 'write_protect_seq' field, the
        mmap_sem was at offset 120 in 'struct mm_struct'.
      
        Which meant that count and owner were in two different cachelines,
        and then when you have contention and spend time in
        rwsem_down_write_slowpath(), this is probably *exactly* the kind
        of layout you want.
      
        Because first the rwsem_write_trylock() will do a cmpxchg on the
        first cacheline (for the optimistic fast-path), and then in the
        case of contention, rwsem_down_write_slowpath() will just access
        the second cacheline.
      
        Which is probably just optimal for a load that spends a lot of
        time contended - new waiters touch that first cacheline, and then
        they queue themselves up on the second cacheline."
      
      After the commit, the rw_semaphore is at offset 128, which means the
      'count' and 'owner' fields are now in the same cacheline, and causes
      more cache bouncing.
      
      Currently there are 3 "#ifdef CONFIG_XXX" before 'mmap_lock' which will
      affect its offset:
      
        CONFIG_MMU
        CONFIG_MEMBARRIER
        CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
      
      The layout above is on 64 bits system with 0day's default kernel config
      (similar to RHEL-8.3's config), in which all these 3 options are 'y'.
      And the layout can vary with different kernel configs.
      
      Relayouting a structure is usually a double-edged sword, as sometimes it
      can helps one case, but hurt other cases.  For this case, one solution
      is, as the newly added 'write_protect_seq' is a 4 bytes long seqcount_t
      (when CONFIG_DEBUG_LOCK_ALLOC=n), placing it into an existing 4 bytes
      hole in 'mm_struct' will not change other fields' alignment, while
      restoring the regression.
      
      Link: https://lore.kernel.org/lkml/20210525031636.GB7744@xsang-OptiPlex-9020/ [1]
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Signed-off-by: default avatarFeng Tang <feng.tang@intel.com>
      Reviewed-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Reviewed-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      Cc: Peter Xu <peterx@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2e302543