From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752548AbbJLQKN (ORCPT ); Mon, 12 Oct 2015 12:10:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:34547 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751896AbbJLQKM (ORCPT ); Mon, 12 Oct 2015 12:10:12 -0400 Date: Mon, 12 Oct 2015 09:10:02 -0700 From: Davidlohr Bueso To: Michael Kerrisk Cc: linux-kernel@vger.kernel.org, Greg Thelen , Andrew Morton Subject: Re: manpage regarding shmat after deleting a segment Message-ID: <20151012161002.GB3170@linux-uzut.site> References: <20151012155021.GA3170@linux-uzut.site> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20151012155021.GA3170@linux-uzut.site> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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