From: Sasha Levin <sashal@kernel.org>
To: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Cc: stable@vger.kernel.org, Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Subject: Re: [PATCH 6.1.y v2 3/4] mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling
Date: Tue, 19 Nov 2024 10:18:22 -0500 [thread overview]
Message-ID: <ZzysPgiWqzxa7fx5@sashalap> (raw)
In-Reply-To: <360e3143-28ed-46e4-8064-12aa03aaccf1@oracle.com>
On Tue, Nov 19, 2024 at 12:40:03PM +0530, Harshit Mogalapalli wrote:
>Hi Sasha,
>
>On 19/11/24 10:06, Sasha Levin wrote:
>>[ Sasha's backport helper bot ]
>>
>>Hi,
>>
>>The upstream commit SHA1 provided is correct: 5baf8b037debf4ec60108ccfeccb8636d1dbad81
>>
>
>Nice bot!
>
>Just few thoughts:
>
>>Commit in newer trees:
>>
>>|-----------------|----------------------------------------------|
>>| 6.11.y | Present (different SHA1: 9f5efc1137ba) |
>>| 6.6.y | Not found |
>>| 6.1.y | Not found |
>>|-----------------|----------------------------------------------|
>>
>
>
>Given that this patch is for 6.1.y, it(6.1.y) need not be considered
>as newer tree I think ?
I've kept it in just because sometimes we might do the backport
ourselves and then someone else will send another backport. I agree that
this could be clearer :)
>Also the backport for 6.6.y is present on lore.stable [1], so the
>backport not being present in stable-6.6.y might be not very useful,
>as it is possible for people to send the backport to multiple trees in
>the same stable update cycle(before 6.6.y has the backport included)
>-- instead could we run this while queuing up(maybe warn if it is
>neither present in stable-queue-6.6 nor in stable-6.6.y ?) ?
Yeah... Automation is a work in progress. Ideally one day this will turn
into the backend of a dashboard that'll keep track of outstanding
backports.
--
Thanks,
Sasha
next prev parent reply other threads:[~2024-11-19 15:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 16:17 [PATCH 6.1.y v2 0/4] fix error handling in mmap_region() and refactor (hotfixes) Lorenzo Stoakes
2024-11-18 16:17 ` [PATCH 6.1.y v2 1/4] mm: avoid unsafe VMA hook invocation when error arises on mmap hook Lorenzo Stoakes
2024-11-19 4:36 ` Sasha Levin
2024-11-18 16:17 ` [PATCH 6.1.y v2 2/4] mm: unconditionally close VMAs on error Lorenzo Stoakes
2024-11-19 4:36 ` Sasha Levin
2024-11-18 16:17 ` [PATCH 6.1.y v2 3/4] mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling Lorenzo Stoakes
2024-11-19 4:36 ` Sasha Levin
2024-11-19 7:10 ` Harshit Mogalapalli
2024-11-19 15:18 ` Sasha Levin [this message]
2024-11-18 16:17 ` [PATCH 6.1.y v2 4/4] mm: resolve faulty mmap_region() error path behaviour Lorenzo Stoakes
2024-11-19 4:36 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZzysPgiWqzxa7fx5@sashalap \
--to=sashal@kernel.org \
--cc=harshit.m.mogalapalli@oracle.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox