On Fri, Nov 15, 2024 at 05:02:29AM +0100, Greg KH wrote:
> On Thu, Nov 14, 2024 at 06:36:15PM +0000, Lorenzo Stoakes wrote:
> > 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 <jannh@xxxxxxxxxx>
> > Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
> > Cc: stable <stable@xxxxxxxxxx>
> > Reviewed-by: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx>
> > Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx>
> > Reviewed-by: Jann Horn <jannh@xxxxxxxxxx>
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
> > ---
> > 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 :(
It's in-reply-to a mail that literally contains the upstream git id,
following the instructions you explicitly gave.
>
> 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.
>
> 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 <stable@xxxxxxxxxxxxxxx>.
(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
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@xxxxxxxxxxxxxxx>' --in-reply-to '2024111110-dubbed-hydration-c1be@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
Might I politely suggest changing this or no longer telling people a series
of commands to follow that result in 'please redo everything over again'?
Something like prefixing this with 'IF YOU NEED ONLY FIXUP A SINGLE COMMIT
YOU CAN DO THE FOLLOWING:'?
Because right now it reads as 'you _must_ follow these instructions' to
resolve the issue.
>
> thanks,
>
> greg k-h
A side note but... I didn't actually want to do these backports this way
(as per our conversation prior to submission of original series), but my
upstream patches got changed to cc: stable @ vger.kernel.org which
triggered the bots, and is why I tried the follow these instructions.
I would otherwise have sent these as series in the first instance. But
c'est la vie. Murphy's law dictated this series of events happen instead :(
Thanks, Lorenzo
