linux-kernel - ipc: object information data in proc and sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG27Bk1q5t590bvGg7Ka+2M-yWEMk_58sZsOxDKx-1XNn8mHww@mail.gmail.com>
Date:	Sun, 18 Nov 2012 12:31:08 +0000
From:	Sami Kerola <kerolasa@....fi>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Doug Ledford <dledford@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-kernel@...r.kernel.org
Cc:	Karel Zak <kzak@...hat.com>
Subject: ipc: object information data in proc and sysfs

Hello,

While back I started to look how to get util-linux ipcs(1) tool to
read values from /proc instead of using IPC multiplex functions.  Most
of the data ipcs(1) is interested is available in /proc, but there are
few exceptions, such as

msgctl q_qbytes
semctl getval
semctl sempid
semctl semncnt
semctl semzcnt

The simplest thing to do would be to add values in /proc/sysvipc/msg
and /proc/sysvipc/sem as additional fields, but that does not seem
right, as it would result to ABI change.

More effort requiring change would be to add information in new sysfs
paths.  The IPC facilities are using id's which could be used as
placeholder directories for the data needed.  Something like

/proc/sys/kernel/ipc/{m,s,q}/id/info
                 ^^^^^^^^^^^^^^^^^^^

That sort of structure would allow future extensions IPC data without
much pain.  I also assume that subdirectories could allow a little
more precise controls, and perhaps some selected values might be made
writable in future.  If nothing else at least expressing in sensible
format semaphore lock wait queues could make debugging tools, such as
lslocks(8), more useful.

I could give a try this change, but not without hearing the concept
makes sense and could be considered part of upstream kernel (assuming
my coding meets the usual quality criteria).

Any thoughts, comments, recommendations?

--
   Sami Kerola
   http://www.iki.fi/kerolasa/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/