Pull liveupdate fixes from Mike Rapoport:
 "Two kexec handover regression fixes:

   - fix order calculation for kho_unpreserve_pages() to make sure sure
     that the order calculation in kho_unpreserve_pages() mathes the
     order calculation in kho_preserve_pages().

   - fix math in calculation of KHO_TREE_MAX_DEPTH to make it work with
     16KB pages"

* tag 'liveupdate-fixes-2026-05-30' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux:
  kho: fix order calculation for kho_unpreserve_pages()
  kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes

Pull misc fixes from Andrew Morton:
 "13 hotfixes. 9 are for MM. 9 are cc:stable and the remaining 4 address
  post-7.1 issues or aren't considered suitable for backporting.

  All patches are singletons - please see the individual changelogs for
  details"

* tag 'mm-hotfixes-stable-2026-05-25-16-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  Revert "mm: introduce a new page type for page pool in page type"
  mm/vmalloc: do not trigger BUG() on BH disabled context
  MAINTAINERS, mailmap: change email for Eugen Hristev
  mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page
  kernel/fork: validate exit_signal in kernel_clone()
  mm: memcontrol: propagate NMI slab stats to memcg vmstats
  mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()
  mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one
  zram: fix use-after-free in zram_writeback_endio
  memfd: deny writeable mappings when implying SEAL_WRITE
  ipc: limit next_id allocation to the valid ID range
  Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"
  MAINTAINERS: .mailmap: update after GEHC spin-off

Commit 91e74fa8b1bc ("kho: make sure preservations do not span multiple
NUMA nodes") made sure preservations from kho_preserve_pages() do not
span multiple NUMA nodes. If they do, the order is reduced and tried
again.

The same logic was not implemented for kho_unpreserve_pages(). This can
result in unpreserve calculating a different order than preserve, and
thus not actually unpreserving the pages.

Fix this by moving the order calculation logic to
__kho_preserve_pages_order() and use it from both preserve and
unpreserve paths.

Move __kho_unpreserve() down to avoid having a forward declaration. Its
users are further down in the file anyway. Also, it results in grouping
for all the page-level preservation and unpreservation functions. This
unfortunately makes the diff hard to read, but the main change in
__kho_unpreserve() is to call __kho_preserve_pages_order() instead of
open-coding the order calculation.

Fixes: 91e74fa8b1bc ("kho: make sure preservations do not span multiple NUMA nodes")
Cc: stable@vger.kernel.org
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Link: https://patch.msgid.link/20260519133332.2498092-1-pratyush@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

Pull bpf fixes from Alexei Starovoitov:

 - Fix bpf_throw() and global subprog combination (Kumar Kartikeya
   Dwivedi)

 - Fix out of bounds access in BPF interpreter (Yazhou Tang)

 - Fix potential out of bounds access in inner per-cpu array map
   (Guannan Wang)

 - Reject NULL data/sig in bpf_verify_pkcs7_signature (KP Singh)

* tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
  libbpf: fix off-by-one in emit_signature_match jump offset
  bpf: Reject NULL data/sig in bpf_verify_pkcs7_signature
  selftests/bpf: Cover global subprog exception leaks
  bpf: Check global subprog exception paths
  bpf: make bpf_session_is_return() reference optional
  bpf: Use array_map_meta_equal for percpu array inner map replacement
  selftests/bpf: Add test for large offset bpf-to-bpf call
  bpf: Fix s16 truncation for large bpf-to-bpf call offsets
  bpf: Fix out-of-bounds read in bpf_patch_call_args()

Pull sched_ext fixes from Tejun Heo:

 - Spurious WARN in ops_dequeue() racing with concurrent dispatch

 - Self-deadlock between scheduler disable and a concurrent sub-sched
   enable

* tag 'sched_ext-for-7.1-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext:
  sched_ext: Fix spurious WARN on stale ops_state in ops_dequeue()
  sched_ext: Fix deadlock between scx_root_disable() and concurrent forks

Pull cgroup fixes from Tejun Heo:
 "Two rstat fixes:

   - Out-of-bounds access in the css_rstat_updated() BPF kfunc when
     called with an unchecked user-supplied cpu

   - Over-strict NMI guard after the recent switch to try_cmpxchg left
     sparc and ppc64 unable to queue rstat updates from NMI"

* tag 'cgroup-for-7.1-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: rstat: relax NMI guard after switch to try_cmpxchg
  cgroup/rstat: validate cpu before css_rstat_cpu() access

Pull dma-mapping fixes from Marek Szyprowski:
 "Two minor updates for the DMA-mapping code, mainly fixing some rare
  corner cases (Petr Tesarik, Jianpeng Chang)"

* tag 'dma-mapping-7.1-2026-05-22' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  dma-mapping: move dma_map_resource() sanity check into debug code
  dma-direct: fix use of max_pfn

Pull tracing fixes from Steven Rostedt:

 - Avoid NULL return from hist_field_name()

   The function hist_field_name() is directly passed to a strcat() which
   does not handle "NULL" characters. Return a zero length string when
   size is greater than the limit.

   This is used only to output already created histograms and no field
   currently is greater than the limit. But it should still not return
   NULL.

 - Do not call map->ops->elt_free() on allocation failure

   When elt_alloc() fails, it should not call the map->ops->elt_free()
   function if it exists, as that function may not be able to handle the
   free on allocation failures. The ->elt_free() should only be called
   when elt_alloc() succeeds.

* tag 'trace-v7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  tracing: Do not call map->ops->elt_free() if elt_alloc() fails
  tracing: Avoid NULL return from hist_field_name() on truncation

When a child process exits, it sends exit_signal to its parent via
do_notify_parent().  The clone() syscall constructs exit_signal as:

(lower_32_bits(clone_flags) & CSIGNAL)

CSIGNAL is 0xff, so values in the range 65-255 are possible.  However,
valid_signal() only accepts signals up to _NSIG (64 on x86_64).  A
non-zero non-valid exit_signal acts the same as exit_signal == 0: the
parent process is not signaled when the child terminates.

The syzkaller reproducer triggers this by calling clone() with flags=0x80,
resulting in exit_signal = (0x80 & CSIGNAL) = 128, which exceeds _NSIG and
is not a valid signal.

The v1 of this patch added the check only in the clone() syscall handler,
which is incomplete.  kernel_clone() has other callers such as
sys_ia32_clone() which would remain unprotected.  Move the check to
kernel_clone() to cover all callers.

Since the valid_signal() check is now in kernel_clone() and covers all
callers including clone3(), the same check in copy_clone_args_from_user()
becomes redundant and is removed.  The higher 32bits check for clone3() is
kept as it is clone3() specific.

Note that this is a user-visible change: previously, passing an invalid
exit_signal to clone() was silently accepted.  The man page for clone()
does not document any defined behavior for invalid exit_signal values, so
rejecting them with -EINVAL is the correct behavior.  It is unlikely that
any sane application relies on passing an invalid exit_signal.

[oleg@redhat.com: the comment above kernel_clone() should be updated]
  Link: https://lore.kernel.org/abwvgU17W8wuW2-J@redhat.com
Link: https://lore.kernel.org/20260316151956.563558-1-kartikey406@gmail.com
Fixes: 3f2c788a1314 ("fork: prevent accidental access to clone3 features")
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: syzbot+bbe6b99feefc3a0842de@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=bbe6b99feefc3a0842de
Tested-by: syzbot+bbe6b99feefc3a0842de@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/20260307064202.353405-1-kartikey406@gmail.com/T/ [v1]
Link: https://lore.kernel.org/all/20260316104536.558108-1-kartikey406@gmail.com/T/ [v2]
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Ben Segall <bsegall@google.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Liam Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Pull ring-buffer fixes from Steven Rostedt:

 - Fix reporting MISSED EVENTS in trace iterator

   When the "trace" file is read with tracing enabled, if the writer
   were to pass the iterator reader, it resets, sets a "missed_events"
   flag and continues. The tracing output checks for missed events and
   if there are some, it prints out "[LOST EVENTS]" to let the user know
   events were dropped.

   But the clearing of the missed_events happened when the tracing
   system queried the ring buffer iterator about missed events. This was
   premature as the ring buffer is per CPU, and the tracing code reads
   all the CPU buffers and checks for missed events when it is read. If
   the CPU iterator that had missed events isn't printed next, the
   output for the LOST EVENTS is lost.

   Clear the missed_events flag when the iterator moves to the next
   event and not when the missed_events flag is queried. Also clear it
   on reset.

 - Flush and stop the persistent ring buffer on panic

   On panic the persistent ring buffer is used to debug what caused the
   panic. But on some architectures, it requires flushing the memory
   from cache, otherwise, the ring buffer persistent memory may not have
   the last events and this could also cause the ring buffer to be
   corrupted on the next boot.

 - Fix nr_subbufs initialization in simple_ring_buffer_init_mm

   The remote simple ring buffer meta data nr_subbufs is initialized too
   early and gets cleared later on, making it zero and not reflect the
   actual number of sub-buffers.

 - Fix unload_page for simple_ring_buffer init rollback

   On error, the pages loaded need to be unloaded. To unload a page it
   is expected that: page = load_page(va); -> unload_page(page). But the
   code was doing: unload_page(va) and not unload_page(page).

 - Create output file from cmd_check_undefined

   The check for undefined symbols checks if the file *.o.checked exists
   and if so it skips doing the work. But the *.o.checked file never was
   created making every build do the work even when it was already done
   previously.

* tag 'trace-ringbuffer-v7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  tracing: Create output file from cmd_check_undefined
  tracing: Fix unload_page for simple_ring_buffer init rollback
  tracing: Fix nr_subbufs initialization in simple_ring_buffer_init_mm()
  ring-buffer: Flush and stop persistent ring buffer on panic
  ring-buffer: Fix reporting of missed events in iterator