Re: manpage regarding shmat after deleting a segment

[Davidlohr Bueso]

On Mon, 12 Oct 2015, Bueso wrote:
> At this point, the manpage should probably be updated to indicate that
> this behavior is only as of v3.10.

Something like this, perhaps?

8<----------------------------------------------------------------------
From: Davidlohr Bueso <dave@xxxxxxxxxxxx>
Date: Mon, 12 Oct 2015 12:40:53 -0700
Subject: [PATCH] shm: Document Linux policies for reusing removed segments

With a399b29dfba (ipc,shm: fix shm_file deletion races) we
changed the policy on how we deal with segments which are
marked for deletion. This is an unintended consequence of
the previous lockless ipc object lookup and security checks.

Update the corresponding man-page to reflect this new behavior

Signed-off-by: Davidlohr Bueso <dbueso@xxxxxxx>
---
 man2/shmctl.2 |  6 ++++--
 man2/shmop.2  | 10 ++++++----
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/man2/shmctl.2 b/man2/shmctl.2
index 21ede49..6212aa4 100644
--- a/man2/shmctl.2
+++ b/man2/shmctl.2
@@ -405,13 +405,15 @@ In the future, these may modified or moved to a
 .I /proc
 filesystem interface.
 
-Linux permits a process to attach
+Until version 3.9, Linux permits a process to attach
 .RB ( shmat (2))
 a shared memory segment that has already been marked for deletion
 using
 .IR shmctl(IPC_RMID) .
 This feature is not available on other UNIX implementations;
-portable applications should avoid relying on it.
+portable applications should avoid relying on it. As of version
+3.10, -EIDRM will be returned in these scenarios, and therefore
+attaching to a deleted segment is considered forbidden.
 
 Various fields in a \fIstruct shmid_ds\fP were typed as
 .I short
diff --git a/man2/shmop.2 b/man2/shmop.2
index e818796..1ea6f99 100644
--- a/man2/shmop.2
+++ b/man2/shmop.2
@@ -266,10 +266,12 @@ Therefore, any pointers maintained within the shared memory must be
 made relative (typically to the starting address of the segment),
 rather than absolute.
 .PP
-On Linux, it is possible to attach a shared memory segment even if it
-is already marked to be deleted.
-However, POSIX.1 does not specify this behavior and
-many other implementations do not support it.
+Up until version 3.9 On Linux, it is possible to attach a shared
+memory segment even if it is already marked to be deleted. However,
+POSIX.1 does not specify this behavior and many other implementations
+do not support it. As of version 3.10, -EIDRM will be returned in
+these scenarios, and therefore attaching to a deleted segment is
+considered forbidden.
 .LP
 The following system parameter affects
 .BR shmat ():
--
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/