Messages in this thread | | | Date | Mon, 6 Jan 2003 18:01:45 +0100 | From | Alex Riesen <> | Subject | Re: shmat problem |
| |
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/
| |