Davidlohr Bueso <dave@xxxxxxxxxxxx> writes: > Hi, > > The following patches adds the discussed[1] new command for shm > as well as for sems and msq as they are subject to the same discrepancies > for ipc object permission checks between the syscall and via procfs. > These new commands are justified in that (1) we are stuck with this > semantics as changing syscall and procfs can break userland; and (2) some > users can benefit from performance (for large amounts of shm segments, > for example) from not having to parse the procfs interface. > > Once (if) merged, I will submit the necesary manpage updates. But I'm > thinking something like: I am just going to kibitz for a moment. Could we name this _STAT_ANY or _STAT_NOPERM instead of _STAT_ALL. I keep thinking a name with _ALL in it should affect all ipc opbjects of a given type, not simply work any ipc object regardless of permissions. Eric > diff --git a/man2/shmctl.2 b/man2/shmctl.2 > index 7bb503999941..bb00bbe21a57 100644 > --- a/man2/shmctl.2 > +++ b/man2/shmctl.2 > @@ -41,6 +41,7 @@ > .\" 2005-04-25, mtk -- noted aberrant Linux behavior w.r.t. new > .\" attaches to a segment that has already been marked for deletion. > .\" 2005-08-02, mtk: Added IPC_INFO, SHM_INFO, SHM_STAT descriptions. > +.\" 2018-02-13, dbueso: Added SHM_STAT_ALL description. > .\" > .TH SHMCTL 2 2017-09-15 "Linux" "Linux Programmer's Manual" > .SH NAME > @@ -242,6 +243,18 @@ However, the > argument is not a segment identifier, but instead an index into > the kernel's internal array that maintains information about > all shared memory segments on the system. > +.TP > +.BR SHM_STAT_ALL " (Linux-specific)" > +Return a > +.I shmid_ds > +structure as for > +.BR SHM_STAT . > +However, the > +.I shm_perm.mode > +is not checked for read access for > +.IR shmid , > +resembing the behaviour of > +/proc/sysvipc/shm. > .PP > The caller can prevent or allow swapping of a shared > memory segment with the following \fIcmd\fP values: > @@ -287,7 +300,7 @@ operation returns the index of the highest used entry in the > kernel's internal array recording information about all > shared memory segments. > (This information can be used with repeated > -.B SHM_STAT > +.B SHM_STAT/SHM_STAT_ALL > operations to obtain information about all shared memory segments > on the system.) > A successful > @@ -328,7 +341,7 @@ isn't accessible. > \fIshmid\fP is not a valid identifier, or \fIcmd\fP > is not a valid command. > Or: for a > -.B SHM_STAT > +.B SHM_STAT/SHM_STAT_ALL > operation, the index value specified in > .I shmid > referred to an array slot that is currently unused. > > > Thanks! > > [1] https://lkml.org/lkml/2017/12/19/220 > > Davidlohr Bueso (3): > ipc/shm: introduce shmctl(SHM_STAT_ALL) > ipc/sem: introduce shmctl(SEM_STAT_ALL) > ipc/msg: introduce shmctl(MSG_STAT_ALL) > > include/uapi/linux/msg.h | 1 + > include/uapi/linux/sem.h | 1 + > include/uapi/linux/shm.h | 5 +++-- > ipc/msg.c | 17 ++++++++++++----- > ipc/sem.c | 17 ++++++++++++----- > ipc/shm.c | 23 ++++++++++++++++++----- > security/selinux/hooks.c | 3 +++ > 7 files changed, 50 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
