Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)

Arun Sharma <[email protected]> wrote:
>
> Andrew Morton wrote:
> 
> >>The man page on my system says:
> >>
> >>               unsigned short mode;  /* Permissions + SHM_DEST and
> >>                                         SHM_LOCKED flags */
> >>
> >>I looked for a precendent before sending the patch and thought that 
> >>SHM_LOCKED was a good one.
> >>
> > 
> > 
> > hm, OK.   But an app could still do
> > 
> > 	if (mode == 0666|SHM_LOCKED)
> > 
> 
> I'd argue that the app should really be doing (perm.mode & 0777 = 0666)

I find your faith in your fellow programmers to be trluy inspirational ;)

> > 
> > 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.

I can't think of any syscall which can be sanely overloaded for this.

The most general way of exposing this info would be to export it in
/proc/pid/maps in some back-compatible manner.

And once I've lost the "oh oh we'd need to write 100 lines of userspace
code for that" bunfight I'd say add a new syscall sys_query_pagesize(void
*addr) which returns the size of the page which backs `addr'.

But then again, if it was possible to write 100 lines of userspace code, we
wouldn't need this capability at all.  I bet if the userspace guys tried a
bit harder they'd work out a way of teaching their applications to remember
what they did.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• Follow-Ups:
  • Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
    • From: Arun Sharma <[email protected]>

• References:
  • [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
    • From: Arun Sharma <[email protected]>
  • Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
    • From: Andrew Morton <[email protected]>
  • Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
    • From: Arun Sharma <[email protected]>
  • Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
    • From: Andrew Morton <[email protected]>
  • Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
    • From: Arun Sharma <[email protected]>

• Prev by Date: Bad page state at prep_new_page in 2.6.14/x86-64
• Next by Date: Re: latest mtd changes broke collie
• Previous by thread: Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
• Next by thread: Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...)
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]