]> git.ipfire.org Git - thirdparty/man-pages.git/commit
man/man2/mremap.2: Describe previously undocumented shrink behaviour master
authorLorenzo Stoakes <lorenzo.stoakes@oracle.com>
Mon, 11 Aug 2025 14:59:39 +0000 (15:59 +0100)
committerAlejandro Colomar <alx@kernel.org>
Wed, 20 Aug 2025 16:14:16 +0000 (18:14 +0200)
commitc7e6c703f8c41d16630dfeb289de6bb45228d8d8
treef2ac4291d5b7a8f1c4fe9c02aafda87d9611b278
parent3d066f79ac04b6b7fd79bca7d3ec0c298ee9ad5e
man/man2/mremap.2: Describe previously undocumented shrink behaviour

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>
Message-ID: <ab2264d8c29d103d400c028f0417cada002ffc11.1754924278.git.lorenzo.stoakes@oracle.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
man/man2/mremap.2