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@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 :)
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@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.
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