On Fri, Aug 30, 2024 at 06:15:46PM GMT, Andrew Morton wrote:
> On Thu, 29 Aug 2024 13:09:41 +0100 Lorenzo Stoakes
> wrote:
>
> > Relevant section from MAINTAINERS:
> >
> > MEMORY MAPPING
>
> I always thought it meant "memory management" ;)
Ha ha no, I
On Fri, Aug 30, 2024 at 07:43:12PM GMT, Lorenzo Stoakes wrote:
> On Fri, Aug 30, 2024 at 06:02:36PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add sealing test to cover mmap for
> > Expand/shrink across sealed vmas (MAP_FIXED)
> > Reuse the same add
nux-kselftest/20240829214352.963001-1-jef...@chromium.org/
> - remove the mmap fix (Liam R. Howlett will fix it separately)
> - Add cover letter (Lorenzo Stoakes)
I think I asked for more than this :)
> - split the testcase for ease of review (Mark Brown)
>
> V1:
> -
> https:
On Fri, Aug 30, 2024 at 06:02:36PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add sealing test to cover mmap for
> Expand/shrink across sealed vmas (MAP_FIXED)
> Reuse the same address in !MAP_FIXED case.
This commit message is woefully small. I told you on v1 to improve the
commit messa
On Fri, Aug 30, 2024 at 08:03:25AM GMT, Dave Hansen wrote:
> On 8/29/24 01:42, Lorenzo Stoakes wrote:
> >> These applications work on x86 because x86 does an implicit 47-bit
> >> restriction of mmap() address that contain a hint address that is less
> >> than 48 b
On Thu, Aug 29, 2024 at 03:16:53PM GMT, Charlie Jenkins wrote:
> On Thu, Aug 29, 2024 at 10:54:25AM +0100, Lorenzo Stoakes wrote:
> > On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> > > On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> > &g
On Thu, Aug 29, 2024 at 05:16:50PM GMT, Mark Brown wrote:
> On Wed, Aug 28, 2024 at 10:55:22PM +, jef...@chromium.org wrote:
>
> > Add more testcases and increase test coverage, e.g. add
> > get_vma_size to check VMA size and prot bits.
>
> I think this needs to be split into multiple patches,
On Thu, Aug 29, 2024 at 08:30:11AM GMT, Jeff Xu wrote:
> Hi Lorenzo
>
> On Thu, Aug 29, 2024 at 8:14 AM Lorenzo Stoakes
> wrote:
> >
> > On Thu, Aug 29, 2024 at 07:45:56AM GMT, Jeff Xu wrote:
> > > HI Andrew
> > >
> > > On Wed, Aug 28, 20
On Thu, Aug 29, 2024 at 07:45:56AM GMT, Jeff Xu wrote:
> HI Andrew
>
> On Wed, Aug 28, 2024 at 3:55 PM wrote:
> >
> > From: Jeff Xu
> >
> > Add more testcases and increase test coverage, e.g. add
> > get_vma_size to check VMA size and prot bits.
This commit message is ridiculously short for such
elevant section from MAINTAINERS:
MEMORY MAPPING
M: Andrew Morton
R: Liam R. Howlett
R: Vlastimil Babka
R: Lorenzo Stoakes
L: linux...@kvack.org
S: Maintained
W: http://www.linux-mm.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
F: mm
On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
>
On Thu, Aug 29, 2024 at 12:15:59AM GMT, Charlie Jenkins wrote:
[snip]
> diff --git a/mm/mmap.c b/mm/mmap.c
> index d0dfc85b209b..34ba0db23678 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1796,6 +1796,9 @@ generic_get_unmapped_area(struct file *filp, unsigned
> long addr,
> struct vm_un
iller
> To: Andreas Larsson
> To: Thomas Gleixner
> To: Ingo Molnar
> To: Borislav Petkov
> To: Dave Hansen
> To: x...@kernel.org
> To: H. Peter Anvin
> To: Andy Lutomirski
> To: Peter Zijlstra
> To: Muchun Song
> To: Andrew Morton
> To: Liam R. Howl
gt; To: Paul Walmsley
> To: Palmer Dabbelt
> To: Albert Ou
> To: Catalin Marinas
> To: Will Deacon
> To: Michael Ellerman
> To: Nicholas Piggin
> To: Christophe Leroy
> To: Naveen N Rao
> To: Muchun Song
> To: Andrew Morton
> To: Liam R. Howlett
> To: Vlasti
On Tue, Aug 27, 2024 at 10:49:22PM GMT, Charlie Jenkins wrote:
> Add a selftest for MAP_BELOW_HINT that maps until it runs out of space
> below the hint address.
>
> Signed-off-by: Charlie Jenkins
> ---
> tools/testing/selftests/mm/Makefile | 1 +
> tools/testing/selftests/mm/map_below_h
On Wed, Aug 21, 2024 at 09:33:06AM GMT, Jeff Xu wrote:
> On Wed, Aug 21, 2024 at 9:24 AM Pedro Falcato wrote:
> >
> > On Wed, Aug 21, 2024 at 5:16 PM Jeff Xu wrote:
> > >
> > > On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato
> > > wrote:
> > > >
> > > > We were doing an extra mmap tree traversal
On Wed, Aug 21, 2024 at 09:15:52AM GMT, Jeff Xu wrote:
> On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato wrote:
> >
> > We were doing an extra mmap tree traversal just to check if the entire
> > range is modifiable. This can be done when we iterate through the VMAs
> > instead.
> >
> > Signed-off-by
gular VMA is followed by a sealed VMA.
>
> Signed-off-by: Pedro Falcato
Other than the comment, LGTM.
Thanks for this series!
Reviewed-by: Lorenzo Stoakes
> ---
> tools/testing/selftests/mm/mseal_test.c | 111
> +++-
> 1 file changed, 110 insertions(+),
On Sat, Aug 17, 2024 at 01:18:33AM GMT, Pedro Falcato wrote:
> With no more users in the tree, we can finally remove can_modify_mm().
>
> Signed-off-by: Pedro Falcato
Reviewed-by: Lorenzo Stoakes
> ---
> mm/internal.h | 14 --
> mm/mseal.c| 21 --
a)
> return true;
> }
>
> +bool can_modify_vma_madv(struct vm_area_struct *vma, int behavior);
> +
> #else
>
> static inline bool can_modify_vma(struct vm_area_struct *vma)
> @@ -387,6 +389,11 @@ static inline bool can_modify_vma(struct vm_area_struct
> *vma)
> return true;
> }
>
> +static inline bool can_modify_vma_madv(struct vm_area_struct *vma, int
> behavior)
> +{
> + return true;
> +}
> +
> #endif
>
> #endif /* __MM_VMA_H */
>
> --
> 2.46.0
>
I remain baffled that the original implementation tried to do these things
at an mm- granularity.
Reviewed-by: Lorenzo Stoakes
ink/expand together.
> - */
> - if (unlikely(!can_modify_mm(mm, addr, addr + old_len))) {
> - ret = -EPERM;
> - goto out;
> - }
> -
> /*
>* Always allow a shrinking remap: that just unmaps
>* the unnecessary pages..
>
> --
> 2.46.0
>
Reviewed-by: Lorenzo Stoakes
ng newflags);
Which explicitly says DO NOT MODIFY THE VMA.
So we're good.
> prev = vma_prev(&vmi);
> if (start > vma->vm_start)
> prev = vma;
>
> --
> 2.46.0
>
Reviewed-by: Lorenzo Stoakes
*/
> - if (unlikely(!can_modify_mm(mm, start, end)))
> - return -EPERM;
> -
This means we will arch_unmap() first, before realising we can't unmap,
however there are a number of other error conditions that would cause a
similar outcome in do_vmi_align_munmap() so I don't think that's a problem.
> /* Find the first overlapping VMA */
> vma = vma_find(vmi, end);
> if (!vma) {
>
> --
> 2.46.0
>
LGTM, Reviewed-by: Lorenzo Stoakes
ic inline bool can_modify_vma(struct vm_area_struct *vma)
> +{
> + return true;
> +}
> +
> +#endif
> +
> #endif /* __MM_VMA_H */
>
> --
> 2.46.0
>
Thanks for moving to vma.h rather than internal.h! Definitely seems to me
to be the correct place for it.
Reviewed-by: Lorenzo Stoakes
24 matches
Mail list logo
