Don't use global CPU masks (like "online" or "present") to
calculate type specific number of threads due systems with
mixed CPU types.
It's also necessary to check all thread_siblings maps to get the
highest number, because some threads (CPUs) may be disables, for
example old lscpu calculates number of threads from the cpu0 and
if you disable cpu0's sibling (cpu4):
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2 <---
Core(s) per socket: 4
Socket(s): 1
# chcpu --disable 4
CPU 4 disabled
CPU(s): 8
On-line CPU(s) list: 0-3,5-7
Off-line CPU(s) list: 4
Thread(s) per core: 1 <--- !
Core(s) per socket: 4
Socket(s): 1
because 'thread_siblings' contains only one thread for cpu0:
# cat /sys/devices/system/cpu/cpu{0,1,2,3,4,5,6,7}/topology/thread_siblings_list
0
1,5
2,6
3,7
cat: /sys/devices/system/cpu/cpu4/topology/thread_siblings_list: No such file or directory
1,5
2,6
3,7
Signed-off-by: Karel Zak <kzak@redhat.com>
* move structs definitions to header file
* define set of /proc/cpuinfo parsing patterns for cpu-type and for
CPUs
Signed-off-by: Karel Zak <kzak@redhat.com>
The current lscpu assumes that all CPUs in the system are the same.
Unfortunately this is not true. We need to split all internal CPUs
descriptions to CPU-type and CPU.
This patch add lscpu-cputype.c where will be CPU-type description --
mostly based on /proc/cpuinfo.
Signed-off-by: Karel Zak <kzak@redhat.com>
When calling variadic functions, NULL must be explicitly cast to a
desired type.
This is noted in the exec(3) manpage.
The call in newgrp.c was changed for consistency.
Signed-off-by: Egor Chelak <egor.chelak@gmail.com>
Up on successful fdopendir(3) file descriptior that will be closed, that
happens in recursiveRemove() switch_root(8) function.
CID: 360697
Reference: https://pubs.opengroup.org/onlinepubs/9699919799/functions/fdopendir.html
Co-Author: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
If a call to chroot is not followed by a call to chdir("/") the chroot jail
confinement can be violated. See also CWE-243.
CID: 360718
CID: 360800
Reference: http://cwe.mitre.org/data/definitions/243.html
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Variable cap was 32 bits and shifting it by 64 bits resulted to the shift
going over a variable boundary.
CID: 360799
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Karel Zak <kzak@redhat.com>
In 9995da0 we added support to fstrim to be able to fall back to
`/proc/self/mountinfo` if `/etc/fstab` didn't exist, but we forgot
to remove the `/etc/fstab` condition from the timer. Let's remove
that condition from the timer so we can go back to periodically
running `fstrim.service`.
issue report:
if i run the heavy duty test from #16859 a couple of times I can get
the loopback layer in the kernel into a state where there's a loopback
block device allocated, that you can open, but where both LOOP_CLR_FD
and _SET_FD fail with EBUSY. and /dev/loop-control still returns it as
the next free one... weird state util-linux losetup when called to
allocate a new device then freezes
This commit:
* restrict number of attempts to 16
* use 200000ms sleep between attempts
* add note about non-atomic loop device setup to the man page
Reported-by: Lennart Poettering <lennart@poettering.net>
Signed-off-by: Karel Zak <kzak@redhat.com>
The library is not distributed and almost all code in this ar(1)
archive is Public Domain or LGPL ... but let's avoid any doubts and do
not mix non-GPL and GPL code there.
Addresses: https://github.com/karelzak/util-linux/issues/1157
Signed-off-by: Karel Zak <kzak@redhat.com>
Karel Zak
Sami Kerola
Egor Chelak
Dusty Mabe