License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
// SPDX-License-Identifier: GPL-2.0
2005-04-17 02:20:36 +04:00
/*
* linux / ipc / util . c
* Copyright ( C ) 1992 Krishna Balasubramanian
*
* Sep 1997 - Call suser ( ) last after " normal " permission checks so we
* get BSD style process accounting right .
* Occurs in several places in the IPC code .
* Chris Evans , < chris @ ferret . lmh . ox . ac . uk >
* Nov 1999 - ipc helper functions , unified SMP locking
2006-01-15 04:43:54 +03:00
* Manfred Spraul < manfred @ colorfullife . com >
2005-04-17 02:20:36 +04:00
* Oct 2002 - One lock per IPC id . RCU ipc_free for lock - free grow_ary ( ) .
* Mingming Cao < cmm @ us . ibm . com >
2006-04-03 01:07:33 +04:00
* Mar 2006 - support for audit of ipc object properties
* Dustin Kirkland < dustin . kirkland @ us . ibm . com >
2006-10-02 13:18:20 +04:00
* Jun 2006 - namespaces ssupport
* OpenVZ , SWsoft Inc .
* Pavel Emelianov < xemul @ openvz . org >
2013-09-12 01:26:26 +04:00
*
* General sysv ipc locking scheme :
2013-10-17 00:46:45 +04:00
* rcu_read_lock ( )
* obtain the ipc object ( kern_ipc_perm ) by looking up the id in an idr
* tree .
* - perform initial checks ( capabilities , auditing and permission ,
* etc ) .
2018-02-07 02:40:49 +03:00
* - perform read - only operations , such as INFO command , that
* do not demand atomicity
2013-10-17 00:46:45 +04:00
* acquire the ipc lock ( kern_ipc_perm . lock ) through
* ipc_lock_object ( )
2018-02-07 02:40:49 +03:00
* - perform read - only operations that demand atomicity ,
* such as STAT command .
2013-10-17 00:46:45 +04:00
* - perform data updates , such as SET , RMID commands and
* mechanism - specific operations ( semop / semtimedop ,
* msgsnd / msgrcv , shmat / shmdt ) .
* drop the ipc lock , through ipc_unlock_object ( ) .
* rcu_read_unlock ( )
*
* The ids - > rwsem must be taken when :
* - creating , removing and iterating the existing entries in ipc
* identifier sets .
* - iterating through files under / proc / sysvipc /
*
* Note that sems have a special fast path that avoids kern_ipc_perm . lock -
* see sem_lock ( ) .
2005-04-17 02:20:36 +04:00
*/
# include <linux/mm.h>
# include <linux/shm.h>
# include <linux/init.h>
# include <linux/msg.h>
# include <linux/vmalloc.h>
# include <linux/slab.h>
2013-04-30 02:08:05 +04:00
# include <linux/notifier.h>
2006-01-11 23:17:46 +03:00
# include <linux/capability.h>
2005-04-17 02:20:36 +04:00
# include <linux/highuid.h>
# include <linux/security.h>
# include <linux/rcupdate.h>
# include <linux/workqueue.h>
2005-09-07 02:17:09 +04:00
# include <linux/seq_file.h>
# include <linux/proc_fs.h>
2006-04-03 01:07:33 +04:00
# include <linux/audit.h>
2006-10-02 13:18:20 +04:00
# include <linux/nsproxy.h>
2007-10-19 10:40:54 +04:00
# include <linux/rwsem.h>
2008-04-29 12:00:42 +04:00
# include <linux/memory.h>
2008-02-08 15:18:22 +03:00
# include <linux/ipc_namespace.h>
2018-06-18 05:52:50 +03:00
# include <linux/rhashtable.h>
ipc/util.c: use binary search for max_idx
If semctl(), msgctl() and shmctl() are called with IPC_INFO, SEM_INFO,
MSG_INFO or SHM_INFO, then the return value is the index of the highest
used index in the kernel's internal array recording information about all
SysV objects of the requested type for the current namespace. (This
information can be used with repeated ..._STAT or ..._STAT_ANY operations
to obtain information about all SysV objects on the system.)
There is a cache for this value. But when the cache needs up be updated,
then the highest used index is determined by looping over all possible
values. With the introduction of IPCMNI_EXTEND_SHIFT, this could be a
loop over 16 million entries. And due to /proc/sys/kernel/*next_id, the
index values do not need to be consecutive.
With <write 16000000 to msg_next_id>, msgget(), msgctl(,IPC_RMID) in a
loop, I have observed a performance increase of around factor 13000.
As there is no get_last() function for idr structures: Implement a
"get_last()" using a binary search.
As far as I see, ipc is the only user that needs get_last(), thus
implement it in ipc/util.c and not in a central location.
[akpm@linux-foundation.org: tweak comment, fix typo]
Link: https://lkml.kernel.org/r/20210425075208.11777-2-manfred@colorfullife.com
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Davidlohr Bueso <dbueso@suse.de>
Cc: <1vier1@web.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-01 04:57:18 +03:00
# include <linux/log2.h>
2005-04-17 02:20:36 +04:00
# include <asm/unistd.h>
# include "util.h"
2005-09-07 02:17:09 +04:00
struct ipc_proc_iface {
const char * path ;
const char * header ;
2006-10-02 13:18:20 +04:00
int ids ;
2005-09-07 02:17:09 +04:00
int ( * show ) ( struct seq_file * , void * ) ;
} ;
2005-04-17 02:20:36 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_init - initialise ipc subsystem
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* The various sysv ipc resources ( semaphores , messages and shared
* memory ) are initialised .
*
* A callback routine is registered into the memory hotplug notifier
* chain : since msgmni scales to lowmem this callback routine will be
* called upon successful memory add / remove to recompute msmgni .
2005-04-17 02:20:36 +04:00
*/
static int __init ipc_init ( void )
{
2018-04-11 02:30:58 +03:00
proc_mkdir ( " sysvipc " , NULL ) ;
2018-08-22 08:01:56 +03:00
sem_init ( ) ;
msg_init ( ) ;
2005-04-17 02:20:36 +04:00
shm_init ( ) ;
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
2018-08-22 08:01:56 +03:00
return 0 ;
2005-04-17 02:20:36 +04:00
}
2014-04-08 02:39:18 +04:00
device_initcall ( ipc_init ) ;
2005-04-17 02:20:36 +04:00
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
static const struct rhashtable_params ipc_kht_params = {
. head_offset = offsetof ( struct kern_ipc_perm , khtnode ) ,
. key_offset = offsetof ( struct kern_ipc_perm , key ) ,
2019-12-09 21:31:43 +03:00
. key_len = sizeof_field ( struct kern_ipc_perm , key ) ,
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
. automatic_shrinking = true ,
} ;
2005-04-17 02:20:36 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_init_ids - initialise ipc identifiers
* @ ids : ipc identifier set
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* Set up the sequence range to use for the ipc identifier range ( limited
2019-05-15 01:46:29 +03:00
* below ipc_mni ) then initialise the keys hashtable and ids idr .
2005-04-17 02:20:36 +04:00
*/
2018-08-22 08:01:56 +03:00
void ipc_init_ids ( struct ipc_ids * ids )
2005-04-17 02:20:36 +04:00
{
ids - > in_use = 0 ;
ids - > seq = 0 ;
2014-01-28 05:07:09 +04:00
init_rwsem ( & ids - > rwsem ) ;
2018-08-22 08:01:56 +03:00
rhashtable_init ( & ids - > key_ht , & ipc_kht_params ) ;
2007-10-19 10:40:48 +04:00
idr_init ( & ids - > ipcs_idr ) ;
2018-08-22 08:02:00 +03:00
ids - > max_idx = - 1 ;
2019-05-15 01:46:33 +03:00
ids - > last_idx = - 1 ;
2017-11-18 02:31:08 +03:00
# ifdef CONFIG_CHECKPOINT_RESTORE
ids - > next_id = - 1 ;
# endif
2005-04-17 02:20:36 +04:00
}
2005-09-07 02:17:09 +04:00
# ifdef CONFIG_PROC_FS
2020-02-04 04:37:17 +03:00
static const struct proc_ops sysvipc_proc_ops ;
2005-09-07 02:17:09 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_init_proc_interface - create a proc interface for sysipc types using a seq_file interface .
* @ path : Path in procfs
* @ header : Banner to be printed at the beginning of the file .
* @ ids : ipc id table to iterate .
* @ show : show routine .
2005-09-07 02:17:09 +04:00
*/
void __init ipc_init_proc_interface ( const char * path , const char * header ,
2006-10-02 13:18:20 +04:00
int ids , int ( * show ) ( struct seq_file * , void * ) )
2005-09-07 02:17:09 +04:00
{
struct proc_dir_entry * pde ;
struct ipc_proc_iface * iface ;
iface = kmalloc ( sizeof ( * iface ) , GFP_KERNEL ) ;
if ( ! iface )
return ;
iface - > path = path ;
iface - > header = header ;
iface - > ids = ids ;
iface - > show = show ;
2008-04-29 12:02:12 +04:00
pde = proc_create_data ( path ,
S_IRUGO , /* world readable */
NULL , /* parent dir */
2020-02-04 04:37:17 +03:00
& sysvipc_proc_ops ,
2008-04-29 12:02:12 +04:00
iface ) ;
2014-01-28 05:07:06 +04:00
if ( ! pde )
2005-09-07 02:17:09 +04:00
kfree ( iface ) ;
}
# endif
2005-04-17 02:20:36 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_findkey - find a key in an ipc identifier set
* @ ids : ipc identifier set
* @ key : key to find
2014-06-07 01:37:37 +04:00
*
2014-01-28 05:07:05 +04:00
* Returns the locked pointer to the ipc structure if found or NULL
* otherwise . If key is found ipc points to the owning ipc structure
*
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
* Called with writer ipc_ids . rwsem held .
2005-04-17 02:20:36 +04:00
*/
2007-10-19 10:40:49 +04:00
static struct kern_ipc_perm * ipc_findkey ( struct ipc_ids * ids , key_t key )
2005-04-17 02:20:36 +04:00
{
ipc: get rid of ids->tables_initialized hack
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70bd ("ipc: optimize semget/shmget/msgget for lots
of keys")
It's there, specifically, to prevent nil pointer dereferences, from using
an uninitialized api. Considering how rhashtable_init() can fail
(probably due to ENOMEM, if anything), this made the overall ipc
initialization capable of failure as well. That alone is ugly, but fine,
however I've spotted a few issues regarding the semantics of
tables_initialized (however unlikely they may be):
- There is inconsistency in what we return to userspace: ipc_addid()
returns ENOSPC which is certainly _wrong_, while ipc_obtain_object_idr()
returns EINVAL.
- After we started using rhashtables, ipc_findkey() can return nil upon
!tables_initialized, but the caller expects nil for when the ipc
structure isn't found, and can therefore call into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly get rid of
the hack altogether.
[manfred@colorfullife.com: commit id extended to 12 digits]
Link: http://lkml.kernel.org/r/20180712185241.4017-10-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-22 08:01:52 +03:00
struct kern_ipc_perm * ipcp ;
2007-10-19 10:40:48 +04:00
ipc: get rid of ids->tables_initialized hack
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70bd ("ipc: optimize semget/shmget/msgget for lots
of keys")
It's there, specifically, to prevent nil pointer dereferences, from using
an uninitialized api. Considering how rhashtable_init() can fail
(probably due to ENOMEM, if anything), this made the overall ipc
initialization capable of failure as well. That alone is ugly, but fine,
however I've spotted a few issues regarding the semantics of
tables_initialized (however unlikely they may be):
- There is inconsistency in what we return to userspace: ipc_addid()
returns ENOSPC which is certainly _wrong_, while ipc_obtain_object_idr()
returns EINVAL.
- After we started using rhashtables, ipc_findkey() can return nil upon
!tables_initialized, but the caller expects nil for when the ipc
structure isn't found, and can therefore call into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly get rid of
the hack altogether.
[manfred@colorfullife.com: commit id extended to 12 digits]
Link: http://lkml.kernel.org/r/20180712185241.4017-10-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-22 08:01:52 +03:00
ipcp = rhashtable_lookup_fast ( & ids - > key_ht , & key ,
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
ipc_kht_params ) ;
ipc: get rid of ids->tables_initialized hack
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70bd ("ipc: optimize semget/shmget/msgget for lots
of keys")
It's there, specifically, to prevent nil pointer dereferences, from using
an uninitialized api. Considering how rhashtable_init() can fail
(probably due to ENOMEM, if anything), this made the overall ipc
initialization capable of failure as well. That alone is ugly, but fine,
however I've spotted a few issues regarding the semantics of
tables_initialized (however unlikely they may be):
- There is inconsistency in what we return to userspace: ipc_addid()
returns ENOSPC which is certainly _wrong_, while ipc_obtain_object_idr()
returns EINVAL.
- After we started using rhashtables, ipc_findkey() can return nil upon
!tables_initialized, but the caller expects nil for when the ipc
structure isn't found, and can therefore call into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly get rid of
the hack altogether.
[manfred@colorfullife.com: commit id extended to 12 digits]
Link: http://lkml.kernel.org/r/20180712185241.4017-10-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-22 08:01:52 +03:00
if ( ! ipcp )
return NULL ;
2007-10-19 10:40:48 +04:00
ipc: get rid of ids->tables_initialized hack
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70bd ("ipc: optimize semget/shmget/msgget for lots
of keys")
It's there, specifically, to prevent nil pointer dereferences, from using
an uninitialized api. Considering how rhashtable_init() can fail
(probably due to ENOMEM, if anything), this made the overall ipc
initialization capable of failure as well. That alone is ugly, but fine,
however I've spotted a few issues regarding the semantics of
tables_initialized (however unlikely they may be):
- There is inconsistency in what we return to userspace: ipc_addid()
returns ENOSPC which is certainly _wrong_, while ipc_obtain_object_idr()
returns EINVAL.
- After we started using rhashtables, ipc_findkey() can return nil upon
!tables_initialized, but the caller expects nil for when the ipc
structure isn't found, and can therefore call into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly get rid of
the hack altogether.
[manfred@colorfullife.com: commit id extended to 12 digits]
Link: http://lkml.kernel.org/r/20180712185241.4017-10-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-22 08:01:52 +03:00
rcu_read_lock ( ) ;
ipc_lock_object ( ipcp ) ;
return ipcp ;
2005-04-17 02:20:36 +04:00
}
2017-11-18 02:31:08 +03:00
/*
2018-08-22 08:01:25 +03:00
* Insert new IPC object into idr tree , and set sequence number and id
* in the correct order .
* Especially :
* - the sequence number must be set before inserting the object into the idr ,
* because the sequence number is accessed without a lock .
* - the id can / must be set after inserting the object into the idr .
* All accesses must be done after getting kern_ipc_perm . lock .
*
* The caller must own kern_ipc_perm . lock . of the new object .
* On error , the function returns a ( negative ) error code .
2019-05-15 01:46:33 +03:00
*
* To conserve sequence number space , especially with extended ipc_mni ,
* the sequence number is incremented only when the returned ID is less than
* the last one .
2017-11-18 02:31:08 +03:00
*/
2018-08-22 08:01:25 +03:00
static inline int ipc_idr_alloc ( struct ipc_ids * ids , struct kern_ipc_perm * new )
2017-11-18 02:31:08 +03:00
{
2018-08-22 08:01:25 +03:00
int idx , next_id = - 1 ;
# ifdef CONFIG_CHECKPOINT_RESTORE
next_id = ids - > next_id ;
ids - > next_id = - 1 ;
# endif
/*
* As soon as a new object is inserted into the idr ,
* ipc_obtain_object_idr ( ) or ipc_obtain_object_check ( ) can find it ,
* and the lockless preparations for ipc operations can start .
* This means especially : permission checks , audit calls , allocation
* of undo structures , . . .
*
* Thus the object must be fully initialized , and if something fails ,
* then the full tear - down sequence must be followed .
* ( i . e . : set new - > deleted , reduce refcount , call_rcu ( ) )
*/
if ( next_id < 0 ) { /* !CHECKPOINT_RESTORE or next_id is unset */
ipc: do cyclic id allocation for the ipc object.
For ipcmni_extend mode, the sequence number space is only 7 bits. So
the chance of id reuse is relatively high compared with the non-extended
mode.
To alleviate this id reuse problem, this patch enables cyclic allocation
for the index to the radix tree (idx). The disadvantage is that this
can cause a slight slow-down of the fast path, as the radix tree could
be higher than necessary.
To limit the radix tree height, I have chosen the following limits:
1) The cycling is done over in_use*1.5.
2) At least, the cycling is done over
"normal" ipcnmi mode: RADIX_TREE_MAP_SIZE elements
"ipcmni_extended": 4096 elements
Result:
- for normal mode:
No change for <= 42 active ipc elements. With more than 42
active ipc elements, a 2nd level would be added to the radix
tree.
Without cyclic allocation, a 2nd level would be added only with
more than 63 active elements.
- for extended mode:
Cycling creates always at least a 2-level radix tree.
With more than 2730 active objects, a 3rd level would be
added, instead of > 4095 active objects until the 3rd level
is added without cyclic allocation.
For a 2-level radix tree compared to a 1-level radix tree, I have
observed < 1% performance impact.
Notes:
1) Normal "x=semget();y=semget();" is unaffected: Then the idx
is e.g. a and a+1, regardless if idr_alloc() or idr_alloc_cyclic()
is used.
2) The -1% happens in a microbenchmark after this situation:
x=semget();
for(i=0;i<4000;i++) {t=semget();semctl(t,0,IPC_RMID);}
y=semget();
Now perform semget calls on x and y that do not sleep.
3) The worst-case reuse cycle time is unfortunately unaffected:
If you have 2^24-1 ipc objects allocated, and get/remove the last
possible element in a loop, then the id is reused after 128
get/remove pairs.
Performance check:
A microbenchmark that performes no-op semop() randomly on two IDs,
with only these two IDs allocated.
The IDs were set using /proc/sys/kernel/sem_next_id.
The test was run 5 times, averages are shown.
1 & 2: Base (6.22 seconds for 10.000.000 semops)
1 & 40: -0.2%
1 & 3348: - 0.8%
1 & 27348: - 1.6%
1 & 15777204: - 3.2%
Or: ~12.6 cpu cycles per additional radix tree level.
The cpu is an Intel I3-5010U. ~1300 cpu cycles/syscall is slower
than what I remember (spectre impact?).
V2 of the patch:
- use "min" and "max"
- use RADIX_TREE_MAP_SIZE * RADIX_TREE_MAP_SIZE instead of
(2<<12).
[akpm@linux-foundation.org: fix max() warning]
Link: http://lkml.kernel.org/r/20190329204930.21620-3-longman@redhat.com
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Waiman Long <longman@redhat.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-15 01:46:36 +03:00
int max_idx ;
max_idx = max ( ids - > in_use * 3 / 2 , ipc_min_cycle ) ;
max_idx = min ( max_idx , ipc_mni ) ;
2019-05-15 01:46:33 +03:00
/* allocate the idx, with a NULL struct kern_ipc_perm */
ipc: do cyclic id allocation for the ipc object.
For ipcmni_extend mode, the sequence number space is only 7 bits. So
the chance of id reuse is relatively high compared with the non-extended
mode.
To alleviate this id reuse problem, this patch enables cyclic allocation
for the index to the radix tree (idx). The disadvantage is that this
can cause a slight slow-down of the fast path, as the radix tree could
be higher than necessary.
To limit the radix tree height, I have chosen the following limits:
1) The cycling is done over in_use*1.5.
2) At least, the cycling is done over
"normal" ipcnmi mode: RADIX_TREE_MAP_SIZE elements
"ipcmni_extended": 4096 elements
Result:
- for normal mode:
No change for <= 42 active ipc elements. With more than 42
active ipc elements, a 2nd level would be added to the radix
tree.
Without cyclic allocation, a 2nd level would be added only with
more than 63 active elements.
- for extended mode:
Cycling creates always at least a 2-level radix tree.
With more than 2730 active objects, a 3rd level would be
added, instead of > 4095 active objects until the 3rd level
is added without cyclic allocation.
For a 2-level radix tree compared to a 1-level radix tree, I have
observed < 1% performance impact.
Notes:
1) Normal "x=semget();y=semget();" is unaffected: Then the idx
is e.g. a and a+1, regardless if idr_alloc() or idr_alloc_cyclic()
is used.
2) The -1% happens in a microbenchmark after this situation:
x=semget();
for(i=0;i<4000;i++) {t=semget();semctl(t,0,IPC_RMID);}
y=semget();
Now perform semget calls on x and y that do not sleep.
3) The worst-case reuse cycle time is unfortunately unaffected:
If you have 2^24-1 ipc objects allocated, and get/remove the last
possible element in a loop, then the id is reused after 128
get/remove pairs.
Performance check:
A microbenchmark that performes no-op semop() randomly on two IDs,
with only these two IDs allocated.
The IDs were set using /proc/sys/kernel/sem_next_id.
The test was run 5 times, averages are shown.
1 & 2: Base (6.22 seconds for 10.000.000 semops)
1 & 40: -0.2%
1 & 3348: - 0.8%
1 & 27348: - 1.6%
1 & 15777204: - 3.2%
Or: ~12.6 cpu cycles per additional radix tree level.
The cpu is an Intel I3-5010U. ~1300 cpu cycles/syscall is slower
than what I remember (spectre impact?).
V2 of the patch:
- use "min" and "max"
- use RADIX_TREE_MAP_SIZE * RADIX_TREE_MAP_SIZE instead of
(2<<12).
[akpm@linux-foundation.org: fix max() warning]
Link: http://lkml.kernel.org/r/20190329204930.21620-3-longman@redhat.com
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Waiman Long <longman@redhat.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-15 01:46:36 +03:00
idx = idr_alloc_cyclic ( & ids - > ipcs_idr , NULL , 0 , max_idx ,
GFP_NOWAIT ) ;
2019-05-15 01:46:33 +03:00
if ( idx > = 0 ) {
/*
* idx got allocated successfully .
* Now calculate the sequence number and set the
* pointer for real .
*/
if ( idx < = ids - > last_idx ) {
ids - > seq + + ;
if ( ids - > seq > = ipcid_seq_max ( ) )
ids - > seq = 0 ;
}
ids - > last_idx = idx ;
new - > seq = ids - > seq ;
/* no need for smp_wmb(), this is done
* inside idr_replace , as part of
* rcu_assign_pointer
*/
idr_replace ( & ids - > ipcs_idr , new , idx ) ;
}
2017-11-18 02:31:08 +03:00
} else {
2018-08-22 08:01:25 +03:00
new - > seq = ipcid_to_seqx ( next_id ) ;
idx = idr_alloc ( & ids - > ipcs_idr , new , ipcid_to_idx ( next_id ) ,
0 , GFP_NOWAIT ) ;
2017-11-18 02:31:08 +03:00
}
2018-08-22 08:01:25 +03:00
if ( idx > = 0 )
2019-05-15 01:46:33 +03:00
new - > id = ( new - > seq < < ipcmni_seq_shift ( ) ) + idx ;
2018-08-22 08:01:25 +03:00
return idx ;
2017-11-18 02:31:08 +03:00
}
2005-04-17 02:20:36 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_addid - add an ipc identifier
* @ ids : ipc identifier set
* @ new : new ipc permission set
2017-11-18 02:31:15 +03:00
* @ limit : limit for the number of used ids
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* Add an entry ' new ' to the ipc ids idr . The permissions object is
2018-08-22 08:02:00 +03:00
* initialised and the first free entry is set up and the index assigned
2014-01-28 05:07:05 +04:00
* is returned . The ' new ' entry is returned in a locked state on success .
2018-08-22 08:01:29 +03:00
*
2014-01-28 05:07:05 +04:00
* On failure the entry is not locked and a negative err - code is returned .
2018-08-22 08:01:29 +03:00
* The caller must use ipc_rcu_putref ( ) to free the identifier .
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* Called with writer ipc_ids . rwsem held .
2005-04-17 02:20:36 +04:00
*/
2017-11-18 02:31:15 +03:00
int ipc_addid ( struct ipc_ids * ids , struct kern_ipc_perm * new , int limit )
2005-04-17 02:20:36 +04:00
{
2012-02-08 04:54:11 +04:00
kuid_t euid ;
kgid_t egid ;
2018-08-22 08:01:25 +03:00
int idx , err ;
2005-04-17 02:20:36 +04:00
2018-08-22 08:01:29 +03:00
/* 1) Initialize the refcount so that ipc_rcu_putref works */
refcount_set ( & new - > refcount , 1 ) ;
2019-05-15 01:46:29 +03:00
if ( limit > ipc_mni )
limit = ipc_mni ;
2007-10-19 10:40:48 +04:00
ipc: get rid of ids->tables_initialized hack
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70bd ("ipc: optimize semget/shmget/msgget for lots
of keys")
It's there, specifically, to prevent nil pointer dereferences, from using
an uninitialized api. Considering how rhashtable_init() can fail
(probably due to ENOMEM, if anything), this made the overall ipc
initialization capable of failure as well. That alone is ugly, but fine,
however I've spotted a few issues regarding the semantics of
tables_initialized (however unlikely they may be):
- There is inconsistency in what we return to userspace: ipc_addid()
returns ENOSPC which is certainly _wrong_, while ipc_obtain_object_idr()
returns EINVAL.
- After we started using rhashtables, ipc_findkey() can return nil upon
!tables_initialized, but the caller expects nil for when the ipc
structure isn't found, and can therefore call into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly get rid of
the hack altogether.
[manfred@colorfullife.com: commit id extended to 12 digits]
Link: http://lkml.kernel.org/r/20180712185241.4017-10-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-22 08:01:52 +03:00
if ( ids - > in_use > = limit )
2007-10-19 10:40:57 +04:00
return - ENOSPC ;
2007-10-19 10:40:48 +04:00
2013-02-28 05:04:53 +04:00
idr_preload ( GFP_KERNEL ) ;
2008-11-20 02:36:08 +03:00
spin_lock_init ( & new - > lock ) ;
rcu_read_lock ( ) ;
spin_lock ( & new - > lock ) ;
2015-09-30 19:48:40 +03:00
current_euid_egid ( & euid , & egid ) ;
new - > cuid = new - > uid = euid ;
new - > gid = new - > cgid = egid ;
2018-08-22 08:01:29 +03:00
new - > deleted = false ;
2018-08-22 08:01:25 +03:00
idx = ipc_idr_alloc ( ids , new ) ;
2013-02-28 05:04:53 +04:00
idr_preload_end ( ) ;
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
2018-08-22 08:01:25 +03:00
if ( idx > = 0 & & new - > key ! = IPC_PRIVATE ) {
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
err = rhashtable_insert_fast ( & ids - > key_ht , & new - > khtnode ,
ipc_kht_params ) ;
if ( err < 0 ) {
2018-08-22 08:01:25 +03:00
idr_remove ( & ids - > ipcs_idr , idx ) ;
idx = err ;
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
}
}
2018-08-22 08:01:25 +03:00
if ( idx < 0 ) {
2018-08-22 08:01:29 +03:00
new - > deleted = true ;
2008-11-20 02:36:08 +03:00
spin_unlock ( & new - > lock ) ;
rcu_read_unlock ( ) ;
2018-08-22 08:01:25 +03:00
return idx ;
2008-11-20 02:36:08 +03:00
}
2007-10-19 10:40:48 +04:00
2005-04-17 02:20:36 +04:00
ids - > in_use + + ;
2018-08-22 08:02:00 +03:00
if ( idx > ids - > max_idx )
ids - > max_idx = idx ;
2018-08-22 08:01:25 +03:00
return idx ;
2005-04-17 02:20:36 +04:00
}
2007-10-19 10:40:49 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipcget_new - create a new ipc object
* @ ns : ipc namespace
2014-09-08 20:27:23 +04:00
* @ ids : ipc identifier set
2014-01-28 05:07:05 +04:00
* @ ops : the actual creation routine to call
* @ params : its parameters
*
* This routine is called by sys_msgget , sys_semget ( ) and sys_shmget ( )
* when the key is IPC_PRIVATE .
2007-10-19 10:40:49 +04:00
*/
2008-02-08 15:18:54 +03:00
static int ipcget_new ( struct ipc_namespace * ns , struct ipc_ids * ids ,
2014-06-07 01:37:36 +04:00
const struct ipc_ops * ops , struct ipc_params * params )
2007-10-19 10:40:49 +04:00
{
int err ;
2013-09-12 01:26:24 +04:00
down_write ( & ids - > rwsem ) ;
2007-10-19 10:40:49 +04:00
err = ops - > getnew ( ns , params ) ;
2013-09-12 01:26:24 +04:00
up_write ( & ids - > rwsem ) ;
2007-10-19 10:40:49 +04:00
return err ;
}
/**
2014-01-28 05:07:05 +04:00
* ipc_check_perms - check security and permissions for an ipc object
* @ ns : ipc namespace
* @ ipcp : ipc permission set
* @ ops : the actual security routine to call
* @ params : its parameters
2007-10-19 10:40:53 +04:00
*
2014-01-28 05:07:05 +04:00
* This routine is called by sys_msgget ( ) , sys_semget ( ) and sys_shmget ( )
* when the key is not IPC_PRIVATE and that key already exists in the
* ds IDR .
2007-10-19 10:40:53 +04:00
*
2014-01-28 05:07:05 +04:00
* On success , the ipc id is returned .
2007-10-19 10:40:53 +04:00
*
2014-01-28 05:07:05 +04:00
* It is called with ipc_ids . rwsem and ipcp - > lock held .
2007-10-19 10:40:49 +04:00
*/
2011-03-24 02:43:24 +03:00
static int ipc_check_perms ( struct ipc_namespace * ns ,
struct kern_ipc_perm * ipcp ,
2014-06-07 01:37:36 +04:00
const struct ipc_ops * ops ,
2011-03-24 02:43:24 +03:00
struct ipc_params * params )
2007-10-19 10:40:49 +04:00
{
int err ;
2011-03-24 02:43:24 +03:00
if ( ipcperms ( ns , ipcp , params - > flg ) )
2007-10-19 10:40:49 +04:00
err = - EACCES ;
else {
err = ops - > associate ( ipcp , params - > flg ) ;
if ( ! err )
err = ipcp - > id ;
}
return err ;
}
/**
2014-01-28 05:07:05 +04:00
* ipcget_public - get an ipc object or create a new one
* @ ns : ipc namespace
2014-09-08 20:27:23 +04:00
* @ ids : ipc identifier set
2014-01-28 05:07:05 +04:00
* @ ops : the actual creation routine to call
* @ params : its parameters
*
* This routine is called by sys_msgget , sys_semget ( ) and sys_shmget ( )
* when the key is not IPC_PRIVATE .
* It adds a new entry if the key is not found and does some permission
* / security checkings if the key is found .
*
* On success , the ipc id is returned .
2007-10-19 10:40:49 +04:00
*/
2008-02-08 15:18:54 +03:00
static int ipcget_public ( struct ipc_namespace * ns , struct ipc_ids * ids ,
2014-06-07 01:37:36 +04:00
const struct ipc_ops * ops , struct ipc_params * params )
2007-10-19 10:40:49 +04:00
{
struct kern_ipc_perm * ipcp ;
int flg = params - > flg ;
int err ;
2007-10-19 10:40:54 +04:00
/*
* Take the lock as a writer since we are potentially going to add
* a new entry + read locks are not " upgradable "
*/
2013-09-12 01:26:24 +04:00
down_write ( & ids - > rwsem ) ;
2007-10-19 10:40:49 +04:00
ipcp = ipc_findkey ( ids , params - > key ) ;
if ( ipcp = = NULL ) {
/* key not used */
if ( ! ( flg & IPC_CREAT ) )
err = - ENOENT ;
else
err = ops - > getnew ( ns , params ) ;
} else {
/* ipc object has been locked by ipc_findkey() */
if ( flg & IPC_CREAT & & flg & IPC_EXCL )
err = - EEXIST ;
else {
err = 0 ;
if ( ops - > more_checks )
err = ops - > more_checks ( ipcp , params ) ;
if ( ! err )
2007-10-19 10:40:53 +04:00
/*
* ipc_check_perms returns the IPC id on
* success
*/
2011-03-24 02:43:24 +03:00
err = ipc_check_perms ( ns , ipcp , ops , params ) ;
2007-10-19 10:40:49 +04:00
}
ipc_unlock ( ipcp ) ;
}
2013-09-12 01:26:24 +04:00
up_write ( & ids - > rwsem ) ;
2007-10-19 10:40:49 +04:00
return err ;
}
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
/**
* ipc_kht_remove - remove an ipc from the key hashtable
* @ ids : ipc identifier set
* @ ipcp : ipc perm structure containing the key to remove
*
* ipc_ids . rwsem ( as a writer ) and the spinlock for this ID are held
* before this function is called , and remain locked on the exit .
*/
static void ipc_kht_remove ( struct ipc_ids * ids , struct kern_ipc_perm * ipcp )
{
if ( ipcp - > key ! = IPC_PRIVATE )
ipc: WARN if trying to remove ipc object which is absent
Patch series "shm: shm_rmid_forced feature fixes".
Some time ago I met kernel crash after CRIU restore procedure,
fortunately, it was CRIU restore, so, I had dump files and could do
restore many times and crash reproduced easily. After some
investigation I've constructed the minimal reproducer. It was found
that it's use-after-free and it happens only if sysctl
kernel.shm_rmid_forced = 1.
The key of the problem is that the exit_shm() function not handles shp's
object destroy when task->sysvshm.shm_clist contains items from
different IPC namespaces. In most cases this list will contain only
items from one IPC namespace.
How can this list contain object from different namespaces? The
exit_shm() function is designed to clean up this list always when
process leaves IPC namespace. But we made a mistake a long time ago and
did not add a exit_shm() call into the setns() syscall procedures.
The first idea was just to add this call to setns() syscall but it
obviously changes semantics of setns() syscall and that's
userspace-visible change. So, I gave up on this idea.
The first real attempt to address the issue was just to omit forced
destroy if we meet shp object not from current task IPC namespace [1].
But that was not the best idea because task->sysvshm.shm_clist was
protected by rwsem which belongs to current task IPC namespace. It
means that list corruption may occur.
Second approach is just extend exit_shm() to properly handle shp's from
different IPC namespaces [2]. This is really non-trivial thing, I've
put a lot of effort into that but not believed that it's possible to
make it fully safe, clean and clear.
Thanks to the efforts of Manfred Spraul working an elegant solution was
designed. Thanks a lot, Manfred!
Eric also suggested the way to address the issue in ("[RFC][PATCH] shm:
In shm_exit destroy all created and never attached segments") Eric's
idea was to maintain a list of shm_clists one per IPC namespace, use
lock-less lists. But there is some extra memory consumption-related
concerns.
An alternative solution which was suggested by me was implemented in
("shm: reset shm_clist on setns but omit forced shm destroy"). The idea
is pretty simple, we add exit_shm() syscall to setns() but DO NOT
destroy shm segments even if sysctl kernel.shm_rmid_forced = 1, we just
clean up the task->sysvshm.shm_clist list.
This chages semantics of setns() syscall a little bit but in comparision
to the "naive" solution when we just add exit_shm() without any special
exclusions this looks like a safer option.
[1] https://lkml.org/lkml/2021/7/6/1108
[2] https://lkml.org/lkml/2021/7/14/736
This patch (of 2):
Let's produce a warning if we trying to remove non-existing IPC object
from IPC namespace kht/idr structures.
This allows us to catch possible bugs when the ipc_rmid() function was
called with inconsistent struct ipc_ids*, struct kern_ipc_perm*
arguments.
Link: https://lkml.kernel.org/r/20211027224348.611025-1-alexander.mikhalitsyn@virtuozzo.com
Link: https://lkml.kernel.org/r/20211027224348.611025-2-alexander.mikhalitsyn@virtuozzo.com
Co-developed-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Andrei Vagin <avagin@gmail.com>
Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: Vasily Averin <vvs@virtuozzo.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-20 03:43:18 +03:00
WARN_ON_ONCE ( rhashtable_remove_fast ( & ids - > key_ht , & ipcp - > khtnode ,
ipc_kht_params ) ) ;
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
}
2007-10-19 10:40:49 +04:00
ipc/util.c: use binary search for max_idx
If semctl(), msgctl() and shmctl() are called with IPC_INFO, SEM_INFO,
MSG_INFO or SHM_INFO, then the return value is the index of the highest
used index in the kernel's internal array recording information about all
SysV objects of the requested type for the current namespace. (This
information can be used with repeated ..._STAT or ..._STAT_ANY operations
to obtain information about all SysV objects on the system.)
There is a cache for this value. But when the cache needs up be updated,
then the highest used index is determined by looping over all possible
values. With the introduction of IPCMNI_EXTEND_SHIFT, this could be a
loop over 16 million entries. And due to /proc/sys/kernel/*next_id, the
index values do not need to be consecutive.
With <write 16000000 to msg_next_id>, msgget(), msgctl(,IPC_RMID) in a
loop, I have observed a performance increase of around factor 13000.
As there is no get_last() function for idr structures: Implement a
"get_last()" using a binary search.
As far as I see, ipc is the only user that needs get_last(), thus
implement it in ipc/util.c and not in a central location.
[akpm@linux-foundation.org: tweak comment, fix typo]
Link: https://lkml.kernel.org/r/20210425075208.11777-2-manfred@colorfullife.com
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Davidlohr Bueso <dbueso@suse.de>
Cc: <1vier1@web.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-01 04:57:18 +03:00
/**
* ipc_search_maxidx - search for the highest assigned index
* @ ids : ipc identifier set
* @ limit : known upper limit for highest assigned index
*
* The function determines the highest assigned index in @ ids . It is intended
* to be called when ids - > max_idx needs to be updated .
* Updating ids - > max_idx is necessary when the current highest index ipc
* object is deleted .
* If no ipc object is allocated , then - 1 is returned .
*
* ipc_ids . rwsem needs to be held by the caller .
*/
static int ipc_search_maxidx ( struct ipc_ids * ids , int limit )
{
int tmpidx ;
int i ;
int retval ;
i = ilog2 ( limit + 1 ) ;
retval = 0 ;
for ( ; i > = 0 ; i - - ) {
tmpidx = retval | ( 1 < < i ) ;
/*
* " 0 " is a possible index value , thus search using
* e . g . 15 , 7 , 3 , 1 , 0 instead of 16 , 8 , 4 , 2 , 1.
*/
tmpidx = tmpidx - 1 ;
if ( idr_get_next ( & ids - > ipcs_idr , & tmpidx ) )
retval | = ( 1 < < i ) ;
}
return retval - 1 ;
}
2005-04-17 02:20:36 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_rmid - remove an ipc identifier
* @ ids : ipc identifier set
* @ ipcp : ipc perm structure containing the identifier to remove
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* ipc_ids . rwsem ( as a writer ) and the spinlock for this ID are held
* before this function is called , and remain locked on the exit .
2005-04-17 02:20:36 +04:00
*/
2007-10-19 10:40:48 +04:00
void ipc_rmid ( struct ipc_ids * ids , struct kern_ipc_perm * ipcp )
2005-04-17 02:20:36 +04:00
{
2018-08-22 08:02:00 +03:00
int idx = ipcid_to_idx ( ipcp - > id ) ;
2007-10-19 10:40:48 +04:00
ipc: WARN if trying to remove ipc object which is absent
Patch series "shm: shm_rmid_forced feature fixes".
Some time ago I met kernel crash after CRIU restore procedure,
fortunately, it was CRIU restore, so, I had dump files and could do
restore many times and crash reproduced easily. After some
investigation I've constructed the minimal reproducer. It was found
that it's use-after-free and it happens only if sysctl
kernel.shm_rmid_forced = 1.
The key of the problem is that the exit_shm() function not handles shp's
object destroy when task->sysvshm.shm_clist contains items from
different IPC namespaces. In most cases this list will contain only
items from one IPC namespace.
How can this list contain object from different namespaces? The
exit_shm() function is designed to clean up this list always when
process leaves IPC namespace. But we made a mistake a long time ago and
did not add a exit_shm() call into the setns() syscall procedures.
The first idea was just to add this call to setns() syscall but it
obviously changes semantics of setns() syscall and that's
userspace-visible change. So, I gave up on this idea.
The first real attempt to address the issue was just to omit forced
destroy if we meet shp object not from current task IPC namespace [1].
But that was not the best idea because task->sysvshm.shm_clist was
protected by rwsem which belongs to current task IPC namespace. It
means that list corruption may occur.
Second approach is just extend exit_shm() to properly handle shp's from
different IPC namespaces [2]. This is really non-trivial thing, I've
put a lot of effort into that but not believed that it's possible to
make it fully safe, clean and clear.
Thanks to the efforts of Manfred Spraul working an elegant solution was
designed. Thanks a lot, Manfred!
Eric also suggested the way to address the issue in ("[RFC][PATCH] shm:
In shm_exit destroy all created and never attached segments") Eric's
idea was to maintain a list of shm_clists one per IPC namespace, use
lock-less lists. But there is some extra memory consumption-related
concerns.
An alternative solution which was suggested by me was implemented in
("shm: reset shm_clist on setns but omit forced shm destroy"). The idea
is pretty simple, we add exit_shm() syscall to setns() but DO NOT
destroy shm segments even if sysctl kernel.shm_rmid_forced = 1, we just
clean up the task->sysvshm.shm_clist list.
This chages semantics of setns() syscall a little bit but in comparision
to the "naive" solution when we just add exit_shm() without any special
exclusions this looks like a safer option.
[1] https://lkml.org/lkml/2021/7/6/1108
[2] https://lkml.org/lkml/2021/7/14/736
This patch (of 2):
Let's produce a warning if we trying to remove non-existing IPC object
from IPC namespace kht/idr structures.
This allows us to catch possible bugs when the ipc_rmid() function was
called with inconsistent struct ipc_ids*, struct kern_ipc_perm*
arguments.
Link: https://lkml.kernel.org/r/20211027224348.611025-1-alexander.mikhalitsyn@virtuozzo.com
Link: https://lkml.kernel.org/r/20211027224348.611025-2-alexander.mikhalitsyn@virtuozzo.com
Co-developed-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Andrei Vagin <avagin@gmail.com>
Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: Vasily Averin <vvs@virtuozzo.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-20 03:43:18 +03:00
WARN_ON_ONCE ( idr_remove ( & ids - > ipcs_idr , idx ) ! = ipcp ) ;
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
ipc_kht_remove ( ids , ipcp ) ;
2005-04-17 02:20:36 +04:00
ids - > in_use - - ;
2014-01-28 05:07:02 +04:00
ipcp - > deleted = true ;
2017-11-18 02:31:18 +03:00
2018-08-22 08:02:00 +03:00
if ( unlikely ( idx = = ids - > max_idx ) ) {
ipc/util.c: use binary search for max_idx
If semctl(), msgctl() and shmctl() are called with IPC_INFO, SEM_INFO,
MSG_INFO or SHM_INFO, then the return value is the index of the highest
used index in the kernel's internal array recording information about all
SysV objects of the requested type for the current namespace. (This
information can be used with repeated ..._STAT or ..._STAT_ANY operations
to obtain information about all SysV objects on the system.)
There is a cache for this value. But when the cache needs up be updated,
then the highest used index is determined by looping over all possible
values. With the introduction of IPCMNI_EXTEND_SHIFT, this could be a
loop over 16 million entries. And due to /proc/sys/kernel/*next_id, the
index values do not need to be consecutive.
With <write 16000000 to msg_next_id>, msgget(), msgctl(,IPC_RMID) in a
loop, I have observed a performance increase of around factor 13000.
As there is no get_last() function for idr structures: Implement a
"get_last()" using a binary search.
As far as I see, ipc is the only user that needs get_last(), thus
implement it in ipc/util.c and not in a central location.
[akpm@linux-foundation.org: tweak comment, fix typo]
Link: https://lkml.kernel.org/r/20210425075208.11777-2-manfred@colorfullife.com
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Davidlohr Bueso <dbueso@suse.de>
Cc: <1vier1@web.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-01 04:57:18 +03:00
idx = ids - > max_idx - 1 ;
if ( idx > = 0 )
idx = ipc_search_maxidx ( ids , idx ) ;
2018-08-22 08:02:00 +03:00
ids - > max_idx = idx ;
2017-11-18 02:31:18 +03:00
}
2005-04-17 02:20:36 +04:00
}
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
/**
* ipc_set_key_private - switch the key of an existing ipc to IPC_PRIVATE
* @ ids : ipc identifier set
* @ ipcp : ipc perm structure containing the key to modify
*
* ipc_ids . rwsem ( as a writer ) and the spinlock for this ID are held
* before this function is called , and remain locked on the exit .
*/
void ipc_set_key_private ( struct ipc_ids * ids , struct kern_ipc_perm * ipcp )
{
ipc_kht_remove ( ids , ipcp ) ;
ipcp - > key = IPC_PRIVATE ;
}
2018-08-22 08:02:04 +03:00
bool ipc_rcu_getref ( struct kern_ipc_perm * ptr )
2005-04-17 02:20:36 +04:00
{
2017-09-09 02:17:45 +03:00
return refcount_inc_not_zero ( & ptr - > refcount ) ;
2006-11-22 17:55:48 +03:00
}
2017-07-13 00:34:41 +03:00
void ipc_rcu_putref ( struct kern_ipc_perm * ptr ,
void ( * func ) ( struct rcu_head * head ) )
2005-04-17 02:20:36 +04:00
{
2017-09-09 02:17:45 +03:00
if ( ! refcount_dec_and_test ( & ptr - > refcount ) )
2005-04-17 02:20:36 +04:00
return ;
2017-07-13 00:34:41 +03:00
call_rcu ( & ptr - > rcu , func ) ;
ipc: fix race with LSMs
Currently, IPC mechanisms do security and auditing related checks under
RCU. However, since security modules can free the security structure,
for example, through selinux_[sem,msg_queue,shm]_free_security(), we can
race if the structure is freed before other tasks are done with it,
creating a use-after-free condition. Manfred illustrates this nicely,
for instance with shared mem and selinux:
-> do_shmat calls rcu_read_lock()
-> do_shmat calls shm_object_check().
Checks that the object is still valid - but doesn't acquire any locks.
Then it returns.
-> do_shmat calls security_shm_shmat (e.g. selinux_shm_shmat)
-> selinux_shm_shmat calls ipc_has_perm()
-> ipc_has_perm accesses ipc_perms->security
shm_close()
-> shm_close acquires rw_mutex & shm_lock
-> shm_close calls shm_destroy
-> shm_destroy calls security_shm_free (e.g. selinux_shm_free_security)
-> selinux_shm_free_security calls ipc_free_security(&shp->shm_perm)
-> ipc_free_security calls kfree(ipc_perms->security)
This patch delays the freeing of the security structures after all RCU
readers are done. Furthermore it aligns the security life cycle with
that of the rest of IPC - freeing them based on the reference counter.
For situations where we need not free security, the current behavior is
kept. Linus states:
"... the old behavior was suspect for another reason too: having the
security blob go away from under a user sounds like it could cause
various other problems anyway, so I think the old code was at least
_prone_ to bugs even if it didn't have catastrophic behavior."
I have tested this patch with IPC testcases from LTP on both my
quad-core laptop and on a 64 core NUMA server. In both cases selinux is
enabled, and tests pass for both voluntary and forced preemption models.
While the mentioned races are theoretical (at least no one as reported
them), I wanted to make sure that this new logic doesn't break anything
we weren't aware of.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Acked-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-24 04:04:45 +04:00
}
2005-04-17 02:20:36 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipcperms - check ipc permissions
* @ ns : ipc namespace
* @ ipcp : ipc permission set
* @ flag : desired permission set
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* Check user , group , other permissions for access
* to ipc resources . return 0 if allowed
2011-03-24 02:43:24 +03:00
*
2017-03-30 23:11:36 +03:00
* @ flag will most probably be 0 or ` ` S_ . . . UGO ` ` from < linux / stat . h >
2005-04-17 02:20:36 +04:00
*/
2011-03-24 02:43:24 +03:00
int ipcperms ( struct ipc_namespace * ns , struct kern_ipc_perm * ipcp , short flag )
{
2012-02-08 04:54:11 +04:00
kuid_t euid = current_euid ( ) ;
2008-12-10 11:40:06 +03:00
int requested_mode , granted_mode ;
2005-04-17 02:20:36 +04:00
2008-12-10 11:40:06 +03:00
audit_ipc_obj ( ipcp ) ;
2005-04-17 02:20:36 +04:00
requested_mode = ( flag > > 6 ) | ( flag > > 3 ) | flag ;
granted_mode = ipcp - > mode ;
2012-02-08 04:54:11 +04:00
if ( uid_eq ( euid , ipcp - > cuid ) | |
uid_eq ( euid , ipcp - > uid ) )
2005-04-17 02:20:36 +04:00
granted_mode > > = 6 ;
else if ( in_group_p ( ipcp - > cgid ) | | in_group_p ( ipcp - > gid ) )
granted_mode > > = 3 ;
/* is there some bit set in requested_mode but not in granted_mode? */
2014-06-07 01:37:37 +04:00
if ( ( requested_mode & ~ granted_mode & 0007 ) & &
2011-03-24 02:43:24 +03:00
! ns_capable ( ns - > user_ns , CAP_IPC_OWNER ) )
2005-04-17 02:20:36 +04:00
return - 1 ;
return security_ipc_permission ( ipcp , flag ) ;
}
/*
* Functions to convert between the kern_ipc_perm structure and the
* old / new ipc_perm structures
*/
/**
2014-01-28 05:07:05 +04:00
* kernel_to_ipc64_perm - convert kernel ipc permissions to user
* @ in : kernel permissions
* @ out : new style ipc permissions
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* Turn the kernel object @ in into a set of permissions descriptions
* for returning to userspace ( @ out ) .
2005-04-17 02:20:36 +04:00
*/
2014-01-28 05:07:04 +04:00
void kernel_to_ipc64_perm ( struct kern_ipc_perm * in , struct ipc64_perm * out )
2005-04-17 02:20:36 +04:00
{
out - > key = in - > key ;
2012-02-08 04:54:11 +04:00
out - > uid = from_kuid_munged ( current_user_ns ( ) , in - > uid ) ;
out - > gid = from_kgid_munged ( current_user_ns ( ) , in - > gid ) ;
out - > cuid = from_kuid_munged ( current_user_ns ( ) , in - > cuid ) ;
out - > cgid = from_kgid_munged ( current_user_ns ( ) , in - > cgid ) ;
2005-04-17 02:20:36 +04:00
out - > mode = in - > mode ;
out - > seq = in - > seq ;
}
/**
2014-01-28 05:07:05 +04:00
* ipc64_perm_to_ipc_perm - convert new ipc permissions to old
* @ in : new style ipc permissions
* @ out : old style ipc permissions
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* Turn the new style permissions object @ in into a compatibility
* object and store it into the @ out pointer .
2005-04-17 02:20:36 +04:00
*/
2014-01-28 05:07:04 +04:00
void ipc64_perm_to_ipc_perm ( struct ipc64_perm * in , struct ipc_perm * out )
2005-04-17 02:20:36 +04:00
{
out - > key = in - > key ;
SET_UID ( out - > uid , in - > uid ) ;
SET_GID ( out - > gid , in - > gid ) ;
SET_UID ( out - > cuid , in - > cuid ) ;
SET_GID ( out - > cgid , in - > cgid ) ;
out - > mode = in - > mode ;
out - > seq = in - > seq ;
}
2013-05-01 06:15:19 +04:00
/**
ipc: optimize semget/shmget/msgget for lots of keys
ipc_findkey() used to scan all objects to look for the wanted key. This
is slow when using a high number of keys. This change adds an rhashtable
of kern_ipc_perm objects in ipc_ids, so that one lookup cease to be O(n).
This change gives a 865% improvement of benchmark reaim.jobs_per_min on a
56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 256G memory [1]
Other (more micro) benchmark results, by the author: On an i5 laptop, the
following loop executed right after a reboot took, without and with this
change:
for (int i = 0, k=0x424242; i < KEYS; ++i)
semget(k++, 1, IPC_CREAT | 0600);
total total max single max single
KEYS without with call without call with
1 3.5 4.9 µs 3.5 4.9
10 7.6 8.6 µs 3.7 4.7
32 16.2 15.9 µs 4.3 5.3
100 72.9 41.8 µs 3.7 4.7
1000 5,630.0 502.0 µs * *
10000 1,340,000.0 7,240.0 µs * *
31900 17,600,000.0 22,200.0 µs * *
*: unreliable measure: high variance
The duration for a lookup-only usage was obtained by the same loop once
the keys are present:
total total max single max single
KEYS without with call without call with
1 2.1 2.5 µs 2.1 2.5
10 4.5 4.8 µs 2.2 2.3
32 13.0 10.8 µs 2.3 2.8
100 82.9 25.1 µs * 2.3
1000 5,780.0 217.0 µs * *
10000 1,470,000.0 2,520.0 µs * *
31900 17,400,000.0 7,810.0 µs * *
Finally, executing each semget() in a new process gave, when still
summing only the durations of these syscalls:
creation:
total total
KEYS without with
1 3.7 5.0 µs
10 32.9 36.7 µs
32 125.0 109.0 µs
100 523.0 353.0 µs
1000 20,300.0 3,280.0 µs
10000 2,470,000.0 46,700.0 µs
31900 27,800,000.0 219,000.0 µs
lookup-only:
total total
KEYS without with
1 2.5 2.7 µs
10 25.4 24.4 µs
32 106.0 72.6 µs
100 591.0 352.0 µs
1000 22,400.0 2,250.0 µs
10000 2,510,000.0 25,700.0 µs
31900 28,200,000.0 115,000.0 µs
[1] http://lkml.kernel.org/r/20170814060507.GE23258@yexl-desktop
Link: http://lkml.kernel.org/r/20170815194954.ck32ta2z35yuzpwp@debix
Signed-off-by: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Reviewed-by: Marc Pardo <marc.pardo@supersonicimagine.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Guillaume Knispel <guillaume.knispel@supersonicimagine.com>
Cc: Marc Pardo <marc.pardo@supersonicimagine.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-09 02:17:55 +03:00
* ipc_obtain_object_idr
2013-05-01 06:15:19 +04:00
* @ ids : ipc identifier set
* @ id : ipc id to look for
*
* Look for an id in the ipc ids idr and return associated ipc object .
*
* Call inside the RCU critical section .
* The ipc object is * not * locked on exit .
*/
2015-07-01 00:58:42 +03:00
struct kern_ipc_perm * ipc_obtain_object_idr ( struct ipc_ids * ids , int id )
2013-05-01 06:15:19 +04:00
{
struct kern_ipc_perm * out ;
2018-08-22 08:02:00 +03:00
int idx = ipcid_to_idx ( id ) ;
2013-05-01 06:15:19 +04:00
2018-08-22 08:02:00 +03:00
out = idr_find ( & ids - > ipcs_idr , idx ) ;
2013-05-01 06:15:19 +04:00
if ( ! out )
return ERR_PTR ( - EINVAL ) ;
return out ;
}
/**
* ipc_obtain_object_check
* @ ids : ipc identifier set
* @ id : ipc id to look for
*
2018-08-22 08:01:37 +03:00
* Similar to ipc_obtain_object_idr ( ) but also checks the ipc object
* sequence number .
2013-05-01 06:15:19 +04:00
*
* Call inside the RCU critical section .
* The ipc object is * not * locked on exit .
*/
struct kern_ipc_perm * ipc_obtain_object_check ( struct ipc_ids * ids , int id )
{
2015-07-01 00:58:42 +03:00
struct kern_ipc_perm * out = ipc_obtain_object_idr ( ids , id ) ;
2013-05-01 06:15:19 +04:00
if ( IS_ERR ( out ) )
goto out ;
if ( ipc_checkid ( out , id ) )
2015-07-01 00:58:48 +03:00
return ERR_PTR ( - EINVAL ) ;
2013-05-01 06:15:19 +04:00
out :
2005-04-17 02:20:36 +04:00
return out ;
}
2008-02-08 15:18:54 +03:00
/**
* ipcget - Common sys_ * get ( ) code
2014-09-08 20:27:23 +04:00
* @ ns : namespace
2014-01-28 05:07:05 +04:00
* @ ids : ipc identifier set
* @ ops : operations to be called on ipc object creation , permission checks
* and further checks
* @ params : the parameters needed by the previous operations .
2008-02-08 15:18:54 +03:00
*
* Common routine called by sys_msgget ( ) , sys_semget ( ) and sys_shmget ( ) .
*/
int ipcget ( struct ipc_namespace * ns , struct ipc_ids * ids ,
2014-06-07 01:37:36 +04:00
const struct ipc_ops * ops , struct ipc_params * params )
2008-02-08 15:18:54 +03:00
{
if ( params - > key = = IPC_PRIVATE )
return ipcget_new ( ns , ids , ops , params ) ;
else
return ipcget_public ( ns , ids , ops , params ) ;
}
2008-04-29 12:00:51 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_update_perm - update the permissions of an ipc object
2008-04-29 12:00:51 +04:00
* @ in : the permission given as input .
* @ out : the permission of the ipc to set .
*/
2012-02-08 04:54:11 +04:00
int ipc_update_perm ( struct ipc64_perm * in , struct kern_ipc_perm * out )
2008-04-29 12:00:51 +04:00
{
2012-02-08 04:54:11 +04:00
kuid_t uid = make_kuid ( current_user_ns ( ) , in - > uid ) ;
kgid_t gid = make_kgid ( current_user_ns ( ) , in - > gid ) ;
if ( ! uid_valid ( uid ) | | ! gid_valid ( gid ) )
return - EINVAL ;
out - > uid = uid ;
out - > gid = gid ;
2008-04-29 12:00:51 +04:00
out - > mode = ( out - > mode & ~ S_IRWXUGO )
| ( in - > mode & S_IRWXUGO ) ;
2012-02-08 04:54:11 +04:00
return 0 ;
2008-04-29 12:00:51 +04:00
}
2008-04-29 12:00:54 +04:00
/**
2018-08-22 08:01:34 +03:00
* ipcctl_obtain_check - retrieve an ipc object and check permissions
2014-01-28 05:07:05 +04:00
* @ ns : ipc namespace
2008-04-29 12:00:54 +04:00
* @ ids : the table of ids where to look for the ipc
* @ id : the id of the ipc to retrieve
* @ cmd : the cmd to check
* @ perm : the permission to set
* @ extra_perm : one extra permission parameter used by msq
*
* This function does some common audit and permissions check for some IPC_XXX
* cmd and is called from semctl_down , shmctl_down and msgctl_down .
2017-03-30 23:11:36 +03:00
*
2018-08-22 08:01:34 +03:00
* It :
* - retrieves the ipc object with the given id in the given table .
2017-03-30 23:11:36 +03:00
* - performs some audit and permission check , depending on the given cmd
* - returns a pointer to the ipc object or otherwise , the corresponding
* error .
2013-07-09 03:01:12 +04:00
*
2013-09-12 01:26:24 +04:00
* Call holding the both the rwsem and the rcu read lock .
2008-04-29 12:00:54 +04:00
*/
2018-08-22 08:01:34 +03:00
struct kern_ipc_perm * ipcctl_obtain_check ( struct ipc_namespace * ns ,
2013-09-12 01:26:17 +04:00
struct ipc_ids * ids , int id , int cmd ,
struct ipc64_perm * perm , int extra_perm )
2013-05-01 06:15:24 +04:00
{
2012-02-08 04:54:11 +04:00
kuid_t euid ;
2013-05-01 06:15:24 +04:00
int err = - EPERM ;
struct kern_ipc_perm * ipcp ;
2008-04-29 12:00:54 +04:00
2013-05-01 06:15:24 +04:00
ipcp = ipc_obtain_object_check ( ids , id ) ;
2008-04-29 12:00:54 +04:00
if ( IS_ERR ( ipcp ) ) {
err = PTR_ERR ( ipcp ) ;
2013-07-09 03:01:12 +04:00
goto err ;
2008-04-29 12:00:54 +04:00
}
2008-12-10 11:40:06 +03:00
audit_ipc_obj ( ipcp ) ;
2008-12-10 11:47:15 +03:00
if ( cmd = = IPC_SET )
audit_ipc_set_perm ( extra_perm , perm - > uid ,
2013-05-01 06:15:24 +04:00
perm - > gid , perm - > mode ) ;
2008-11-14 02:39:06 +03:00
euid = current_euid ( ) ;
2012-02-08 04:54:11 +04:00
if ( uid_eq ( euid , ipcp - > cuid ) | | uid_eq ( euid , ipcp - > uid ) | |
2011-03-24 02:43:24 +03:00
ns_capable ( ns - > user_ns , CAP_SYS_ADMIN ) )
2013-07-09 03:01:12 +04:00
return ipcp ; /* successful lookup */
err :
2008-04-29 12:00:54 +04:00
return ERR_PTR ( err ) ;
}
2012-07-31 01:42:46 +04:00
# ifdef CONFIG_ARCH_WANT_IPC_PARSE_VERSION
2005-04-17 02:20:36 +04:00
/**
2014-01-28 05:07:05 +04:00
* ipc_parse_version - ipc call version
* @ cmd : pointer to command
2005-04-17 02:20:36 +04:00
*
2014-01-28 05:07:05 +04:00
* Return IPC_64 for new style IPC and IPC_OLD for old style IPC .
* The @ cmd value is turned from an encoding command and version into
* just the command code .
2005-04-17 02:20:36 +04:00
*/
2014-01-28 05:07:04 +04:00
int ipc_parse_version ( int * cmd )
2005-04-17 02:20:36 +04:00
{
if ( * cmd & IPC_64 ) {
* cmd ^ = IPC_64 ;
return IPC_64 ;
} else {
return IPC_OLD ;
}
}
2012-07-31 01:42:46 +04:00
# endif /* CONFIG_ARCH_WANT_IPC_PARSE_VERSION */
2005-09-07 02:17:09 +04:00
# ifdef CONFIG_PROC_FS
2007-02-12 11:52:10 +03:00
struct ipc_proc_iter {
struct ipc_namespace * ns ;
2018-03-23 08:22:05 +03:00
struct pid_namespace * pid_ns ;
2007-02-12 11:52:10 +03:00
struct ipc_proc_iface * iface ;
} ;
2018-03-23 08:22:05 +03:00
struct pid_namespace * ipc_seq_pid_ns ( struct seq_file * s )
{
struct ipc_proc_iter * iter = s - > private ;
return iter - > pid_ns ;
}
2007-10-19 10:40:48 +04:00
/*
* This routine locks the ipc structure found at least at position pos .
*/
2008-02-06 12:36:28 +03:00
static struct kern_ipc_perm * sysvipc_find_ipc ( struct ipc_ids * ids , loff_t pos ,
loff_t * new_pos )
2005-09-07 02:17:09 +04:00
{
2021-09-08 06:00:53 +03:00
struct kern_ipc_perm * ipc = NULL ;
int max_idx = ipc_get_maxidx ( ids ) ;
2005-09-07 02:17:09 +04:00
2021-09-08 06:00:53 +03:00
if ( max_idx = = - 1 | | pos > max_idx )
2020-05-14 03:50:48 +03:00
goto out ;
2005-09-07 02:17:09 +04:00
2021-09-08 06:00:53 +03:00
for ( ; pos < = max_idx ; pos + + ) {
2007-10-19 10:40:48 +04:00
ipc = idr_find ( & ids - > ipcs_idr , pos ) ;
if ( ipc ! = NULL ) {
2013-09-12 01:26:29 +04:00
rcu_read_lock ( ) ;
ipc_lock_object ( ipc ) ;
2020-05-14 03:50:48 +03:00
break ;
2005-09-07 02:17:09 +04:00
}
}
2020-05-14 03:50:48 +03:00
out :
* new_pos = pos + 1 ;
return ipc ;
2005-09-07 02:17:09 +04:00
}
2007-10-19 10:40:48 +04:00
static void * sysvipc_proc_next ( struct seq_file * s , void * it , loff_t * pos )
{
struct ipc_proc_iter * iter = s - > private ;
struct ipc_proc_iface * iface = iter - > iface ;
struct kern_ipc_perm * ipc = it ;
/* If we had an ipc id locked before, unlock it */
if ( ipc & & ipc ! = SEQ_START_TOKEN )
ipc_unlock ( ipc ) ;
2008-02-08 15:18:57 +03:00
return sysvipc_find_ipc ( & iter - > ns - > ids [ iface - > ids ] , * pos , pos ) ;
2007-10-19 10:40:48 +04:00
}
2005-09-07 02:17:09 +04:00
/*
2007-10-19 10:40:53 +04:00
* File positions : pos 0 - > header , pos n - > ipc id = n - 1.
* SeqFile iterator : iterator value locked ipc pointer or SEQ_TOKEN_START .
2005-09-07 02:17:09 +04:00
*/
static void * sysvipc_proc_start ( struct seq_file * s , loff_t * pos )
{
2007-02-12 11:52:10 +03:00
struct ipc_proc_iter * iter = s - > private ;
struct ipc_proc_iface * iface = iter - > iface ;
2006-10-02 13:18:20 +04:00
struct ipc_ids * ids ;
2008-02-08 15:18:57 +03:00
ids = & iter - > ns - > ids [ iface - > ids ] ;
2005-09-07 02:17:09 +04:00
/*
* Take the lock - this will be released by the corresponding
* call to stop ( ) .
*/
2013-09-12 01:26:24 +04:00
down_read ( & ids - > rwsem ) ;
2005-09-07 02:17:09 +04:00
/* pos < 0 is invalid */
if ( * pos < 0 )
return NULL ;
/* pos == 0 means header */
if ( * pos = = 0 )
return SEQ_START_TOKEN ;
/* Find the (pos-1)th ipc */
2007-10-19 10:40:48 +04:00
return sysvipc_find_ipc ( ids , * pos - 1 , pos ) ;
2005-09-07 02:17:09 +04:00
}
static void sysvipc_proc_stop ( struct seq_file * s , void * it )
{
struct kern_ipc_perm * ipc = it ;
2007-02-12 11:52:10 +03:00
struct ipc_proc_iter * iter = s - > private ;
struct ipc_proc_iface * iface = iter - > iface ;
2006-10-02 13:18:20 +04:00
struct ipc_ids * ids ;
2005-09-07 02:17:09 +04:00
2007-10-19 10:40:53 +04:00
/* If we had a locked structure, release it */
2005-09-07 02:17:09 +04:00
if ( ipc & & ipc ! = SEQ_START_TOKEN )
ipc_unlock ( ipc ) ;
2008-02-08 15:18:57 +03:00
ids = & iter - > ns - > ids [ iface - > ids ] ;
2005-09-07 02:17:09 +04:00
/* Release the lock we took in start() */
2013-09-12 01:26:24 +04:00
up_read ( & ids - > rwsem ) ;
2005-09-07 02:17:09 +04:00
}
static int sysvipc_proc_show ( struct seq_file * s , void * it )
{
2007-02-12 11:52:10 +03:00
struct ipc_proc_iter * iter = s - > private ;
struct ipc_proc_iface * iface = iter - > iface ;
2005-09-07 02:17:09 +04:00
2015-04-16 02:17:54 +03:00
if ( it = = SEQ_START_TOKEN ) {
seq_puts ( s , iface - > header ) ;
return 0 ;
}
2005-09-07 02:17:09 +04:00
return iface - > show ( s , it ) ;
}
2009-09-23 03:43:43 +04:00
static const struct seq_operations sysvipc_proc_seqops = {
2005-09-07 02:17:09 +04:00
. start = sysvipc_proc_start ,
. stop = sysvipc_proc_stop ,
. next = sysvipc_proc_next ,
. show = sysvipc_proc_show ,
} ;
2007-02-12 11:52:10 +03:00
static int sysvipc_proc_open ( struct inode * inode , struct file * file )
{
struct ipc_proc_iter * iter ;
2014-10-14 02:54:14 +04:00
iter = __seq_open_private ( file , & sysvipc_proc_seqops , sizeof ( * iter ) ) ;
2007-02-12 11:52:10 +03:00
if ( ! iter )
2014-10-14 02:54:14 +04:00
return - ENOMEM ;
2007-02-12 11:52:10 +03:00
2022-01-22 09:14:23 +03:00
iter - > iface = pde_data ( inode ) ;
2007-02-12 11:52:10 +03:00
iter - > ns = get_ipc_ns ( current - > nsproxy - > ipc_ns ) ;
2018-03-23 08:22:05 +03:00
iter - > pid_ns = get_pid_ns ( task_active_pid_ns ( current ) ) ;
2014-10-14 02:54:14 +04:00
return 0 ;
2007-02-12 11:52:10 +03:00
}
static int sysvipc_proc_release ( struct inode * inode , struct file * file )
{
struct seq_file * seq = file - > private_data ;
struct ipc_proc_iter * iter = seq - > private ;
put_ipc_ns ( iter - > ns ) ;
2018-03-23 08:22:05 +03:00
put_pid_ns ( iter - > pid_ns ) ;
2007-02-12 11:52:10 +03:00
return seq_release_private ( inode , file ) ;
2005-09-07 02:17:09 +04:00
}
2020-02-04 04:37:17 +03:00
static const struct proc_ops sysvipc_proc_ops = {
proc: faster open/read/close with "permanent" files
Now that "struct proc_ops" exist we can start putting there stuff which
could not fly with VFS "struct file_operations"...
Most of fs/proc/inode.c file is dedicated to make open/read/.../close
reliable in the event of disappearing /proc entries which usually happens
if module is getting removed. Files like /proc/cpuinfo which never
disappear simply do not need such protection.
Save 2 atomic ops, 1 allocation, 1 free per open/read/close sequence for such
"permanent" files.
Enable "permanent" flag for
/proc/cpuinfo
/proc/kmsg
/proc/modules
/proc/slabinfo
/proc/stat
/proc/sysvipc/*
/proc/swaps
More will come once I figure out foolproof way to prevent out module
authors from marking their stuff "permanent" for performance reasons
when it is not.
This should help with scalability: benchmark is "read /proc/cpuinfo R times
by N threads scattered over the system".
N R t, s (before) t, s (after)
-----------------------------------------------------
64 4096 1.582458 1.530502 -3.2%
256 4096 6.371926 6.125168 -3.9%
1024 4096 25.64888 24.47528 -4.6%
Benchmark source:
#include <chrono>
#include <iostream>
#include <thread>
#include <vector>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
const int NR_CPUS = sysconf(_SC_NPROCESSORS_ONLN);
int N;
const char *filename;
int R;
int xxx = 0;
int glue(int n)
{
cpu_set_t m;
CPU_ZERO(&m);
CPU_SET(n, &m);
return sched_setaffinity(0, sizeof(cpu_set_t), &m);
}
void f(int n)
{
glue(n % NR_CPUS);
while (*(volatile int *)&xxx == 0) {
}
for (int i = 0; i < R; i++) {
int fd = open(filename, O_RDONLY);
char buf[4096];
ssize_t rv = read(fd, buf, sizeof(buf));
asm volatile ("" :: "g" (rv));
close(fd);
}
}
int main(int argc, char *argv[])
{
if (argc < 4) {
std::cerr << "usage: " << argv[0] << ' ' << "N /proc/filename R
";
return 1;
}
N = atoi(argv[1]);
filename = argv[2];
R = atoi(argv[3]);
for (int i = 0; i < NR_CPUS; i++) {
if (glue(i) == 0)
break;
}
std::vector<std::thread> T;
T.reserve(N);
for (int i = 0; i < N; i++) {
T.emplace_back(f, i);
}
auto t0 = std::chrono::system_clock::now();
{
*(volatile int *)&xxx = 1;
for (auto& t: T) {
t.join();
}
}
auto t1 = std::chrono::system_clock::now();
std::chrono::duration<double> dt = t1 - t0;
std::cout << dt.count() << '
';
return 0;
}
P.S.:
Explicit randomization marker is added because adding non-function pointer
will silently disable structure layout randomization.
[akpm@linux-foundation.org: coding style fixes]
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Joe Perches <joe@perches.com>
Link: http://lkml.kernel.org/r/20200222201539.GA22576@avx2
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-07 06:09:01 +03:00
. proc_flags = PROC_ENTRY_PERMANENT ,
2020-02-04 04:37:17 +03:00
. proc_open = sysvipc_proc_open ,
. proc_read = seq_read ,
. proc_lseek = seq_lseek ,
. proc_release = sysvipc_proc_release ,
2005-09-07 02:17:09 +04:00
} ;
# endif /* CONFIG_PROC_FS */