Hi Greg,
How are you?
What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Specifically those 5 commits:
67203f3f2a63d429272f0c80451e5fcc469fdb46 selftests/mm: add mseal test for no-discard madvise
4d1b3416659be70a2251b494e85e25978de06519 mm: move can_modify_vma to mm/vma.h
4a2dd02b09160ee43f96c759fafa7b56dfc33816 mm/mprotect: replace can_modify_mm with can_modify_vma
23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 mseal: replace can_modify_mm_madv with a vma variant
f28bdd1b17ec187eaa34845814afaaff99832762 selftests/mm: add more mseal traversal tests
There will be merge conflicts, I can backport them to 5.10 and test to help the backporting process.
Those 5 fixes are needed for two reasons: maintain the consistency of mseal's semantics across releases, and for ease of backporting future fixes.
PS: There are also three other commits for munmap and remap (see below), they have dependency on Michael Ellerman's arch_unmap() patch [1] and maybe uprobe change [2]. If Michael and Oleg are OK with backporting their patches, then great ! Otherwise, since those commits below don't change mseal's semantics, I think it is OK to just backport above 5 patches.
df2a7df9a9aa32c3df227de346693e6e802c8591 mm/munmap: replace can_modify_mm with can_modify_vma 38075679b5f157eeacd46c900e9cfc684bdbc167 mm/mremap: replace can_modify_mm with can_modify_vma 5b3db2b812a1f86dfab587324d198a5d10c7a5cf mm: remove can_modify_mm()
[1] https://lore.kernel.org/all/20240812082605.743814-1-mpe@ellerman.id.au/ [2] https://lore.kernel.org/all/20240911131320.GA3448@redhat.com/
Thanks! -Jeff
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote:
Hi Greg,
How are you?
What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
Specifically those 5 commits:
67203f3f2a63d429272f0c80451e5fcc469fdb46 selftests/mm: add mseal test for no-discard madvise
4d1b3416659be70a2251b494e85e25978de06519 mm: move can_modify_vma to mm/vma.h
4a2dd02b09160ee43f96c759fafa7b56dfc33816 mm/mprotect: replace can_modify_mm with can_modify_vma
23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 mseal: replace can_modify_mm_madv with a vma variant
f28bdd1b17ec187eaa34845814afaaff99832762 selftests/mm: add more mseal traversal tests
There will be merge conflicts, I can backport them to 5.10 and test to help the backporting process.
5.10 or 6.10?
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
Those 5 fixes are needed for two reasons: maintain the consistency of mseal's semantics across releases, and for ease of backporting future fixes.
Backporting more to 6.10? Again, it's end-of-life, who would be backporting anything else?
confused,
greg k-h
On Sun, Oct 13, 2024 at 10:54 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote:
Hi Greg,
How are you?
What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
Specifically those 5 commits:
67203f3f2a63d429272f0c80451e5fcc469fdb46 selftests/mm: add mseal test for no-discard madvise
4d1b3416659be70a2251b494e85e25978de06519 mm: move can_modify_vma to mm/vma.h
4a2dd02b09160ee43f96c759fafa7b56dfc33816 mm/mprotect: replace can_modify_mm with can_modify_vma
23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 mseal: replace can_modify_mm_madv with a vma variant
f28bdd1b17ec187eaa34845814afaaff99832762 selftests/mm: add more mseal traversal tests
There will be merge conflicts, I can backport them to 5.10 and test to help the backporting process.
5.10 or 6.10?
6.10.
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
OK, I didn't know that. Less work is nice :-)
Thanks! -Jeff
Those 5 fixes are needed for two reasons: maintain the consistency of mseal's semantics across releases, and for ease of backporting future fixes.
Backporting more to 6.10? Again, it's end-of-life, who would be backporting anything else?
confused,
greg k-h
On Mon, Oct 14, 2024 at 08:27:29AM -0700, Jeff Xu wrote:
On Sun, Oct 13, 2024 at 10:54 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote:
Hi Greg,
How are you?
What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
Specifically those 5 commits:
67203f3f2a63d429272f0c80451e5fcc469fdb46 selftests/mm: add mseal test for no-discard madvise
4d1b3416659be70a2251b494e85e25978de06519 mm: move can_modify_vma to mm/vma.h
4a2dd02b09160ee43f96c759fafa7b56dfc33816 mm/mprotect: replace can_modify_mm with can_modify_vma
23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 mseal: replace can_modify_mm_madv with a vma variant
f28bdd1b17ec187eaa34845814afaaff99832762 selftests/mm: add more mseal traversal tests
There will be merge conflicts, I can backport them to 5.10 and test to help the backporting process.
5.10 or 6.10?
6.10.
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
OK, I didn't know that. Less work is nice :-)
So, now that you don't care about 6.10.y, what about 6.11.y? Are any of these actually bugfixes that people need?
thanks,
greg k-h
On Mon, Oct 14, 2024 at 9:12 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 08:27:29AM -0700, Jeff Xu wrote:
On Sun, Oct 13, 2024 at 10:54 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote:
Hi Greg,
How are you?
What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
Specifically those 5 commits:
67203f3f2a63d429272f0c80451e5fcc469fdb46 selftests/mm: add mseal test for no-discard madvise
4d1b3416659be70a2251b494e85e25978de06519 mm: move can_modify_vma to mm/vma.h
4a2dd02b09160ee43f96c759fafa7b56dfc33816 mm/mprotect: replace can_modify_mm with can_modify_vma
23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 mseal: replace can_modify_mm_madv with a vma variant
f28bdd1b17ec187eaa34845814afaaff99832762 selftests/mm: add more mseal traversal tests
There will be merge conflicts, I can backport them to 5.10 and test to help the backporting process.
5.10 or 6.10?
6.10.
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
OK, I didn't know that. Less work is nice :-)
So, now that you don't care about 6.10.y, what about 6.11.y? Are any of these actually bugfixes that people need?
Oh, yes. It would be great to backport those 5 mentioned to 6.11.y. I don't know what will be the lifetime of 6.11.y, but keeping mseal's semantics consistent across releases is important.
Thanks -Jeff
thanks,
greg k-h
On Mon, Oct 14, 2024 at 09:19:55AM -0700, Jeff Xu wrote:
On Mon, Oct 14, 2024 at 9:12 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 08:27:29AM -0700, Jeff Xu wrote:
On Sun, Oct 13, 2024 at 10:54 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote:
Hi Greg,
How are you?
What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
Specifically those 5 commits:
67203f3f2a63d429272f0c80451e5fcc469fdb46 selftests/mm: add mseal test for no-discard madvise
4d1b3416659be70a2251b494e85e25978de06519 mm: move can_modify_vma to mm/vma.h
4a2dd02b09160ee43f96c759fafa7b56dfc33816 mm/mprotect: replace can_modify_mm with can_modify_vma
23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 mseal: replace can_modify_mm_madv with a vma variant
f28bdd1b17ec187eaa34845814afaaff99832762 selftests/mm: add more mseal traversal tests
There will be merge conflicts, I can backport them to 5.10 and test to help the backporting process.
5.10 or 6.10?
6.10.
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
OK, I didn't know that. Less work is nice :-)
So, now that you don't care about 6.10.y, what about 6.11.y? Are any of these actually bugfixes that people need?
Oh, yes. It would be great to backport those 5 mentioned to 6.11.y.
Why, are they bugfixes?
I don't know what will be the lifetime of 6.11.y, but keeping mseal's semantics consistent across releases is important.
Stable kernels last until the next release happens, like has been happening for 15+ years now, nothing new here :)
If you wish to have patches backported to stable kernels, please read https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
thanks,
greg k-h
On Mon, Oct 14, 2024 at 9:23 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 09:19:55AM -0700, Jeff Xu wrote:
On Mon, Oct 14, 2024 at 9:12 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 08:27:29AM -0700, Jeff Xu wrote:
On Sun, Oct 13, 2024 at 10:54 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote:
Hi Greg,
How are you?
What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
Specifically those 5 commits:
67203f3f2a63d429272f0c80451e5fcc469fdb46 selftests/mm: add mseal test for no-discard madvise
4d1b3416659be70a2251b494e85e25978de06519 mm: move can_modify_vma to mm/vma.h
4a2dd02b09160ee43f96c759fafa7b56dfc33816 mm/mprotect: replace can_modify_mm with can_modify_vma
23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 mseal: replace can_modify_mm_madv with a vma variant
f28bdd1b17ec187eaa34845814afaaff99832762 selftests/mm: add more mseal traversal tests
There will be merge conflicts, I can backport them to 5.10 and test to help the backporting process.
5.10 or 6.10?
6.10.
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
OK, I didn't know that. Less work is nice :-)
So, now that you don't care about 6.10.y, what about 6.11.y? Are any of these actually bugfixes that people need?
Oh, yes. It would be great to backport those 5 mentioned to 6.11.y.
Why, are they bugfixes?
Yes. For performance, there are 5% impact with mprotect/madvise.
I don't know what will be the lifetime of 6.11.y, but keeping mseal's semantics consistent across releases is important.
Stable kernels last until the next release happens, like has been happening for 15+ years now, nothing new here :)
Does it mean that with 6.12, 6.11.y will be EOL soon ? say in the next few months? (Sorry that I didn't know much about linux release cycle. )
If you wish to have patches backported to stable kernels, please read https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
thanks,
greg k-h
On Mon, Oct 14, 2024 at 6:26 PM Jeff Xu jeffxu@chromium.org wrote:
On Mon, Oct 14, 2024 at 9:23 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 09:19:55AM -0700, Jeff Xu wrote:
On Mon, Oct 14, 2024 at 9:12 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 08:27:29AM -0700, Jeff Xu wrote:
On Sun, Oct 13, 2024 at 10:54 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote: > Hi Greg, > > How are you? > > What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
> Specifically those 5 commits: > > 67203f3f2a63d429272f0c80451e5fcc469fdb46 > selftests/mm: add mseal test for no-discard madvise > > 4d1b3416659be70a2251b494e85e25978de06519 > mm: move can_modify_vma to mm/vma.h > > 4a2dd02b09160ee43f96c759fafa7b56dfc33816 > mm/mprotect: replace can_modify_mm with can_modify_vma > > 23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 > mseal: replace can_modify_mm_madv with a vma variant > > f28bdd1b17ec187eaa34845814afaaff99832762 > selftests/mm: add more mseal traversal tests > > There will be merge conflicts, I can backport them to 5.10 and test > to help the backporting process.
5.10 or 6.10?
6.10.
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
OK, I didn't know that. Less work is nice :-)
So, now that you don't care about 6.10.y, what about 6.11.y? Are any of these actually bugfixes that people need?
Oh, yes. It would be great to backport those 5 mentioned to 6.11.y.
Why, are they bugfixes?
Yes. For performance, there are 5% impact with mprotect/madvise.
They're not bugfixes, they fix a performance regression. As far as I'm aware, they do not fit the criteria for -stable inclusion.
But ofc Greg might know better :)
On Mon, Oct 14, 2024 at 10:25:54AM -0700, Jeff Xu wrote:
On Mon, Oct 14, 2024 at 9:23 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 09:19:55AM -0700, Jeff Xu wrote:
On Mon, Oct 14, 2024 at 9:12 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Oct 14, 2024 at 08:27:29AM -0700, Jeff Xu wrote:
On Sun, Oct 13, 2024 at 10:54 PM Greg KH gregkh@linuxfoundation.org wrote:
On Sun, Oct 13, 2024 at 10:17:48PM -0700, Jeff Xu wrote: > Hi Greg, > > How are you? > > What is the process to backport Pedro's recent mseal fixes to 6.10 ?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how all of this works :)
> Specifically those 5 commits: > > 67203f3f2a63d429272f0c80451e5fcc469fdb46 > selftests/mm: add mseal test for no-discard madvise > > 4d1b3416659be70a2251b494e85e25978de06519 > mm: move can_modify_vma to mm/vma.h > > 4a2dd02b09160ee43f96c759fafa7b56dfc33816 > mm/mprotect: replace can_modify_mm with can_modify_vma > > 23c57d1fa2b9530e38f7964b4e457fed5a7a0ae8 > mseal: replace can_modify_mm_madv with a vma variant > > f28bdd1b17ec187eaa34845814afaaff99832762 > selftests/mm: add more mseal traversal tests > > There will be merge conflicts, I can backport them to 5.10 and test > to help the backporting process.
5.10 or 6.10?
6.10.
And why 6.10? If you look at the front page of kernel.org you will see that 6.10 is now end-of-life, so why does that kernel matter to you anymore?
OK, I didn't know that. Less work is nice :-)
So, now that you don't care about 6.10.y, what about 6.11.y? Are any of these actually bugfixes that people need?
Oh, yes. It would be great to backport those 5 mentioned to 6.11.y.
Why, are they bugfixes?
Yes. For performance, there are 5% impact with mprotect/madvise.
That's not a bugfix, but we do sometimes take performance improvements if it's really needed and the maintainer is willing to do the backport for us.
I don't know what will be the lifetime of 6.11.y, but keeping mseal's semantics consistent across releases is important.
Stable kernels last until the next release happens, like has been happening for 15+ years now, nothing new here :)
Does it mean that with 6.12, 6.11.y will be EOL soon ?
Yes.
say in the next few months?
Yes.
(Sorry that I didn't know much about linux release cycle. )
It's well documented, please see the Documentation/process/2.Process.rst file for details. If you have questions after that, please let us know.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Jeff Xu -
Pedro Falcato