lkml.org 
[lkml]   [2005]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
> Arun Sharma <arun.sharma@google.com> wrote:
> >
> > Andrew Morton wrote:
> >
> > >>>How important is this feature?
> > >>
> > >>Without this feature, an application has no way to figure out if a given
> > >>segment is hugetlb or not. Applications need to know this to be able to
> > >>handle alignment issues properly.
> > >>
> > >>Also, if the flag is exported via ipcs, the system administrator would
> > >>have a better idea about how the hugetlb pages she configured on the
> > >>system are getting used.
> > >>
> > >
> > >
> > > I'd suggest that any API which allows us to query the hugeness of a piece
> > > of memory should also work for mmap(hugetld_fd...). IOW: this capability
> > > shouldn't be restricted to sysv shm areas.
> >
> > The capability I was talking about was the ability to figure out where
> > the configured hugetlb pages are going (vs is this a hugetlb page?).
>
> Well, please figure out a way which has less risk of breaking userspace.
>
> 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. 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.

This might not change your point of view (there is a theoretical risk
after all), but I thought it worth mentioning.

Cheers,

Michael
-
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/

\
 
 \ /
  Last update: 2005-11-12 08:22    [W:0.695 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site