Re: [PATCH 6.6.y] mm: refactor map_deny_write_exec()

[Greg KH <gregkh@linuxfoundation.org>]

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@google.com>
> > > Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
> > > Cc: stable <stable@kernel.org>
> > > Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> > > Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
> > > Reviewed-by: Jann Horn <jannh@google.com>
> > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > ---
> > >  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@vger.kernel.org>.
> 
> (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