1. 08 Oct, 2021 18 commits
  2. 05 Oct, 2021 15 commits
  3. 04 Oct, 2021 1 commit
    • Mauro Carvalho Chehab's avatar
      Merge tag 'v5.15-rc4' into media_tree · c52e7b85
      Mauro Carvalho Chehab authored
      Linux 5.15-rc4
      
      * tag 'v5.15-rc4': (320 commits)
        Linux 5.15-rc4
        elf: don't use MAP_FIXED_NOREPLACE for elf interpreter mappings
        objtool: print out the symbol type when complaining about it
        kvm: fix objtool relocation warning
        cachefiles: Fix oops in trace_cachefiles_mark_buried due to NULL object
        drm/i915: fix blank screen booting crashes
        hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field
        hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field
        hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field
        hwmon: (pmbus/mp2975) Add missed POUT attribute for page 1 mp2975 controller
        hwmon: (pmbus/ibm-cffps) max_power_out swap changes
        hwmon: (occ) Fix P10 VRM temp sensors
        thermal: Update information in MAINTAINERS
        io_uring: kill fasync
        sched: Always inline is_percpu_thread()
        sched/fair: Null terminate buffer when updating tunable_scaling
        sched/fair: Add ancestors of unthrottled undecayed cfs_rq
        perf/core: fix userpage->time_enabled of inactive events
        perf/x86/intel: Update event constraints for ICX
        perf/x86: Reset destroy callback on event init failure
        ...
      c52e7b85
  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