Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1244866

Re: manpage regarding shmat after deleting a segment

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

manpage regarding shmat after deleting a segment Davidlohr Bueso <dave@stgolabs.net> - 2015-10-12 18:00 +0200
  Re: manpage regarding shmat after deleting a segment Davidlohr Bueso <dave@stgolabs.net> - 2015-10-12 18:20 +0200
    Re: manpage regarding shmat after deleting a segment Davidlohr Bueso <dave@stgolabs.net> - 2015-10-12 21:50 +0200

csiph-web