mbox series

[GIT,PULL] hotfixes for 6.10-rc5

Message ID 20240617114712.45d4743f8bacb832dea4b5a9@linux-foundation.org (mailing list archive)
State New
Headers show
Series [GIT,PULL] hotfixes for 6.10-rc5 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-hotfixes-stable-2024-06-17-11-43

Message

Andrew Morton June 17, 2024, 6:47 p.m. UTC
Linus, please merge this batch of hotfixes, thanks.


The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670:

  Linux 6.10-rc3 (2024-06-09 14:19:43 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-hotfixes-stable-2024-06-17-11-43

for you to fetch changes up to 01c8f9806bde438ca1c8cbbc439f0a14a6694f6c:

  kcov: don't lose track of remote references during softirqs (2024-06-15 10:43:08 -0700)

----------------------------------------------------------------
19 hotfixes, 8 of which are cc:stable.

Mainly MM singleton fixes.  And a couple of ocfs2 regression fixes.

----------------------------------------------------------------
Aleksandr Nogikh (1):
      kcov: don't lose track of remote references during softirqs

Baolin Wang (1):
      mm: shmem: fix getting incorrect lruvec when replacing a shmem folio

David Hildenbrand (1):
      Revert "mm: init_mlocked_on_free_v3"

Hugh Dickins (1):
      mm/migrate: fix kernel BUG at mm/compaction.c:2761!

Jeff Xu (1):
      mm/memfd: add documentation for MFD_NOEXEC_SEAL MFD_EXEC

Joseph Qi (2):
      ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()
      ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()

Kefeng Wang (1):
      mm: fix possible OOB in numa_rebuild_large_mapping()

Lorenzo Stoakes (1):
      MAINTAINERS: remove Lorenzo as vmalloc reviewer

Mark Brown (1):
      selftests: mm: make map_fixed_noreplace test names stable

Oleg Nesterov (1):
      zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING

Peter Oberparleiter (1):
      gcov: add support for GCC 14

Peter Xu (2):
      mm/page_table_check: fix crash on ZONE_DEVICE
      mm/debug_vm_pgtable: drop RANDOM_ORVALUE trick

Rafael Aquini (1):
      mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

Ran Xiaokai (1):
      mm: huge_memory: fix misused mapping_large_folio_support() for anon folios

Suren Baghdasaryan (2):
      lib/alloc_tag: do not register sysctl interface when CONFIG_SYSCTL=n
      lib/alloc_tag: fix RCU imbalance in pgalloc_tag_get()

Yury Norov (1):
      gcc: disable '-Warray-bounds' for gcc-9

 Documentation/admin-guide/kernel-parameters.txt  |   6 -
 Documentation/userspace-api/index.rst            |   1 +
 Documentation/userspace-api/mfd_noexec.rst       |  86 ++++++++++
 MAINTAINERS                                      |   1 -
 arch/Kconfig                                     |  12 ++
 fs/ocfs2/journal.c                               | 192 +++++++++++++----------
 fs/ocfs2/ocfs2.h                                 |  27 ++++
 fs/ocfs2/super.c                                 |   4 +-
 include/linux/kcov.h                             |   2 +
 include/linux/mm.h                               |   9 +-
 include/linux/pagemap.h                          |   4 +
 include/linux/pgalloc_tag.h                      |  11 +-
 init/Kconfig                                     |   2 +-
 kernel/gcov/gcc_4_7.c                            |   4 +-
 kernel/kcov.c                                    |   1 +
 kernel/pid_namespace.c                           |   1 +
 lib/alloc_tag.c                                  |  16 +-
 mm/debug_vm_pgtable.c                            |  31 +---
 mm/huge_memory.c                                 |  28 ++--
 mm/internal.h                                    |   1 -
 mm/memcontrol.c                                  |   3 +-
 mm/memory.c                                      |  20 +--
 mm/migrate.c                                     |   8 +-
 mm/mm_init.c                                     |  43 +----
 mm/page_alloc.c                                  |   2 +-
 mm/page_table_check.c                            |  11 +-
 mm/shmem.c                                       |   2 +-
 security/Kconfig.hardening                       |  15 --
 tools/testing/selftests/mm/map_fixed_noreplace.c |  24 ++-
 29 files changed, 345 insertions(+), 222 deletions(-)
 create mode 100644 Documentation/userspace-api/mfd_noexec.rst

Comments

Linus Torvalds June 17, 2024, 8:09 p.m. UTC | #1
On Mon, 17 Jun 2024 at 11:47, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Rafael Aquini (1):
>       mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

No.

And HELL NO!

We're not adding *another* new random incomprehensible config option
that tries to fix a random case that no normal user will understand.

Our kernel config is too damn complex as-is. We're not making it worse
like this. Anybody who cares about this kind of crazy esoteric detail
can damn well just set their Kconfig manually, instead of forcing this
kind of insane questions on other people.

This Kconfig insanity needs to stop. Why do I need to be the person who says

  "STOP ASKING POOR USERS IDIOTIC QUESTIONS THAT THEY CAN'T SANELY ANSWER"

I've pulled, but I'm reverting this commit. We are *not* going down
this path of insanity.

I'd also like to note that the reported 32-bit issue was ALREADY FIXED
months ago by commit 4ef9ad19e176 ("mm: huge_memory: don't force huge
page alignment on 32 bit")

It's possible that we should extend that - much saner - fix to also
look at the number of bits for randomization even outside of 32-bit
processes, and judge things on the number of bits we're expected to
randomize mappings on.

So it's very possible that the

        if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
                return 0;

test in __thp_get_unmapped_area() should be extended to take requested
address randomization into account.

But there is NO WAY this is fixed with another completely
incomprehensible Kconfig option.

So I'm really unhappy about this. The whole "add idiotic random
Kconfig options" needs to stop.

Those options are not something a normal person can understand, and as
shown by the fact that this patch was already bogus and superseded by
a much better patch from months ago, clearly said Kconfig options
WEREN'T EVEN UNDERSTOOD BY VM MAINTAINERS!

Christ. Sorry for the shouting, but dammit, people need to really
internalize the whole "we don't add crazy Kconfig options".

                    Linus
Matthew Wilcox June 17, 2024, 8:17 p.m. UTC | #2
On Mon, Jun 17, 2024 at 01:09:15PM -0700, Linus Torvalds wrote:
> On Mon, 17 Jun 2024 at 11:47, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > Rafael Aquini (1):
> >       mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

This patch wasn't even cc'd to linux-mm, so I never saw it.  I would
have NAKed it based on this already being fixed.

https://lore.kernel.org/all/20240606180622.102099-1-aquini@redhat.com/
pr-tracker-bot@kernel.org June 17, 2024, 8:20 p.m. UTC | #3
The pull request you sent on Mon, 17 Jun 2024 11:47:12 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-hotfixes-stable-2024-06-17-11-43

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e6b324fbf2de1797a4756fe2a489442464738dad

Thank you!
Linus Torvalds June 17, 2024, 8:23 p.m. UTC | #4
On Mon, 17 Jun 2024 at 13:17, Matthew Wilcox <willy@infradead.org> wrote:
>
> This patch wasn't even cc'd to linux-mm, so I never saw it.  I would
> have NAKed it based on this already being fixed.

I actually cc'd y ou partly because you were part of that earlier fix,
but also because of the implicit question:

  "So it's very possible that the

        if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall())
                return 0;

   test in __thp_get_unmapped_area() should be extended to take requested
   address randomization into account"

and whether we maybe could do better?

For x86-64, the default for min compat bits is 28 - which is
presumably plenty - but maybe we have issues elsewhere?

               Linus