[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180213220911.e57z65efqx52pz53@linux-n805>
Date: Tue, 13 Feb 2018 14:09:11 -0800
From: Davidlohr Bueso <dave@...olabs.net>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: akpm@...ux-foundation.org, mhocko@...nel.org,
mtk.manpages@...il.com, keescook@...omium.org,
linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands
On Tue, 13 Feb 2018, Eric W. Biederman wrote:
>Davidlohr Bueso <dave@...olabs.net> 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.
Nice word that, kibitz.
>
>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.
Yeah, and _ALL similarly makes the difference of IPC_STAT and SHM_STAT wrt
the passed shmid that more adhoc.
I'm going to go with _STAT_ANY.
Thanks,
Davidlohr
Powered by blists - more mailing lists