* [PATCH v5 0/3] man/man2/mremap.2: describe multiple mapping move, shrink @ 2025-08-11 14:59 Lorenzo Stoakes 2025-08-11 14:59 ` [PATCH v5 1/3] man/man2/mremap.2: explicitly document the simple move operation Lorenzo Stoakes ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Lorenzo Stoakes @ 2025-08-11 14:59 UTC (permalink / raw) To: Alejandro Colomar Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api We have added new functionality to mremap() in Linux 6.17, permitting the move of multiple VMAs when performing a move alone (that is - providing MREMAP_MAYMOVE | MREMAP_FIXED flags and specifying old_size == new_size). We document this new feature. Additionally, we document previously undocumented behaviour around shrinking of input VMA ranges which permits the input range to span multiple VMAs. v5: * Reword point about 'old_address' needing to be in a mapped range more clearly as per Alejandro. * Update wording accordingly around this, e.g. referencing unmapped areas between mappings to be consistent. * Minor wording fixup stating that the MREMAP_DONTUNMAP flag may _also_ be specified. * Separated out adding a section on 'pure' moves and describing the new behaviour, as per Alejandro. * Update the commit message of 2/3 to reflect the above. * Removed erroneously introduced blank line in 2/3 as per Alejandro. v4: * Update description of newly discovered mremap() behaviour to highlight the fact that, if in-place, [old_address, old_address + new_length) may span multiple VMAs also. * Fix up commit message for 2/2 to correct typo on specified range. * Added code sample to 1/2 as per Alejandro. https://lore.kernel.org/all/cover.1754414738.git.lorenzo.stoakes@oracle.com/ v3: * Use more precise language around mremap() move description as per Jann. * Fix some typos in commit messages. https://lore.kernel.org/all/cover.1753795807.git.lorenzo.stoakes@oracle.com/ v2: * Split out the two man page changes as requested by Alejandro. https://lore.kernel.org/all/cover.1753711160.git.lorenzo.stoakes@oracle.com/ v1: https://lore.kernel.org/all/20250723174634.75054-1-lorenzo.stoakes@oracle.com/ Lorenzo Stoakes (3): man/man2/mremap.2: explicitly document the simple move operation man/man2/mremap.2: describe multiple mapping move man/man2/mremap.2: describe previously undocumented shrink behaviour man/man2/mremap.2 | 109 +++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 98 insertions(+), 11 deletions(-) -- 2.50.1 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v5 1/3] man/man2/mremap.2: explicitly document the simple move operation 2025-08-11 14:59 [PATCH v5 0/3] man/man2/mremap.2: describe multiple mapping move, shrink Lorenzo Stoakes @ 2025-08-11 14:59 ` Lorenzo Stoakes 2025-08-15 10:05 ` Alejandro Colomar 2025-08-11 14:59 ` [PATCH v5 2/3] man/man2/mremap.2: describe multiple mapping move Lorenzo Stoakes 2025-08-11 14:59 ` [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour Lorenzo Stoakes 2 siblings, 1 reply; 10+ messages in thread From: Lorenzo Stoakes @ 2025-08-11 14:59 UTC (permalink / raw) To: Alejandro Colomar Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api In preparation for discussing newly introduced mremap() behaviour to permit the move of multiple mappings at once, add a section to the mremap.2 man page to describe these operations in general. Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> --- man/man2/mremap.2 | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 index 2168ca728..4e3c8e54e 100644 --- a/man/man2/mremap.2 +++ b/man/man2/mremap.2 @@ -25,6 +25,20 @@ moving it at the same time (controlled by the argument and the available virtual address space). .P +Mappings can also simply be moved +(without any resizing) +by specifying equal +.I old_size +and +.I new_size +and using the +.B MREMAP_FIXED +flag +(see below). +The +.B MREMAP_DONTUNMAP +flag may also be specified. +.P .I old_address is the old address of the virtual memory block that you want to expand (or shrink). -- 2.50.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v5 1/3] man/man2/mremap.2: explicitly document the simple move operation 2025-08-11 14:59 ` [PATCH v5 1/3] man/man2/mremap.2: explicitly document the simple move operation Lorenzo Stoakes @ 2025-08-15 10:05 ` Alejandro Colomar 0 siblings, 0 replies; 10+ messages in thread From: Alejandro Colomar @ 2025-08-15 10:05 UTC (permalink / raw) To: Lorenzo Stoakes Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api [-- Attachment #1: Type: text/plain, Size: 1366 bytes --] Hi Lorenzo, On Mon, Aug 11, 2025 at 03:59:37PM +0100, Lorenzo Stoakes wrote: > In preparation for discussing newly introduced mremap() behaviour to permit > the move of multiple mappings at once, add a section to the mremap.2 man > page to describe these operations in general. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Thanks! I've applied this patch. <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=6ba37b9e14f6565d0cccecb634100d7fe11d22fb> Have a lovely day! Alex > --- > man/man2/mremap.2 | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 > index 2168ca728..4e3c8e54e 100644 > --- a/man/man2/mremap.2 > +++ b/man/man2/mremap.2 > @@ -25,6 +25,20 @@ moving it at the same time (controlled by the > argument and > the available virtual address space). > .P > +Mappings can also simply be moved > +(without any resizing) > +by specifying equal > +.I old_size > +and > +.I new_size > +and using the > +.B MREMAP_FIXED > +flag > +(see below). > +The > +.B MREMAP_DONTUNMAP > +flag may also be specified. > +.P > .I old_address > is the old address of the virtual memory block that you > want to expand (or shrink). > -- > 2.50.1 > -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v5 2/3] man/man2/mremap.2: describe multiple mapping move 2025-08-11 14:59 [PATCH v5 0/3] man/man2/mremap.2: describe multiple mapping move, shrink Lorenzo Stoakes 2025-08-11 14:59 ` [PATCH v5 1/3] man/man2/mremap.2: explicitly document the simple move operation Lorenzo Stoakes @ 2025-08-11 14:59 ` Lorenzo Stoakes 2025-08-15 15:19 ` Alejandro Colomar 2025-08-11 14:59 ` [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour Lorenzo Stoakes 2 siblings, 1 reply; 10+ messages in thread From: Lorenzo Stoakes @ 2025-08-11 14:59 UTC (permalink / raw) To: Alejandro Colomar Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api Document the new behaviour introduced in Linux 6.17 whereby it is now possible to move multiple mappings in a single operation, as long as the operation is purely a move, that is old_size is equal to new_size and MREMAP_FIXED is specified. This change also explains the limitations of of this method and the possibility of partial failure. Finally, we pluralise language where it makes sense to so the documentation does not contradict either this new capability nor the pre-existing edge case. Example code is enclosed below demonstrating the behaviour which is now possible: int main(void) { unsigned long page_size = sysconf(_SC_PAGESIZE); void *ptr = mmap(NULL, 10 * page_size, PROT_READ | PROT_WRITE, MAP_ANON | MAP_PRIVATE, -1, 0); void *tgt_ptr = mmap(NULL, 10 * page_size, PROT_NONE, MAP_ANON | MAP_PRIVATE, -1, 0); int i; if (ptr == MAP_FAILED || tgt_ptr == MAP_FAILED) { perror("mmap"); return EXIT_FAILURE; } /* Unmap every other page. */ for (i = 1; i < 10; i += 2) munmap(ptr + i * page_size, page_size); /* Now move all 5 distinct mappings to tgt_ptr. */ ptr = mremap(ptr, 10 * page_size, 10 * page_size, MREMAP_MAYMOVE | MREMAP_FIXED, tgt_ptr); if (ptr == MAP_FAILED) { perror("mremap"); return EXIT_FAILURE; } return EXIT_SUCCESS; } Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> --- man/man2/mremap.2 | 68 +++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 57 insertions(+), 11 deletions(-) diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 index 4e3c8e54e..6d14bf627 100644 --- a/man/man2/mremap.2 +++ b/man/man2/mremap.2 @@ -35,22 +35,36 @@ and using the .B MREMAP_FIXED flag (see below). +Since Linux 6.17, +while +.I old_address +must be mapped, +.I old_size +may span multiple mappings +including unmapped areas between +them when performing a move like this. The .B MREMAP_DONTUNMAP flag may also be specified. .P +If the operation is not +simply moving mappings, +then +.I old_size +must span only a single mapping. +.P .I old_address -is the old address of the virtual memory block that you -want to expand (or shrink). +is the old address of the first virtual memory block that you +want to expand, shrink, and/or move. Note that .I old_address has to be page aligned. .I old_size -is the old size of the -virtual memory block. +is the size of the range containing +virtual memory blocks to be manipulated. .I new_size is the requested size of the -virtual memory block after the resize. +virtual memory blocks after the resize. An optional fifth argument, .IR new_address , may be provided; see the description of @@ -119,13 +133,42 @@ If is specified, then .B MREMAP_MAYMOVE must also be specified. +.IP +Since Linux 6.17, +if +.I old_size +is equal to +.I new_size +and +.B MREMAP_FIXED +is specified, then +.I old_size +may span beyond the mapping in which +.I old_address +resides. +In this case, +gaps between mappings in the original range +are maintained in the new range. +The whole operation is performed atomically +unless an error arises, +in which case the operation may be partially +completed, +that is, +some mappings may be moved and others not. +.IP +Moving multiple mappings is not permitted if +any of those mappings have either +been registered with +.BR userfaultfd (2) , +or map drivers that +specify their own custom address mapping logic. .TP .BR MREMAP_DONTUNMAP " (since Linux 5.7)" .\" commit e346b3813067d4b17383f975f197a9aa28a3b077 This flag, which must be used in conjunction with .BR MREMAP_MAYMOVE , -remaps a mapping to a new address but does not unmap the mapping at -.IR old_address . +remaps mappings to a new address but does not unmap them +from their original address. .IP The .B MREMAP_DONTUNMAP @@ -163,13 +206,13 @@ mapped. See NOTES for some possible applications of .BR MREMAP_DONTUNMAP . .P -If the memory segment specified by +If the memory segments specified by .I old_address and .I old_size -is locked (using +are locked (using .BR mlock (2) -or similar), then this lock is maintained when the segment is +or similar), then this lock is maintained when the segments are resized and/or relocated. As a consequence, the amount of memory locked by the process may change. .SH RETURN VALUE @@ -202,7 +245,10 @@ virtual memory address for this process. You can also get .B EFAULT even if there exist mappings that cover the -whole address space requested, but those mappings are of different types. +whole address space requested, but those mappings are of different types, +and the +.BR mremap () +operation being performed does not support this. .TP .B EINVAL An invalid argument was given. -- 2.50.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v5 2/3] man/man2/mremap.2: describe multiple mapping move 2025-08-11 14:59 ` [PATCH v5 2/3] man/man2/mremap.2: describe multiple mapping move Lorenzo Stoakes @ 2025-08-15 15:19 ` Alejandro Colomar 0 siblings, 0 replies; 10+ messages in thread From: Alejandro Colomar @ 2025-08-15 15:19 UTC (permalink / raw) To: Lorenzo Stoakes Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api [-- Attachment #1: Type: text/plain, Size: 6204 bytes --] Hi Lorenzo, On Mon, Aug 11, 2025 at 03:59:38PM +0100, Lorenzo Stoakes wrote: > Document the new behaviour introduced in Linux 6.17 whereby it is now > possible to move multiple mappings in a single operation, as long as the > operation is purely a move, that is old_size is equal to new_size and > MREMAP_FIXED is specified. > > This change also explains the limitations of of this method and the > possibility of partial failure. > > Finally, we pluralise language where it makes sense to so the documentation > does not contradict either this new capability nor the pre-existing edge > case. > > Example code is enclosed below demonstrating the behaviour which is now > possible: > > int main(void) > { > unsigned long page_size = sysconf(_SC_PAGESIZE); > void *ptr = mmap(NULL, 10 * page_size, PROT_READ | PROT_WRITE, > MAP_ANON | MAP_PRIVATE, -1, 0); > void *tgt_ptr = mmap(NULL, 10 * page_size, PROT_NONE, > MAP_ANON | MAP_PRIVATE, -1, 0); > int i; > > if (ptr == MAP_FAILED || tgt_ptr == MAP_FAILED) { > perror("mmap"); > return EXIT_FAILURE; > } > > /* Unmap every other page. */ > for (i = 1; i < 10; i += 2) > munmap(ptr + i * page_size, page_size); > > /* Now move all 5 distinct mappings to tgt_ptr. */ > ptr = mremap(ptr, 10 * page_size, 10 * page_size, > MREMAP_MAYMOVE | MREMAP_FIXED, tgt_ptr); > if (ptr == MAP_FAILED) { > perror("mremap"); > return EXIT_FAILURE; > } > > return EXIT_SUCCESS; > } I've applied some editorial changes to the program. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Thanks! I've applied the patch, with a small amendment (see below). <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=d99a3495372a69b48309f2a1a4e2067af2bfbe69> Have a lovely day! Alex > --- > man/man2/mremap.2 | 68 +++++++++++++++++++++++++++++++++++++++-------- > 1 file changed, 57 insertions(+), 11 deletions(-) > > diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 > index 4e3c8e54e..6d14bf627 100644 > --- a/man/man2/mremap.2 > +++ b/man/man2/mremap.2 > @@ -35,22 +35,36 @@ and using the > .B MREMAP_FIXED > flag > (see below). > +Since Linux 6.17, > +while > +.I old_address > +must be mapped, > +.I old_size > +may span multiple mappings > +including unmapped areas between > +them when performing a move like this. And I've reworded this last line. Repetitive consistent language helps understanding documentation, so it's better to repeat "a simple move" here again. diff --git i/man/man2/mremap.2 w/man/man2/mremap.2 index 6d14bf627..65b4d5f58 100644 --- i/man/man2/mremap.2 +++ w/man/man2/mremap.2 @@ -42,7 +42,7 @@ .SH DESCRIPTION .I old_size may span multiple mappings including unmapped areas between -them when performing a move like this. +them when performing a simple move. The .B MREMAP_DONTUNMAP flag may also be specified. > The > .B MREMAP_DONTUNMAP > flag may also be specified. > .P > +If the operation is not > +simply moving mappings, > +then > +.I old_size > +must span only a single mapping. > +.P > .I old_address > -is the old address of the virtual memory block that you > -want to expand (or shrink). > +is the old address of the first virtual memory block that you > +want to expand, shrink, and/or move. > Note that > .I old_address > has to be page aligned. > .I old_size > -is the old size of the > -virtual memory block. > +is the size of the range containing > +virtual memory blocks to be manipulated. > .I new_size > is the requested size of the > -virtual memory block after the resize. > +virtual memory blocks after the resize. > An optional fifth argument, > .IR new_address , > may be provided; see the description of > @@ -119,13 +133,42 @@ If > is specified, then > .B MREMAP_MAYMOVE > must also be specified. > +.IP > +Since Linux 6.17, > +if > +.I old_size > +is equal to > +.I new_size > +and > +.B MREMAP_FIXED > +is specified, then > +.I old_size > +may span beyond the mapping in which > +.I old_address > +resides. > +In this case, > +gaps between mappings in the original range > +are maintained in the new range. > +The whole operation is performed atomically > +unless an error arises, > +in which case the operation may be partially > +completed, > +that is, > +some mappings may be moved and others not. > +.IP > +Moving multiple mappings is not permitted if > +any of those mappings have either > +been registered with > +.BR userfaultfd (2) , > +or map drivers that > +specify their own custom address mapping logic. > .TP > .BR MREMAP_DONTUNMAP " (since Linux 5.7)" > .\" commit e346b3813067d4b17383f975f197a9aa28a3b077 > This flag, which must be used in conjunction with > .BR MREMAP_MAYMOVE , > -remaps a mapping to a new address but does not unmap the mapping at > -.IR old_address . > +remaps mappings to a new address but does not unmap them > +from their original address. > .IP > The > .B MREMAP_DONTUNMAP > @@ -163,13 +206,13 @@ mapped. > See NOTES for some possible applications of > .BR MREMAP_DONTUNMAP . > .P > -If the memory segment specified by > +If the memory segments specified by > .I old_address > and > .I old_size > -is locked (using > +are locked (using > .BR mlock (2) > -or similar), then this lock is maintained when the segment is > +or similar), then this lock is maintained when the segments are > resized and/or relocated. > As a consequence, the amount of memory locked by the process may change. > .SH RETURN VALUE > @@ -202,7 +245,10 @@ virtual memory address for this process. > You can also get > .B EFAULT > even if there exist mappings that cover the > -whole address space requested, but those mappings are of different types. > +whole address space requested, but those mappings are of different types, > +and the > +.BR mremap () > +operation being performed does not support this. > .TP > .B EINVAL > An invalid argument was given. > -- > 2.50.1 > -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour 2025-08-11 14:59 [PATCH v5 0/3] man/man2/mremap.2: describe multiple mapping move, shrink Lorenzo Stoakes 2025-08-11 14:59 ` [PATCH v5 1/3] man/man2/mremap.2: explicitly document the simple move operation Lorenzo Stoakes 2025-08-11 14:59 ` [PATCH v5 2/3] man/man2/mremap.2: describe multiple mapping move Lorenzo Stoakes @ 2025-08-11 14:59 ` Lorenzo Stoakes 2025-08-15 21:36 ` Alejandro Colomar 2 siblings, 1 reply; 10+ messages in thread From: Lorenzo Stoakes @ 2025-08-11 14:59 UTC (permalink / raw) To: Alejandro Colomar Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api There is pre-existing logic that appears to be undocumented for an mremap() shrink operation, where it turns out that the usual 'input range must span a single mapping' requirement no longer applies. In fact, it turns out that the input range specified by [old_address, old_address + old_size) may span any number of mappings. If shrinking in-place (that is, neither the MREMAP_FIXED nor MREMAP_DONTUNMAP flags are specified), then the new span may also span any number of VMAs - [old_address, old_address + new_size). If shrinking and moving, the range specified by [old_address, old_address + new_size) must span a single VMA. There must be at least one VMA contained within the [old_address, old_address + old_size) range, and old_address must be within the range of a VMA. Explicitly document this. Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> --- man/man2/mremap.2 | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 index 6d14bf627..53d4eda29 100644 --- a/man/man2/mremap.2 +++ b/man/man2/mremap.2 @@ -47,8 +47,35 @@ The .B MREMAP_DONTUNMAP flag may also be specified. .P -If the operation is not -simply moving mappings, +Equally, if the operation performs a shrink, +that is if +.I old_size +is greater than +.IR new_size , +then +.I old_size +may also span multiple mappings +which do not have to be +adjacent to one another. +If this shrink is performed +in-place, +that is, +neither +.BR MREMAP_FIXED , +nor +.B MREMAP_DONTUNMAP +are specified, +.I new_size +may also span multiple VMAs. +However, if the range is moved, +then +.I new_size +must span only a single mapping. +.P +If the operation is neither a +.B MREMAP_FIXED +move +nor a shrink, then .I old_size must span only a single mapping. -- 2.50.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour 2025-08-11 14:59 ` [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour Lorenzo Stoakes @ 2025-08-15 21:36 ` Alejandro Colomar 2025-08-19 20:37 ` Lorenzo Stoakes 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2025-08-15 21:36 UTC (permalink / raw) To: Lorenzo Stoakes Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api [-- Attachment #1: Type: text/plain, Size: 2714 bytes --] Hi Lorenzo, On Mon, Aug 11, 2025 at 03:59:39PM +0100, Lorenzo Stoakes wrote: > There is pre-existing logic that appears to be undocumented for an mremap() > shrink operation, where it turns out that the usual 'input range must span > a single mapping' requirement no longer applies. > > In fact, it turns out that the input range specified by [old_address, > old_address + old_size) may span any number of mappings. > > If shrinking in-place (that is, neither the MREMAP_FIXED nor > MREMAP_DONTUNMAP flags are specified), then the new span may also span any > number of VMAs - [old_address, old_address + new_size). > > If shrinking and moving, the range specified by [old_address, old_address + > new_size) must span a single VMA. > > There must be at least one VMA contained within the [old_address, > old_address + old_size) range, and old_address must be within the range of > a VMA. > > Explicitly document this. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > --- > man/man2/mremap.2 | 31 +++++++++++++++++++++++++++++-- > 1 file changed, 29 insertions(+), 2 deletions(-) > > diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 > index 6d14bf627..53d4eda29 100644 > --- a/man/man2/mremap.2 > +++ b/man/man2/mremap.2 > @@ -47,8 +47,35 @@ The > .B MREMAP_DONTUNMAP > flag may also be specified. > .P > -If the operation is not > -simply moving mappings, > +Equally, if the operation performs a shrink, > +that is if Missing comma. > +.I old_size > +is greater than > +.IR new_size , > +then > +.I old_size > +may also span multiple mappings > +which do not have to be > +adjacent to one another. I'm wondering if there's a missing comma or not before 'which'. The meaning of the sentence would be different. So, I should ask: Does old_size > new_size mean that old_size may span multiple mappings and you're commenting that multiple mappings need not be adjacent? Or are multiple mappings always allowed and old_size > new_size allows non-adjacent ones? I suspect it's the former, right? Then, it's missing a comma, right? Other than this, the patch looks good. Have a lovely night! Alex > +If this shrink is performed > +in-place, > +that is, > +neither > +.BR MREMAP_FIXED , > +nor > +.B MREMAP_DONTUNMAP > +are specified, > +.I new_size > +may also span multiple VMAs. > +However, if the range is moved, > +then > +.I new_size > +must span only a single mapping. > +.P > +If the operation is neither a > +.B MREMAP_FIXED > +move > +nor a shrink, > then > .I old_size > must span only a single mapping. > -- > 2.50.1 > -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour 2025-08-15 21:36 ` Alejandro Colomar @ 2025-08-19 20:37 ` Lorenzo Stoakes 2025-08-20 10:50 ` Alejandro Colomar 0 siblings, 1 reply; 10+ messages in thread From: Lorenzo Stoakes @ 2025-08-19 20:37 UTC (permalink / raw) To: Alejandro Colomar Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api On Fri, Aug 15, 2025 at 11:36:26PM +0200, Alejandro Colomar wrote: > Hi Lorenzo, > > On Mon, Aug 11, 2025 at 03:59:39PM +0100, Lorenzo Stoakes wrote: > > There is pre-existing logic that appears to be undocumented for an mremap() > > shrink operation, where it turns out that the usual 'input range must span > > a single mapping' requirement no longer applies. > > > > In fact, it turns out that the input range specified by [old_address, > > old_address + old_size) may span any number of mappings. > > > > If shrinking in-place (that is, neither the MREMAP_FIXED nor > > MREMAP_DONTUNMAP flags are specified), then the new span may also span any > > number of VMAs - [old_address, old_address + new_size). > > > > If shrinking and moving, the range specified by [old_address, old_address + > > new_size) must span a single VMA. > > > > There must be at least one VMA contained within the [old_address, > > old_address + old_size) range, and old_address must be within the range of > > a VMA. > > > > Explicitly document this. > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > > --- > > man/man2/mremap.2 | 31 +++++++++++++++++++++++++++++-- > > 1 file changed, 29 insertions(+), 2 deletions(-) > > > > diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 > > index 6d14bf627..53d4eda29 100644 > > --- a/man/man2/mremap.2 > > +++ b/man/man2/mremap.2 > > @@ -47,8 +47,35 @@ The > > .B MREMAP_DONTUNMAP > > flag may also be specified. > > .P > > -If the operation is not > > -simply moving mappings, > > +Equally, if the operation performs a shrink, > > +that is if > > Missing comma. Could you fix that up? Thnks! > > > +.I old_size > > +is greater than > > +.IR new_size , > > +then > > +.I old_size > > +may also span multiple mappings > > +which do not have to be > > +adjacent to one another. > > I'm wondering if there's a missing comma or not before 'which'. > The meaning of the sentence would be different. > > So, I should ask: > > Does old_size > new_size mean that old_size may span multiple mappings > and you're commenting that multiple mappings need not be adjacent? Yes. > > Or are multiple mappings always allowed and old_size > new_size allows > non-adjacent ones? No. > > I suspect it's the former, right? Then, it's missing a comma, right? Yes could you fix that up? > > > Other than this, the patch looks good. Thanks! > > > Have a lovely night! > Alex > > > +If this shrink is performed > > +in-place, > > +that is, > > +neither > > +.BR MREMAP_FIXED , > > +nor > > +.B MREMAP_DONTUNMAP > > +are specified, > > +.I new_size > > +may also span multiple VMAs. > > +However, if the range is moved, > > +then > > +.I new_size > > +must span only a single mapping. > > +.P > > +If the operation is neither a > > +.B MREMAP_FIXED > > +move > > +nor a shrink, > > then > > .I old_size > > must span only a single mapping. > > -- > > 2.50.1 > > > > -- > <https://www.alejandro-colomar.es/> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour 2025-08-19 20:37 ` Lorenzo Stoakes @ 2025-08-20 10:50 ` Alejandro Colomar 2025-08-20 11:24 ` Lorenzo Stoakes 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2025-08-20 10:50 UTC (permalink / raw) To: Lorenzo Stoakes Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api [-- Attachment #1: Type: text/plain, Size: 1714 bytes --] Hi Lorenzo, On Tue, Aug 19, 2025 at 09:37:39PM +0100, Lorenzo Stoakes wrote: > > > diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 > > > index 6d14bf627..53d4eda29 100644 > > > --- a/man/man2/mremap.2 > > > +++ b/man/man2/mremap.2 > > > @@ -47,8 +47,35 @@ The > > > .B MREMAP_DONTUNMAP > > > flag may also be specified. > > > .P > > > -If the operation is not > > > -simply moving mappings, > > > +Equally, if the operation performs a shrink, I've changed s/Equally/Similarly/ > > > +that is if > > > > Missing comma. > > Could you fix that up? Thnks! > > > > > > +.I old_size > > > +is greater than > > > +.IR new_size , > > > +then > > > +.I old_size > > > +may also span multiple mappings > > > +which do not have to be > > > +adjacent to one another. > > > > I'm wondering if there's a missing comma or not before 'which'. > > The meaning of the sentence would be different. > > > > So, I should ask: > > > > Does old_size > new_size mean that old_size may span multiple mappings > > and you're commenting that multiple mappings need not be adjacent? > > Yes. > > > > > Or are multiple mappings always allowed and old_size > new_size allows > > non-adjacent ones? > > No. > > > > > I suspect it's the former, right? Then, it's missing a comma, right? > > Yes could you fix that up? Yup. > > > > > > > Other than this, the patch looks good. > > Thanks! Thanks for the patch! I've applied it with those amendments. <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=21b1c7188ce1d66ef294eb1681361315a35e8070> Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour 2025-08-20 10:50 ` Alejandro Colomar @ 2025-08-20 11:24 ` Lorenzo Stoakes 0 siblings, 0 replies; 10+ messages in thread From: Lorenzo Stoakes @ 2025-08-20 11:24 UTC (permalink / raw) To: Alejandro Colomar Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro, Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka, Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel, linux-api On Wed, Aug 20, 2025 at 12:50:25PM +0200, Alejandro Colomar wrote: > Hi Lorenzo, > > On Tue, Aug 19, 2025 at 09:37:39PM +0100, Lorenzo Stoakes wrote: > > > > diff --git a/man/man2/mremap.2 b/man/man2/mremap.2 > > > > index 6d14bf627..53d4eda29 100644 > > > > --- a/man/man2/mremap.2 > > > > +++ b/man/man2/mremap.2 > > > > @@ -47,8 +47,35 @@ The > > > > .B MREMAP_DONTUNMAP > > > > flag may also be specified. > > > > .P > > > > -If the operation is not > > > > -simply moving mappings, > > > > +Equally, if the operation performs a shrink, > > I've changed s/Equally/Similarly/ > > > > > +that is if > > > > > > Missing comma. > > > > Could you fix that up? Thnks! > > > > > > > > > +.I old_size > > > > +is greater than > > > > +.IR new_size , > > > > +then > > > > +.I old_size > > > > +may also span multiple mappings > > > > +which do not have to be > > > > +adjacent to one another. > > > > > > I'm wondering if there's a missing comma or not before 'which'. > > > The meaning of the sentence would be different. > > > > > > So, I should ask: > > > > > > Does old_size > new_size mean that old_size may span multiple mappings > > > and you're commenting that multiple mappings need not be adjacent? > > > > Yes. > > > > > > > > Or are multiple mappings always allowed and old_size > new_size allows > > > non-adjacent ones? > > > > No. > > > > > > > > I suspect it's the former, right? Then, it's missing a comma, right? > > > > Yes could you fix that up? > > Yup. > > > > > > > > > > > > Other than this, the patch looks good. > > > > Thanks! > > Thanks for the patch! I've applied it with those amendments. > <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=21b1c7188ce1d66ef294eb1681361315a35e8070> All sounds good, thanks for doing that and also for applies for other patches in series :) Cheers, Lorenzo > > > Have a lovely day! > Alex > > -- > <https://www.alejandro-colomar.es/> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-08-20 11:24 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-08-11 14:59 [PATCH v5 0/3] man/man2/mremap.2: describe multiple mapping move, shrink Lorenzo Stoakes 2025-08-11 14:59 ` [PATCH v5 1/3] man/man2/mremap.2: explicitly document the simple move operation Lorenzo Stoakes 2025-08-15 10:05 ` Alejandro Colomar 2025-08-11 14:59 ` [PATCH v5 2/3] man/man2/mremap.2: describe multiple mapping move Lorenzo Stoakes 2025-08-15 15:19 ` Alejandro Colomar 2025-08-11 14:59 ` [PATCH v5 3/3] man/man2/mremap.2: describe previously undocumented shrink behaviour Lorenzo Stoakes 2025-08-15 21:36 ` Alejandro Colomar 2025-08-19 20:37 ` Lorenzo Stoakes 2025-08-20 10:50 ` Alejandro Colomar 2025-08-20 11:24 ` Lorenzo Stoakes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).