From: Davidlohr Bueso <dave@stgolabs.net>
To: Michael Kerrisk <mtk@man7.org>
Cc: linux-kernel@vger.kernel.org, Greg Thelen <gthelen@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: manpage regarding shmat after deleting a segment
Date: Mon, 12 Oct 2015 12:43:29 -0700 [thread overview]
Message-ID: <20151012194329.GE3170@linux-uzut.site> (raw)
In-Reply-To: <20151012161002.GB3170@linux-uzut.site>
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@stgolabs.net>
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@suse.de>
---
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
next prev parent reply other threads:[~2015-10-12 19:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 15:50 manpage regarding shmat after deleting a segment Davidlohr Bueso
2015-10-12 16:10 ` Davidlohr Bueso
2015-10-12 19:43 ` Davidlohr Bueso [this message]
2015-10-19 13:49 ` Davidlohr Bueso
2015-12-16 17:57 ` Michael Kerrisk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151012194329.GE3170@linux-uzut.site \
--to=dave@stgolabs.net \
--cc=akpm@linux-foundation.org \
--cc=gthelen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk@man7.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox