I looked at the attached patch. I don't like it, because there
are possibly a bunch of apps out there that will do a shmget(),
and on success, quickly turn around and do a shmctl() to check
that the size of the shm segment is equal to what it has created.
This will fail, since the shmctl(SHM_STAT) returns INT_MAX at
the most. (Yes, I know, the app should have assumed success when
the shmget() did not return -1, but some apps have to do this
for portability reasons, and some are outright paranoid).
Thinking a little more about the possible 64bit breakages, only
sys_shmctl() is at risk. Older programs will pass in a "int" size
into shmget(), but that should be smoothly promoted to a "size_t".
Due to 64 bit padding of the shmid_ds structure fields, the size
of the shmid_ds has _not_ changed. For >2Gb segments,
IPC_STAT/SHM_STAT will report wrong (truncated) sizes, but that
should be acceptable (this is an API breakage).
The size of "struct shminfo" _has_ changed, which represents an
ABI breakage. I think I can fix this in the sparc64 and alpha
code.
Comments?
Kanoj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/