On Fri, Nov 15, 2024 at 09:27:22AM +0100, Greg KH wrote:
> 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 :)
Right yes, missed that, these had to be hand fixed up which is part of it.
>
> > > 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.
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.
I would add something about 'if there are a series to be applied, see <link to
stable process option 3> or whatever it will be.
Because presumably, even if I had got the upstream commit ID bit right, you'd
still have had no clue on ordering right? And we'd be in the same position.
>
> thanks,
>
> greg k-h
