public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
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

  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