mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 09:10:02 -0700	[thread overview]
Message-ID: <20151012161002.GB3170@linux-uzut.site> (raw)
In-Reply-To: <20151012155021.GA3170@linux-uzut.site>

On Mon, 12 Oct 2015, Bueso wrote:

>Hi Michael,
>
>We currently have the following statement in the shmctl(2) manpage:
>
>     Linux permits a process to attach (shmat(2)) a shared memory segment
>     that has already been marked for deletion using shmctl(IPC_RMID).
>     This feature is  not  available  on other UNIX implementations;
>     portable applications should avoid relying on it.
>
>Which seems to be incorrect, or at least confusing/stale. shmat() will
>check against previously deleted segments (although the resources are in
>fact deleted only when the last process referencing it exits). Therefore
>Linux appears to do what all other Unices do.

Ok, so perhaps not so stale. Its just that we managed to break userspace
again via a399b29dfba (ipc,shm: fix shm_file deletion races), which is
something we need to proporly do the the lockless ipc object lookups/security
checks. Sure, without that 'if (shp->shm_file == NULL)' check, there is
no problem with attaching to a deleted seg.

At this point, the manpage should probably be updated to indicate that
this behavior is only as of v3.10.

>
>Specifically, this is in the form of validating against ipc_valid_object(),
>which checks against the deleted flag, returning EIDRM when the segment has
>already been marked for deletion via shmctl(IPC_RMID).
>
>Now, previously shmat() used to check against shm_file validity (changed in
>0f3d2b0135f4 ipc: introduce ipc_valid_object() helper to sort out IPC_RMID
>races), which is basically the same wrt to the text in question. So this
>behavior is in fact quite old. Furthermore, in general there seems to be a
>lot of ambiguity among IPC_RMID, EIDRM, EINVAL, and now this text.
>
>Therefore I propose dropping this. Am I missing something? Thoughts?
>
>Thanks,
>Davidlohr
>
>diff --git a/man2/shmctl.2 b/man2/shmctl.2
>index 21ede49..72a2854 100644
>--- a/man2/shmctl.2
>+++ b/man2/shmctl.2
>@@ -405,14 +405,6 @@ In the future, these may modified or moved to a
> .I /proc
> filesystem interface.
>-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.
>-
> Various fields in a \fIstruct shmid_ds\fP were typed as
> .I short
> under Linux 2.2

  reply	other threads:[~2015-10-12 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 15:50 Davidlohr Bueso
2015-10-12 16:10 ` Davidlohr Bueso [this message]
2015-10-12 19:43   ` Davidlohr Bueso
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=20151012161002.GB3170@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

all inboxes | Powered by JetHome®