mremap.2: BUGS: describe older behavior for old_size==0 on private mappings

Explain the older behavior, and why it changed. This is a
follow-up to Mike Kravetz's patch documenting the behavior
for old_size==0 with shared mappings.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man2/mremap.2

@@ -201,7 +201,7 @@ was specified without also specifying
 .BR MREMAP_MAYMOVE ;
 .IP *
 \fIold_size\fP was zero and \fIold_address\fP does not refer to a
-shareable mapping;
+shareable mapping (but see BUGS);
 .IP *
 \fIold_size\fP was zero and the
 .BR MREMAP_MAYMOVE
@@ -238,6 +238,27 @@ call will make a best effort to populate the new area but will not fail
 with
 .B ENOMEM
 if the area cannot be populated.
+.SH BUGS
+Before Linux 4.14,
+if
+.I old_size
+was zero and the mapping referred to by
+.I old_address
+was a private mapping
+.RB ( mmap "(2) " MAP_PRIVATE ),
+.BR mremap ()
+created a new private mapping unrelated to the original mapping.
+This behavior was unintended
+and probably unexpected in user-space applications
+(since the intention of
+.BR mremap ()
+is to create a new mapping based on the original mapping).
+Since Linux 4.14,
+.\" commit dba58d3b8c5045ad89c1c95d33d01451e3964db7
+.BR mremap ()
+fails with the error
+.B EINVAL
+in this scenario.
 .SH SEE ALSO
 .BR brk (2),
 .BR getpagesize (2),