Received: by 10.223.185.116 with SMTP id b49csp3928140wrg; Tue, 13 Feb 2018 09:54:00 -0800 (PST) X-Google-Smtp-Source: AH8x227XazW4neU8OooXP5ZUQs4Kle1/44mgWl0c0/375frxK8lvvPG0u0Dmlc2ePq5v6NooqKiD X-Received: by 10.101.65.9 with SMTP id w9mr1628440pgp.214.1518544440322; Tue, 13 Feb 2018 09:54:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518544440; cv=none; d=google.com; s=arc-20160816; b=IiC0Nbs39+asNihgZq9L8Oy9hpHpJs0vjDgC6vSUbnpHqDX/jOsqTPR6MXZr4k0urY WJERR7XTCUC3tvuX0DNCPdHyzzLreIl7BZ0kRFYiYIGSKIxz9KB5N6YFDrukKDvx8+Uo aCTT7ZjRV8Hhu8huYukYrcE482hYTMn+J+egtxjzA2l8Bucg+UQxNI1lrq0IDAIciv+e lb+KKghgQyo9ExrMsVPR9/TnFCzcuJ6Je7V9VCW+XZnqBBcJ6EYGzPBLZBu4lnorjHro 2ZWDw88SFTps+nYZiSUOggSOe58UG2+XjP9iryUX7WkZrspfDcfGs3WkDwjaMBC5FKnk RxVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=0AyO5u1H4k/RhVZJBb6Q/jcQbweKtRmPV0xDwyWL9yM=; b=nEcK1I+BYXDoc0WZJIx3LJ9xzZoNYvkGeJceRSAOvWIDtrdrrOeRc4rHPRew36wQY1 /+d4tFZrxIN7IjTR9xo+CbB/O+DaHHYCusk30quIj/UxJffNoHGFVx1aQbK6O36ORRjk M0Wf5QNFfYKKDx4i8QI1uqVZc12dUUVxnRe/rjXxAz7wr7z3aRjvqGTvdDP+bxcUj7v5 Ow/SG5fjeWeR27jqlbtQK4xL0kwWI7OqBh0BnRxN3GPkj3gRreoVpIWeOv6cWRTuvrN0 Ap2kz9TXf6Aji644O4fWug1KO+vMb9qEesGr3yPpXs2zcNj5uueLpdjLcF63iHGYHpi5 ryPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w10-v6si4054907plp.561.2018.02.13.09.53.46; Tue, 13 Feb 2018 09:54:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965462AbeBMRwG (ORCPT + 99 others); Tue, 13 Feb 2018 12:52:06 -0500 Received: from smtp2.provo.novell.com ([137.65.250.81]:54567 "EHLO smtp2.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965350AbeBMRvE (ORCPT ); Tue, 13 Feb 2018 12:51:04 -0500 Received: from linux-n805.suse.de (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by smtp2.provo.novell.com with ESMTP (TLS encrypted); Tue, 13 Feb 2018 10:50:56 -0700 From: Davidlohr Bueso To: akpm@linux-foundation.org Cc: mhocko@kernel.org, mtk.manpages@gmail.com, keescook@chromium.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands Date: Tue, 13 Feb 2018 09:41:33 -0800 Message-Id: <20180213174136.6346-1-dave@stgolabs.net> X-Mailer: git-send-email 2.13.6 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: 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(-) -- 2.13.6