Messages in this thread | | | Date | Fri, 11 Nov 2005 23:38:24 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...) |
| |
"Michael Kerrisk" <michael.kerrisk@gmx.net> wrote: > > > Bear in mind that the sort of apps we're talking about here are > > dubiously-written monsters with long and costly upgrade cycles and we tend > > to not get any reports until many many months after we made a kernel > > change. It's very costly all round and we need to be cautious. > > Andrew, > > I am late to this discussion, but for what it's worth, a > portable application really must use checks of the like > (perm.mode & 0777 = 0666), because many implementations > define additional read-only flags for perm.mode: > > Tru64 5.1 > #define SHM_LOCKED 01000 /* segment locked in memory */ > #define SHM_REMOVED 02000 /* already removed */ > > Linux > #define SHM_DEST 01000 /* segment will be destroyed on last detach */ > #define SHM_LOCKED 02000 /* segment will not be swapped */ > > HP-UX 11 > # define SHM_CLEAR 01000 /* clear segment on next attach */ > # define SHM_DEST 02000 /* destroy segment when # attached = 0 */ > # define SHM_NOSWAP 010000 /* region for shared memory is memory locked */ > /* (or should be when the region is allocated) */ > > AIX 5.1 > #define SHM_DEST 02000 /* destroy segment when # attached = 0 */ > > So the chances are probably good that portable applications > wouldn't break with Arun's proposal.
The chances of breakage I agree are very low. But non-zero. I'd still like us to find a way which is completely safe.
> Of course applications > that were written just for Linux, and don't take care, might > also be at risk, but I think the risk is probably low. > A check of the form: > > if (mode == 0666|SHM_LOCKED) > > instead of: > > if (mode & SHM_LOCKED) > > is very obtuse.
Yes, but
if ((mode & ~(SHM_LOCKED|SHM_REMOVED)) == 0666)
is pretty perverse, but more likely. Stranger things have been seen ;)
> This might not change your point of view (there is a theoretical risk > after all), but I thought it worth mentioning.
Thanks. - 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/
| |