On Fri, Nov 15, 2024 at 08:38:00AM +0000, Lorenzo Stoakes wrote:
> 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.
If I had the git ids, I'd take the time to figure it out. As-is, these
were going to have to be redone anyway, hence me asking that they be
sent in a series. That's all, just trying to make my life easier.
thanks,
greg k-h
