Noticed there is a slight change for mprotect between 6.1 and 6.4 RC1
For example:
Consider the case below:
1 mmap(0x5000000, PAGE_SIZE, ...)
2 mprotect(0x5000000, PAGE_SIZE*4, ...)
in 6.1 and before, 2 will fail, and in 6.4 RC1, it will pass.
I know that munmap will accept out-of-bound cases like this (because
memory is freed anyway).
Is this change intentional ?
Thanks!
Best regards,
-Jeff
+ Peter, Lian, Lorenzo
Is this related to this hotfix ?
mm/mprotect: fix do_mprotect_pkey() return on error
Thanks!
-Jeff
On Mon, May 15, 2023 at 11:00 AM Jeff Xu <[email protected]> wrote:
>
> Noticed there is a slight change for mprotect between 6.1 and 6.4 RC1
>
> For example:
> Consider the case below:
> 1 mmap(0x5000000, PAGE_SIZE, ...)
> 2 mprotect(0x5000000, PAGE_SIZE*4, ...)
>
> in 6.1 and before, 2 will fail, and in 6.4 RC1, it will pass.
>
> I know that munmap will accept out-of-bound cases like this (because
> memory is freed anyway).
>
> Is this change intentional ?
>
> Thanks!
> Best regards,
> -Jeff
On Mon, May 15, 2023 at 06:41:35PM -0700, Jeff Xu wrote:
> + Peter, Lian, Lorenzo
>
> Is this related to this hotfix ?
> mm/mprotect: fix do_mprotect_pkey() return on error
Doesn't look like to me, that seems to only avoid replacing an error with
another error, rather than stop returning error for any case.
AFAIU this shouldn't be intentional, but Liam could correct. Maybe a
bisection would show at least when it got changed?
>
>
> Thanks!
>
> -Jeff
>
>
>
>
>
>
> On Mon, May 15, 2023 at 11:00 AM Jeff Xu <[email protected]> wrote:
> >
> > Noticed there is a slight change for mprotect between 6.1 and 6.4 RC1
> >
> > For example:
> > Consider the case below:
> > 1 mmap(0x5000000, PAGE_SIZE, ...)
> > 2 mprotect(0x5000000, PAGE_SIZE*4, ...)
> >
> > in 6.1 and before, 2 will fail, and in 6.4 RC1, it will pass.
> >
> > I know that munmap will accept out-of-bound cases like this (because
> > memory is freed anyway).
> >
> > Is this change intentional ?
> >
> > Thanks!
> > Best regards,
> > -Jeff
>
--
Peter Xu
* Peter Xu <[email protected]> [230516 12:35]:
> On Mon, May 15, 2023 at 06:41:35PM -0700, Jeff Xu wrote:
> > + Peter, Lian, Lorenzo
> >
> > Is this related to this hotfix ?
> > mm/mprotect: fix do_mprotect_pkey() return on error
>
> Doesn't look like to me, that seems to only avoid replacing an error with
> another error, rather than stop returning error for any case.
>
> AFAIU this shouldn't be intentional, but Liam could correct. Maybe a
> bisection would show at least when it got changed?
I did not intentionally modify the return of mprotect for this case. As
Peter said, that change shouldn't cause the change in behaviour you are
seeing.
A bisection would help narrow it down, as it could be changes to mm/mmap
vma_merge() and friends.
Thanks,
Liam
>
> >
> >
> > Thanks!
> >
> > -Jeff
> >
> >
> >
> >
> >
> >
> > On Mon, May 15, 2023 at 11:00 AM Jeff Xu <[email protected]> wrote:
> > >
> > > Noticed there is a slight change for mprotect between 6.1 and 6.4 RC1
> > >
> > > For example:
> > > Consider the case below:
> > > 1 mmap(0x5000000, PAGE_SIZE, ...)
> > > 2 mprotect(0x5000000, PAGE_SIZE*4, ...)
> > >
> > > in 6.1 and before, 2 will fail, and in 6.4 RC1, it will pass.
> > >
> > > I know that munmap will accept out-of-bound cases like this (because
> > > memory is freed anyway).
> > >
> > > Is this change intentional ?
> > >
> > > Thanks!
> > > Best regards,
> > > -Jeff
> >
>
> --
> Peter Xu
>
>