Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 6 Jan 2003 11:53:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 6 Jan 2003 11:53:14 -0500 Received: from smtp.mailix.net ([216.148.213.132]:17846 "EHLO smtp.mailix.net") by vger.kernel.org with ESMTP id ; Mon, 6 Jan 2003 11:53:14 -0500 Date: Mon, 6 Jan 2003 18:01:45 +0100 From: Alex Riesen To: Doug McNaught Cc: Dirk Bull , linux-kernel Subject: Re: shmat problem Message-ID: <20030106170144.GB16249@steel> Reply-To: Alex Riesen References: <20030106162251.GA15900@steel> <20030106164332.GA16131@steel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1138 Lines: 32 Doug McNaught, Mon, Jan 06, 2003 17:50:24 +0100: > > Linux manpages-1.54 (Dec 30 2002): > > > > The (Linux-specific) SHM_REMAP flag may be asserted in shmflg to indi- > > cate that the mapping of the segment should replace any existing map- > > ping in the range starting at shmaddr and continuing for the size of > > the segment. (Normally an EINVAL error would result if a mapping > > already exists in this address range.) In this case, shmaddr must not > > be NULL. > > Wouldn't the OP's code still (potentially) have problems? What if you > had: > > char my_shared_area[2048]; > int my_unshared_var; > > void *foo = shmat(id, &my_shared_area, SHM_REMAP); > > Would my_unshared_var end up shared, since memory mappings have page > granularity? > yes, i suppose so. Maybe that was the reason making SHM_REMAP non-default behaviour for shmat. -alex - 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/