From: Isaac Manjarres <isaacmanjarres@google.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
aliceryhl@google.com, surenb@google.com, stable@vger.kernel.org,
kernel-team@android.com
Subject: Re: [PATCH 5.10.y 0/4] Backport series: "permit write-sealed memfd read-only shared mappings"
Date: Wed, 6 Aug 2025 09:54:32 -0700 [thread overview]
Message-ID: <aJOIyKQtevW0Ov_A@google.com> (raw)
In-Reply-To: <2025073103-unheated-outbid-11a2@gregkh>
On Thu, Jul 31, 2025 at 06:58:41AM +0200, Greg KH wrote:
> On Thu, Jul 31, 2025 at 05:40:29AM +0100, Lorenzo Stoakes wrote:
> > On Wed, Jul 30, 2025 at 03:26:01PM -0700, Isaac Manjarres wrote:
> > > On Wed, Jul 30, 2025 at 08:34:02PM +0100, Lorenzo Stoakes wrote:
> > > > > >
> > > > > > Having said that, I'm not against you doing this, just wondering about
> > > > > > that.
> > > > > >
> > > > > > Also - what kind of testing have you do on these series?
> > > > > I did the following tests:
> > > > >
> > > > > 1. I have a unit test that tries to map write-sealed memfds as
> > > > > read-only and shared. I verified that this works for each kernel version
> > > > > that this series is being applied to.
> > > > >
> > > > > 2. Android devices do use memfds as well, so I did try these patches out
> > > > > on a device running each kernel version, and tried boot testing, using
> > > > > several apps/games. I was looking for functional failures in these
> > > > > scenarios but didn't encounter any.
> > > > >
> > > > > Do you have any other recommendations of what I should test?
> > > >
> > > > No, that sounds good to me! Thank you for taking the time to implement and
> > > > carefully check this :)
> > > >
> > > > In this case I have no objections to these backports!
> > > >
> > > > Cheers, Lorenzo
> > >
> > > Thanks Lorenzo! Just to confirm, is there anything required from my
> > > end for these patches or they'll get reviewed and merged over time?
> >
> > No, these should all be good to go, Greg + Sasha handle the stable kernels
> > and should percolate through their process (I see Sasha's scripts have been
> > firing off already :)
>
> Yeah, give us a week or so to catch up with all of the recently
> submitted changes, the merge window, AND finally, a vacation for the
> stable maintainers....
>
Understood. Thank you all for this!
--Isaac
prev parent reply other threads:[~2025-08-06 16:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 1:53 [PATCH 5.10.y 0/4] Backport series: "permit write-sealed memfd read-only shared mappings" Isaac J. Manjarres
2025-07-30 1:53 ` [PATCH 5.10.y 1/4] mm: drop the assumption that VM_SHARED always implies writable Isaac J. Manjarres
2025-07-30 16:29 ` Sasha Levin
2025-08-24 7:57 ` Patch "mm: drop the assumption that VM_SHARED always implies writable" has been added to the 5.10-stable tree gregkh
2025-07-30 1:54 ` [PATCH 5.10.y 2/4] mm: update memfd seal write check to include F_SEAL_WRITE Isaac J. Manjarres
2025-07-30 16:29 ` Sasha Levin
2025-08-24 7:57 ` Patch "mm: update memfd seal write check to include F_SEAL_WRITE" has been added to the 5.10-stable tree gregkh
2025-07-30 1:54 ` [PATCH 5.10.y 3/4] mm: reinstate ability to map write-sealed memfd mappings read-only Isaac J. Manjarres
2025-07-30 16:29 ` Sasha Levin
2025-08-24 7:57 ` Patch "mm: reinstate ability to map write-sealed memfd mappings read-only" has been added to the 5.10-stable tree gregkh
2025-07-30 1:54 ` [PATCH 5.10.y 4/4] selftests/memfd: add test for mapping write-sealed memfd read-only Isaac J. Manjarres
2025-07-30 16:29 ` Sasha Levin
2025-07-30 14:21 ` [PATCH 5.10.y 0/4] Backport series: "permit write-sealed memfd read-only shared mappings" Lorenzo Stoakes
2025-07-30 17:23 ` Isaac Manjarres
2025-07-30 19:34 ` Lorenzo Stoakes
2025-07-30 22:26 ` Isaac Manjarres
2025-07-31 4:40 ` Lorenzo Stoakes
2025-07-31 4:58 ` Greg KH
2025-07-31 5:02 ` Lorenzo Stoakes
2025-08-06 16:54 ` Isaac Manjarres [this message]
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=aJOIyKQtevW0Ov_A@google.com \
--to=isaacmanjarres@google.com \
--cc=aliceryhl@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.