All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Xu <peterx@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Andreas Larsson <andreas@gaisler.com>,
	"James E . J . Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>
Subject: [PATCH 5.10.y 0/4]  fix error handling in mmap_region() and refactor (hotfixes)
Date: Fri, 15 Nov 2024 12:36:50 +0000	[thread overview]
Message-ID: <cover.1731670097.git.lorenzo.stoakes@oracle.com> (raw)

Critical fixes for mmap_region(), backported to 5.10.y.

Some notes on differences from upstream:

* We do NOT take commit 0fb4a7ad270b ("mm: refactor
  map_deny_write_exec()"), as this refactors code only introduced in 6.2.

* We make reference in "mm: refactor arch_calc_vm_flag_bits() and arm64 MTE
  handling" to parisc, but the referenced functionality does not exist in
  this kernel.

* In this kernel is_shared_maywrite() does not exist and the code uses
  VM_SHARED to determine whether mapping_map_writable() /
  mapping_unmap_writable() should be invoked. This backport therefore
  follows suit.

* The vma_dummy_vm_ops static global doesn't exist in this kernel, so we
  use a local static variable in mmap_file() and vma_close().

* Each version of these series is confronted by a slightly different
  mmap_region(), so we must adapt the change for each stable version. The
  approach remains the same throughout, however, and we correctly avoid
  closing the VMA part way through any __mmap_region() operation.

* In 5.10 we must handle VM_DENYWRITE. Since this is done at the top of the
  file-backed VMA handling logic, and importantly before mmap_file() invocation,
  this does not imply any additional difficult error handling on partial
  completion of mapping so has no significant impact.

Lorenzo Stoakes (4):
  mm: avoid unsafe VMA hook invocation when error arises on mmap hook
  mm: unconditionally close VMAs on error
  mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling
  mm: resolve faulty mmap_region() error path behaviour

 arch/arm64/include/asm/mman.h | 10 +++--
 include/linux/mman.h          |  7 +--
 mm/internal.h                 | 19 ++++++++
 mm/mmap.c                     | 82 +++++++++++++++++++++--------------
 mm/nommu.c                    |  9 ++--
 mm/shmem.c                    |  3 --
 mm/util.c                     | 33 ++++++++++++++
 7 files changed, 117 insertions(+), 46 deletions(-)

--
2.47.0

             reply	other threads:[~2024-11-15 12:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 12:36 Lorenzo Stoakes [this message]
2024-11-15 12:36 ` [PATCH 5.10.y 1/4] mm: avoid unsafe VMA hook invocation when error arises on mmap hook Lorenzo Stoakes
2024-11-19 14:24   ` Patch "mm: avoid unsafe VMA hook invocation when error arises on mmap hook" has been added to the 5.10-stable tree gregkh
2024-11-15 12:36 ` [PATCH 5.10.y 2/4] mm: unconditionally close VMAs on error Lorenzo Stoakes
2024-11-19 14:24   ` Patch "mm: unconditionally close VMAs on error" has been added to the 5.10-stable tree gregkh
2024-11-15 12:36 ` [PATCH 5.10.y 3/4] mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling Lorenzo Stoakes
2024-11-19 14:24   ` Patch "mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling" has been added to the 5.10-stable tree gregkh
2024-11-15 12:36 ` [PATCH 5.10.y 4/4] mm: resolve faulty mmap_region() error path behaviour Lorenzo Stoakes
2024-11-19 14:24   ` Patch "mm: resolve faulty mmap_region() error path behaviour" has been added to the 5.10-stable tree gregkh
2024-11-25 15:28 ` [PATCH 5.10.y 0/4] fix error handling in mmap_region() and refactor (hotfixes) Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1731670097.git.lorenzo.stoakes@oracle.com \
    --to=lorenzo.stoakes@oracle.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreas@gaisler.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.