[6.6.y,0/5] fix error handling in mmap_region() and refactor (hotfixes)

Message

Lorenzo Stoakes Nov. 15, 2024, 12:41 p.m. UTC

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

Some notes on differences from upstream:

* 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.

* 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.

Lorenzo Stoakes (5):
  mm: avoid unsafe VMA hook invocation when error arises on mmap hook
  mm: unconditionally close VMAs on error
  mm: refactor map_deny_write_exec()
  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 ++-
 arch/parisc/include/asm/mman.h |   5 +-
 include/linux/mman.h           |  28 ++++++--
 mm/internal.h                  |  45 ++++++++++++
 mm/mmap.c                      | 128 ++++++++++++++++++---------------
 mm/mprotect.c                  |   2 +-
 mm/nommu.c                     |   9 ++-
 mm/shmem.c                     |   3 -
 8 files changed, 153 insertions(+), 77 deletions(-)

--
2.47.0

Comments

Vlastimil Babka Nov. 15, 2024, 5:17 p.m. UTC | #1

On 11/15/24 13:41, Lorenzo Stoakes wrote:
> Critical fixes for mmap_region(), backported to 6.6.y.
> 
> Some notes on differences from upstream:
> 
> * 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.
> 
> * 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.
> 
> Lorenzo Stoakes (5):
>   mm: avoid unsafe VMA hook invocation when error arises on mmap hook
>   mm: unconditionally close VMAs on error
>   mm: refactor map_deny_write_exec()
>   mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling
>   mm: resolve faulty mmap_region() error path behaviour

I don't know if review tags are actually applied to stable backports on top
of the original reviews, but I've checked so FTR:

Reviewed-by: Vlastimil Babka <[e-mail]>

>  arch/arm64/include/asm/mman.h  |  10 ++-
>  arch/parisc/include/asm/mman.h |   5 +-
>  include/linux/mman.h           |  28 ++++++--
>  mm/internal.h                  |  45 ++++++++++++
>  mm/mmap.c                      | 128 ++++++++++++++++++---------------
>  mm/mprotect.c                  |   2 +-
>  mm/nommu.c                     |   9 ++-
>  mm/shmem.c                     |   3 -
>  8 files changed, 153 insertions(+), 77 deletions(-)
> 
> --
> 2.47.0

Liam R. Howlett Nov. 15, 2024, 8:09 p.m. UTC | #2

* Lorenzo Stoakes <[e-mail]> [241115 07:42]:
> Critical fixes for mmap_region(), backported to 6.6.y.
> 
> Some notes on differences from upstream:
> 
> * 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.
> 
> * 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.
> 
> Lorenzo Stoakes (5):
>   mm: avoid unsafe VMA hook invocation when error arises on mmap hook
>   mm: unconditionally close VMAs on error
>   mm: refactor map_deny_write_exec()
>   mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling
>   mm: resolve faulty mmap_region() error path behaviour

These backports look good.

Reviewed-by: Liam R. Howlett <[e-mail]>

> 
>  arch/arm64/include/asm/mman.h  |  10 ++-
>  arch/parisc/include/asm/mman.h |   5 +-
>  include/linux/mman.h           |  28 ++++++--
>  mm/internal.h                  |  45 ++++++++++++
>  mm/mmap.c                      | 128 ++++++++++++++++++---------------
>  mm/mprotect.c                  |   2 +-
>  mm/nommu.c                     |   9 ++-
>  mm/shmem.c                     |   3 -
>  8 files changed, 153 insertions(+), 77 deletions(-)
> 
> --
> 2.47.0

Greg KH Nov. 19, 2024, 1:16 p.m. UTC | #3

On Fri, Nov 15, 2024 at 12:41:53PM +0000, Lorenzo Stoakes wrote:
> Critical fixes for mmap_region(), backported to 6.6.y.

Did I miss the 6.11.y and 6.1.y versions of this series somewhere?

thanks,

greg k-h

Lorenzo Stoakes Nov. 19, 2024, 1:24 p.m. UTC | #4

On Tue, Nov 19, 2024 at 02:16:52PM +0100, Greg KH wrote:
> On Fri, Nov 15, 2024 at 12:41:53PM +0000, Lorenzo Stoakes wrote:
> > Critical fixes for mmap_region(), backported to 6.6.y.
>
> Did I miss the 6.11.y and 6.1.y versions of this series somewhere?
>
> thanks,
>
> greg k-h

5.10.y - https://lore.kernel.org/linux-mm/[e-mail]/
5.15.y - https://lore.kernel.org/linux-mm/[e-mail]/
 6.1.y - https://lore.kernel.org/linux-mm/[e-mail]/
 6.6.y - https://lore.kernel.org/linux-mm/[e-mail]/

I didn't backport to 6.11.y as we are about to move to 6.12, but I can if
you need that.

Greg KH Nov. 19, 2024, 2:14 p.m. UTC | #5

On Tue, Nov 19, 2024 at 01:24:33PM +0000, Lorenzo Stoakes wrote:
> On Tue, Nov 19, 2024 at 02:16:52PM +0100, Greg KH wrote:
> > On Fri, Nov 15, 2024 at 12:41:53PM +0000, Lorenzo Stoakes wrote:
> > > Critical fixes for mmap_region(), backported to 6.6.y.
> >
> > Did I miss the 6.11.y and 6.1.y versions of this series somewhere?
> >
> > thanks,
> >
> > greg k-h
> 
> 5.10.y - https://lore.kernel.org/linux-mm/[e-mail]/
> 5.15.y - https://lore.kernel.org/linux-mm/[e-mail]/
>  6.1.y - https://lore.kernel.org/linux-mm/[e-mail]/
>  6.6.y - https://lore.kernel.org/linux-mm/[e-mail]/
> 
> I didn't backport to 6.11.y as we are about to move to 6.12, but I can if
> you need that.

True, 6.11.y is only going to be around for another few weeks, just
wanted to make sure I hadn't missed this.  I'll go queue all of these up
now, thanks for the backports!

greg k-h