On Fri, Nov 15, 2024 at 07:52:26AM +0000, Lorenzo Stoakes wrote:
> 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.
The instructions explicitly give you commands that say to use 'git
cherry-pick -x' which adds the commit id :)
> > 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
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
