FAILED: patch "[PATCH] mm: refactor map_deny_write_exec()" failed to apply to 6.6-stable tree

Refactor the map_deny_write_exec() to not unnecessarily require a VMA parameter but rather to accept VMA flags parameters, which allows us to use this function early in mmap_region() in a subsequent commit.

While we're here, we refactor the function to be more readable and add some additional documentation.

Reported-by Jann Horn <[email protected]>

Fixes deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")

Cc stable <[email protected]>

Reviewed-by Liam R. Howlett <[email protected]>

Reviewed-by Vlastimil Babka <[email protected]>

Reviewed-by Jann Horn <[email protected]>

Signed-off-by Lorenzo Stoakes <[email protected]>

---
 include/linux/mman.h | 21 ++++++++++++++++++---
 mm/mmap.c            |  2 +-
 mm/mprotect.c        |  2 +-
 3 files changed, 20 insertions(+), 5 deletions(-)

Quoted 14 lines · Lorenzo Stoakes

Refactor the map_deny_write_exec() to not unnecessarily require a VMA parameter but rather to accept VMA flags parameters, which allows us to use this function early in mmap_region() in a subsequent commit.

While we're here, we refactor the function to be more readable and add some additional documentation.

Reported-by Jann Horn <[email protected]>

Fixes deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")

Cc stable <[email protected]>

Reviewed-by Liam R. Howlett <[email protected]>

Reviewed-by Vlastimil Babka <[email protected]>

Reviewed-by Jann Horn <[email protected]>

Signed-off-by Lorenzo Stoakes <[email protected]>

Quoted 5 lines

---
 include/linux/mman.h | 21 ++++++++++++++++++---
 mm/mmap.c            |  2 +-
 mm/mprotect.c        |  2 +-
 3 files changed, 20 insertions(+), 5 deletions(-)

There's no clue here as to what the upstream git id is :(

Also, you sent lots of patches for each branch, but not as a series, so we have no idea what order these go in :(

Can you resend all of these, with the upstream git id in it, and as a patch series, so we know to apply them correctly?

thanks,

greg k-h

Quoted 21 lines · Greg KH

Quoted 19 lines · Lorenzo Stoakes

Refactor the map_deny_write_exec() to not unnecessarily require a VMA parameter but rather to accept VMA flags parameters, which allows us to use this function early in mmap_region() in a subsequent commit.

While we're here, we refactor the function to be more readable and add some additional documentation.

Reported-by Jann Horn <[email protected]>

Fixes deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")

Cc stable <[email protected]>

Reviewed-by Liam R. Howlett <[email protected]>

Reviewed-by Vlastimil Babka <[email protected]>

Reviewed-by Jann Horn <[email protected]>

Signed-off-by Lorenzo Stoakes <[email protected]>

---
 include/linux/mman.h | 21 ++++++++++++++++++---
 mm/mmap.c            |  2 +-
 mm/mprotect.c        |  2 +-
 3 files changed, 20 insertions(+), 5 deletions(-)

Quoted 1 line

There's no clue here as to what the upstream git id is :(

It's in-reply-to a mail that literally contains the upstream git id, following the instructions you explicitly gave.

Quoted 2 lines

Also, you sent lots of patches for each branch, but not as a series, so we have no idea what order these go in :(

I did wonder how you'd sort out ordering, but again, I was following your explicit instructions.

Quoted 3 lines

Can you resend all of these, with the upstream git id in it, and as a patch series, so we know to apply them correctly?

I'll do this, but... I do have to say, Greg, each of these patches are in reply to a mail stating something like, for instance this one:

The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

(I note the above hand waves mention of including original git commit, but it's unwise to then immediately list explicit commands none of which mention this...)

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD
git cherry-pick -x 0fb4a7ad270b3b209e510eb9dc5b07bf02b7edaf

Quoted 22 lines · Lorenzo Stoakes

Quoted 21 lines · Greg KH

Quoted 19 lines · Lorenzo Stoakes

Refactor the map_deny_write_exec() to not unnecessarily require a VMA parameter but rather to accept VMA flags parameters, which allows us to use this function early in mmap_region() in a subsequent commit.

While we're here, we refactor the function to be more readable and add some additional documentation.

Reported-by Jann Horn <[email protected]>

Fixes deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")

Cc stable <[email protected]>

Reviewed-by Liam R. Howlett <[email protected]>

Reviewed-by Vlastimil Babka <[email protected]>

Reviewed-by Jann Horn <[email protected]>

Signed-off-by Lorenzo Stoakes <[email protected]>

---
 include/linux/mman.h | 21 ++++++++++++++++++---
 mm/mmap.c            |  2 +-
 mm/mprotect.c        |  2 +-
 3 files changed, 20 insertions(+), 5 deletions(-)

Quoted 4 lines

Quoted 1 line

There's no clue here as to what the upstream git id is :(

It's in-reply-to a mail that literally contains the upstream git id, following the instructions you explicitly gave.

The instructions explicitly give you commands that say to use 'git cherry-pick -x' which adds the commit id :)

Quoted 23 lines

Quoted 3 lines

Also, you sent lots of patches for each branch, but not as a series, so we have no idea what order these go in :(

I did wonder how you'd sort out ordering, but again, I was following your explicit instructions.

Quoted 3 lines

Can you resend all of these, with the upstream git id in it, and as a patch series, so we know to apply them correctly?

I'll do this, but... I do have to say, Greg, each of these patches are in reply to a mail stating something like, for instance this one:

The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

(I note the above hand waves mention of including original git commit, but it's unwise to then immediately list explicit commands none of which mention this...)

Quoted 5 lines

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD
git cherry-pick -x 0fb4a7ad270b3b209e510eb9dc5b07bf02b7edaf

See, -x, I think you forgot that :)

Anyway, this normally works just fine, as whole series of commits that fail are odd and rare. I can guess at ordering, like I do when I take them from Linus's tree (going by original commit dates), but for when you resend a bunch of them, it's much tricker as the original "FAILED" message doesn't show that order.

thanks,

greg k-h

Quoted 23 lines · Greg KH

Quoted 22 lines · Lorenzo Stoakes

Quoted 21 lines · Greg KH

Quoted 19 lines · Lorenzo Stoakes

Refactor the map_deny_write_exec() to not unnecessarily require a VMA parameter but rather to accept VMA flags parameters, which allows us to use this function early in mmap_region() in a subsequent commit.

While we're here, we refactor the function to be more readable and add some additional documentation.

Reported-by Jann Horn <[email protected]>

Fixes deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")

Cc stable <[email protected]>

Reviewed-by Liam R. Howlett <[email protected]>

Reviewed-by Vlastimil Babka <[email protected]>

Reviewed-by Jann Horn <[email protected]>

Signed-off-by Lorenzo Stoakes <[email protected]>

---
 include/linux/mman.h | 21 ++++++++++++++++++---
 mm/mmap.c            |  2 +-
 mm/mprotect.c        |  2 +-
 3 files changed, 20 insertions(+), 5 deletions(-)

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

There's no clue here as to what the upstream git id is :(

It's in-reply-to a mail that literally contains the upstream git id, following the instructions you explicitly gave.

The instructions explicitly give you commands that say to use 'git cherry-pick -x' which adds the commit id :)

Right yes, missed that, these had to be hand fixed up which is part of it.

Quoted 29 lines

Quoted 23 lines

Quoted 3 lines

Also, you sent lots of patches for each branch, but not as a series, so we have no idea what order these go in :(

I did wonder how you'd sort out ordering, but again, I was following your explicit instructions.

Quoted 3 lines

Can you resend all of these, with the upstream git id in it, and as a patch series, so we know to apply them correctly?

I'll do this, but... I do have to say, Greg, each of these patches are in reply to a mail stating something like, for instance this one:

The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

(I note the above hand waves mention of including original git commit, but it's unwise to then immediately list explicit commands none of which mention this...)

Quoted 5 lines

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD
git cherry-pick -x 0fb4a7ad270b3b209e510eb9dc5b07bf02b7edaf

Quoted 7 lines

See, -x, I think you forgot that :)

Anyway, this normally works just fine, as whole series of commits that fail are odd and rare. I can guess at ordering, like I do when I take them from Linus's tree (going by original commit dates), but for when you resend a bunch of them, it's much tricker as the original "FAILED" message doesn't show that order.

My point stands about rewording this, because I mean - I did what you asked (modulo mistakenly not getting the cherry-picked-by thing) - and it seems you are still unable to apply these.