1. 20 Oct, 2021 11 commits
  2. 10 Oct, 2021 4 commits
    • Trond Myklebust's avatar
      NFS: Fix deadlocks in nfs_scan_commit_list() · 64a93dbf
      Trond Myklebust authored
      Partially revert commit 2ce209c4 ("NFS: Wait for requests that are
      locked on the commit list"), since it can lead to deadlocks between
      commit requests and nfs_join_page_group().
      For now we should assume that any locked requests on the commit list are
      either about to be removed and committed by another task, or the writes
      they describe are about to be retransmitted. In either case, we should
      not need to worry.
      
      Fixes: 2ce209c4 ("NFS: Wait for requests that are locked on the commit list")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      64a93dbf
    • Chuck Lever's avatar
      NFS: Instrument i_size_write() · 110cb2d2
      Chuck Lever authored
      Generate a trace event whenever the NFS client modifies the size of
      a file. These new events aid troubleshooting workloads that trigger
      races around size updates.
      
      There are four new trace points, all named nfs_size_something so
      they are easy to grep for or enable as a group with a single glob.
      
      Size updated on the server:
      
        kworker/u24:10-194   [010]   369.939174: nfs_size_update:      fileid=00:28:2 fhandle=0x36fbbe51 version=1752899344277980615 cursize=250471 newsize=172083
      
      Server-side size update reported via NFSv3 WCC attributes:
      
                   fsx-1387  [006]   380.760686: nfs_size_wcc:         fileid=00:28:2 fhandle=0x36fbbe51 version=1752899355909932456 cursize=146792 newsize=171216
      
      File has been truncated locally:
      
                   fsx-1387  [007]   369.437421: nfs_size_truncate:    fileid=00:28:2 fhandle=0x36fbbe51 version=1752899231200117272 cursize=215244 newsize=0
      
      File has been extended locally:
      
                   fsx-1387  [007]   369.439213: nfs_size_grow:        fileid=00:28:2 fhandle=0x36fbbe51 version=1752899343704248410 cursize=258048 newsize=262144
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      110cb2d2
    • Chuck Lever's avatar
      SUNRPC: Per-rpc_clnt task PIDs · 0392dd51
      Chuck Lever authored
      The current range of RPC task PIDs is 0..65535. That's not adequate
      for distinguishing tasks across multiple rpc_clnts running high
      throughput workloads.
      
      To help relieve this situation and to reduce the bottleneck of
      having a single atomic for assigning all RPC task PIDs, assign task
      PIDs per rpc_clnt.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      0392dd51
    • Chuck Lever's avatar
      NFS: Remove unnecessary TRACE_DEFINE_ENUM()s · 8e09650f
      Chuck Lever authored
      Clean up: TRACE_DEFINE_ENUM is unnecessary because the target
      symbols are all C macros, not enums.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      8e09650f
  3. 04 Oct, 2021 19 commits
  4. 03 Oct, 2021 6 commits
    • Linus Torvalds's avatar
      Linux 5.15-rc4 · 9e1ff307
      Linus Torvalds authored
      9e1ff307
    • Chen Jingwen's avatar
      elf: don't use MAP_FIXED_NOREPLACE for elf interpreter mappings · 9b2f72cc
      Chen Jingwen authored
      In commit b212921b ("elf: don't use MAP_FIXED_NOREPLACE for elf
      executable mappings") we still leave MAP_FIXED_NOREPLACE in place for
      load_elf_interp.
      
      Unfortunately, this will cause kernel to fail to start with:
      
          1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already
          Failed to execute /init (error -17)
      
      The reason is that the elf interpreter (ld.so) has overlapping segments.
      
        readelf -l ld-2.31.so
        Program Headers:
          Type           Offset             VirtAddr           PhysAddr
                         FileSiz            MemSiz              Flags  Align
          LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                         0x000000000002c94c 0x000000000002c94c  R E    0x10000
          LOAD           0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
                         0x00000000000021e8 0x0000000000002320  RW     0x10000
          LOAD           0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
                         0x00000000000011ac 0x0000000000001328  RW     0x10000
      
      The reason for this problem is the same as described in commit
      ad55eac7 ("elf: enforce MAP_FIXED on overlaying elf segments").
      
      Not only executable binaries, elf interpreters (e.g. ld.so) can have
      overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go
      back to MAP_FIXED in load_elf_interp.
      
      Fixes: 4ed28639 ("fs, elf: drop MAP_FIXED usage from elf_map")
      Cc: <stable@vger.kernel.org> # v4.19
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarChen Jingwen <chenjingwen6@huawei.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b2f72cc
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · ca3cef46
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Fix a number of ext4 bugs in fast_commit, inline data, and delayed
        allocation.
      
        Also fix error handling code paths in ext4_dx_readdir() and
        ext4_fill_super().
      
        Finally, avoid a grabbing a journal head in the delayed allocation
        write in the common cases where we are overwriting a pre-existing
        block or appending to an inode"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: recheck buffer uptodate bit under buffer lock
        ext4: fix potential infinite loop in ext4_dx_readdir()
        ext4: flush s_error_work before journal destroy in ext4_fill_super
        ext4: fix loff_t overflow in ext4_max_bitmap_size()
        ext4: fix reserved space counter leakage
        ext4: limit the number of blocks in one ADD_RANGE TLV
        ext4: enforce buffer head state assertion in ext4_da_map_blocks
        ext4: remove extent cache entries when truncating inline data
        ext4: drop unnecessary journal handle in delalloc write
        ext4: factor out write end code of inline file
        ext4: correct the error path of ext4_write_inline_data_end()
        ext4: check and update i_disksize properly
        ext4: add error checking to ext4_ext_replay_set_iblocks()
      ca3cef46
    • Linus Torvalds's avatar
      objtool: print out the symbol type when complaining about it · 7fab1c12
      Linus Torvalds authored
      The objtool warning that the kvm instruction emulation code triggered
      wasn't very useful:
      
          arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception
      
      in that it helpfully tells you which symbol name it had trouble figuring
      out the relocation for, but it doesn't actually say what the unknown
      symbol type was that triggered it all.
      
      In this case it was because of missing type information (type 0, aka
      STT_NOTYPE), but on the whole it really should just have printed that
      out as part of the message.
      
      Because if this warning triggers, that's very much the first thing you
      want to know - why did reloc2sec_off() return failure for that symbol?
      
      So rather than just saying you can't handle some type of symbol without
      saying what the type _was_, just print out the type number too.
      
      Fixes: 24ff6525 ("objtool: Teach get_alt_entry() about more relocation types")
      Link: https://lore.kernel.org/lkml/CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com/Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7fab1c12
    • Linus Torvalds's avatar
      kvm: fix objtool relocation warning · 291073a5
      Linus Torvalds authored
      The recent change to make objtool aware of more symbol relocation types
      (commit 24ff6525: "objtool: Teach get_alt_entry() about more
      relocation types") also added another check, and resulted in this
      objtool warning when building kvm on x86:
      
          arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception
      
      The reason seems to be that kvm_fastop_exception() is marked as a global
      symbol, which causes the relocation to ke kept around for objtool.  And
      at the same time, the kvm_fastop_exception definition (which is done as
      an inline asm statement) doesn't actually set the type of the global,
      which then makes objtool unhappy.
      
      The minimal fix is to just not mark kvm_fastop_exception as being a
      global symbol.  It's only used in that one compilation unit anyway, so
      it was always pointless.  That's how all the other local exception table
      labels are done.
      
      I'm not entirely happy about the kinds of games that the kvm code plays
      with doing its own exception handling, and the fact that it confused
      objtool is most definitely a symptom of the code being a bit too subtle
      and ad-hoc.  But at least this trivial one-liner makes objtool no longer
      upset about what is going on.
      
      Fixes: 24ff6525 ("objtool: Teach get_alt_entry() about more relocation types")
      Link: https://lore.kernel.org/lkml/CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com/
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Sean Christopherson <seanjc@google.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Wanpeng Li <wanpengli@tencent.com>
      Cc: Jim Mattson <jmattson@google.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      291073a5
    • Linus Torvalds's avatar
      Merge tag 'char-misc-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · 6761a0ae
      Linus Torvalds authored
      Pull char/misc driver fixes from Greg KH:
       "Here are some small misc driver fixes for 5.15-rc4. They are in two
        "groups":
      
         - ipack driver fixes for issues found by Johan Hovold
      
         - interconnect driver fixes for reported problems
      
        All of these have been in linux-next for a while with no reported
        issues"
      
      * tag 'char-misc-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        ipack: ipoctal: fix module reference leak
        ipack: ipoctal: fix missing allocation-failure check
        ipack: ipoctal: fix tty-registration error handling
        ipack: ipoctal: fix tty registration race
        ipack: ipoctal: fix stack information leak
        interconnect: qcom: sdm660: Add missing a2noc qos clocks
        dt-bindings: interconnect: sdm660: Add missing a2noc qos clocks
        interconnect: qcom: sdm660: Correct NOC_QOS_PRIORITY shift and mask
        interconnect: qcom: sdm660: Fix id of slv_cnoc_mnoc_cfg
      6761a0ae