Since coreutils v9.1 commit 8f31074cb ("chown: warn about USER.GROUP")
chown utility now warns about using of wrong separator for USER and
GROUP options. This leads to warnings during intall step in ziomon:
$ make install
INSTALL ziomon
SED ziomon/install
chown: warning: '.' should be ':': ‘root.root’
SED ziomon/install
chown: warning: '.' should be ':': ‘root.root’
SED ziomon/install
chown: warning: '.' should be ':': ‘root.root’
To fix those warnings use ':' as separator instead of '.'. With this
patch applied those warnings are no longer present.
Signed-off-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
As on space problems the packing may fail, incomplete tgz are send.
Today no evidence for this is in dbginfo.log, packed upfront into the tgz.
This update helps to identify space related corruption of tgz files.
Reviewed-by: Mario Held <mario.held@de.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
When the kernel is build with CONFIG_NVME_MULTIPATH enabled and an NVMe
where the driver exposes its controller separately is used, chreipl node
on a mount point of the NVMe fails. The failure occurs because chreipl
tries to get the function_id from the NVMe's nvmeXnY block device via
the path '/sys/block/nvmeXnY/device/device/function_id' which does not
exist.
The underlying problem is that with NVMe multipath support the PCI
function is not associated directly with a particular NVMe namespace but
instead with the entire NVMe device which may host multiple NVMe
namespaces. The correct way to get from the block device to the
underlying PCI device and its function ID is then to extract the device
name i.e. the 'nvmeX' part from 'nvmeXnY' and use that to get the
function ID via '/sys/class/nvme/nvme<X>/device/function_id'.
Fixes: 0472b5ea5c ("ipl-tools: Add nvme device support to lsreipl/chreipl")
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
xxd has vim-common as a dependency. We can avoid that by using od
instead which is from coreutils.
While at it, add the require_command function from the
pvattest-info script to the pvextract-hdr script and use it.
Suggested-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Fix issue in the lszdev command where column names if using the --pairs
command line switch can contain characters that are not allowed to be
used as variable names in a shell environment.
Replace bad characters in column names by an underscore if the --shell
command line switch is specified along with the --pairs switch.
The additional --shell switch mimics what is already available in the
lsblk command and thus it shall be used along with the --pairs switch.
Signed-off-by: Daniel S. Haischt <modean@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The proc_sum_t struct is defined with the packed attribute and
produces the following compile warning:
mon_procd.c: In function ‘read_cpu’:
mon_procd.c:351:27: warning: taking address of packed member of ‘struct proc_sum_t’ may result in an unaligned pointer value [-Waddress-of-packed-member]
351 | cal_cpu(&cpudata, &proc_sum.cpu);
| ^~~~~~~~~~~~~
Silence the warning with -Wno-address-of-packed-member compile flag
since the struct is required to be as is.
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The struct scsi_dump_sb is defined with the __packed attribute and
produces the following compile warning in zfcpdump:
zfcpdump_part.c: In function ‘csum_update’:
zfcpdump_part.c:125:41: warning: taking address of packed member of ‘struct scsi_dump_sb’ may result in an unaligned pointer value [-Waddress-of-packed-member]
125 | dump_sb.csum_size, &dump_sb.csum)) {
| ^~~~~~~~~~~~~
However, all members are of the same size and the __packed attribute is
unnecessary. Remove the attribute to get rid of the warning.
Add assertion to ensure correct size of the struct during compile time.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The 'unistd.h' header was missing. Under some circumstances the
-D_GNU_SOURCE gcc flag does not trigger including that file.
Therefore, explicitly include this file here.
Fixes: e1aec24e84 ("libutil: introduce util_lockfile")
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
mdevctl has been updated to use /usr/lib/mdevctl/scripts.d/callouts/
instead of /etc/mdevctl.d/scripts.d/callouts/. The /etc location
is considered deprecated, meaning mdevctl will also look at that
location for now but might eventually stop looking in /etc for
callout scripts.
Based on that, update the installation location for the ap-check
callout. However, because older versions of mdevctl will still
only look in /etc, let's also put a wrapper script in /etc for now
to provide backward compatibility, and plan to remove it at a
later time.
Link: df6bb57429
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/139
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Commit ae7217806b ("common.mak: remove `LINK` and `LINKXX`") changed
the LINK and LINKXX definition to ensure that the same compiler is used
for compilation and linking when specified with CC= (or CXX=
respectively) on the commandline.
However, the commit also removed the pretty print for both commands. Add
the pretty print back in and use the already defined $(CC) and $(CXX)
variables to preserve the original change.
Fixes: ae7217806b ("common.mak: remove `LINK` and `LINKXX`")
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Check the dump provided sizes for reasonableness. This avoids that a
corrupted dump leads to allocation of large buffers on the heap.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Verify that the size is large enough before doing the mmap. Otherwise
this can result in a SIGBUS signal if there is an attempt to access a
page that lies beyond the end of the mapped file (see `man 2 mmap`).
Fixes: 8fa1b5a00b ("zdump: dfi: add support to read Protected Virtualization dumps")
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Corrupted dumps might have invalid page states. Therefore, let's convert
the assertions into errors.
Fixes: 8fa1b5a00b ("zdump: dfi: add support to read Protected Virtualization dumps")
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Make zipl tool prepare ECKD DASD for booting by different IPL
programs (with the same boot record installed).
Besides standard CCW-type IPL, user gets an ability to trigger
(with the same boot record installed!) List-Directed IPL. This
allows to use the feature of secure boot from ECKD DASD (which
is not available for CCW-type IPL).
When using the old boot interfaces, the usual CCW-type IPL is
triggered for DASD. Also for compatibility reasons zipl(8) tool
is modified to create and install one, or two "similar" program
tables per boot partition, depending on job and disk type. The
"similar" program tables differ only in block pointers format.
The old IPL programs (CCW-type IPL) use program table based on the
old format.
All program tables are packed to the same bootmap file. Their
order and logical offsets in the file are not significant (not
used by anyone).
The picture below shows which program table is used for IPL of
specified type from disk of specified type. Here "0" and "1" are
identifiers of program tables based on the old and new block
pointers format respectively. E.g. program table "0" is used for
CCW-type IPL from ECKD DASD. LD-IPL from DASD FBA is unsupported
(respectively, only one program table "0" is used), etc.
CCW-IPL LD-IPL
SCSI X 0
DASD FBA 0 X
ECKD DASD LDL 0 X
ECKD DASD CDL 0 1
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add an option to tunedasd to trigger a copy pair swap using the appropriate
ioctl for DASD devices.
-s, --copy-pair-swap COPY_PAIR
This command requires a comma separated pair of primary,secondary to be
specified. In case of success the old secondary will become the new primary
device and the old primary will become a secondary device.
Example:
tunedasd /dev/dasda -s 0.0.9700,0.0.9740
This will set the old secondary device 0.0.9740 as the new primary.
The old primary device 0.0.9700 will automatically become a secondary
device.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case of an error the ioctl macro only returns errno to the calling
function.
This misses positive returncodes from ioctls.
Change the macro to also return positive return codes.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The DASD device driver has a new attribute copy_pair to make storage
server copy pairs known to the driver.
Add this attribute to zdev.
Usage example:
Add two copy pairs 1000,2000 and 1000,3000 to a DASD device 1000
$ chzdev dasd 1000 copy_pairs=1000,2000 copy_pairs=1000,3000
or
$ chzdev dasd 1000 copy_pairs="1000,2000 1000,3000"
To add a third copy pair later on:
$ chzdev dasd 1000 copy_pairs=1000,4000
To remove all copy pairs from the device 1000:
$ chzdev dasd 1000 -r copy_pairs
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add an option -P|--copy-pairs to show all DASD devices with copy
relations set up in the system and their roles.
The output looks like:
# ./s390-tools/zconf/lsdasd -h
[...]
-P|--copy-pairs
Print information about copy pairs.
# ./s390-tools/zconf/lsdasd -P
Bus-ID Role Name Paired devices
================================================================================
0.0.9700 primary dasdd 0.0.9740,0.0.9743,0.0.9744,0.0.9745
0.0.9740 secondary 0.0.9700
0.0.9701 primary dasdf 0.0.9741
0.0.9741 secondary 0.0.9701
0.0.9702 primary dasdh 0.0.9742
0.0.9742 secondary 0.0.9702
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Adds util_lockfile_example.c, which can be used to sample
util_lockfile support.
To acquire a lock using a parent PID (e.g. your shell instance):
util_lockfile_exmample -f <path> -l <retries>
To release the lock using the parent PID:
util_lockfile_example -f <path> -r
To acquire the lock, sleep briefly, and then release the lock
using the PID of the util_lockfile_example process:
util_lockfile_example -f <path> -L <retries>
In each example, the <path> is the location of the desired lockfile
and <retries> is the number of times to retry acquiring the lock
if it fails.
GitHub-ID: https://github.com/ibm-s390-linux/s390-tools/issues/142
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Implement simple file-locking routines that use process PIDs for stale
lock detection. The implementation is meant to be a simplified subset of
what liblockfile was previously being used for by libap, allowing the
external dependency to be removed.
This initial implementation provides a series of functions that allow for
creating/release file locks using either the current process PID or the
PID of the current process parent. When creating a file lock, first a
temporary file is created and the appropriate PID (either this process
PID or the parent process PID) is placed in the file to specify the owner
of the lock. Then an attempt is made to link that file to the desired
file location; if this succeeds, the lock is now held on behalf of the
specified PID. If it fails, this implies the file already exists
(meaning the lock is already held). In this case, stale lock detection
is performed by reading the PID from the file and ensuring that the
associated process still exists -- if it does not, then the lock is
presumed stale and destroyed. If the process still exists, then either
the lock request fails or the caller will sleep and retry, depending on
an optional retry setting.
A lock remains valid until either 1) it is released via the corresponding
util_lockfile function, which will delete the corresponding file 2) the
associated PID no longer exists, which leaves the file in-place but will
cause it to be destroyed the next time a different process attempts to
lock that file or 3) the file is directly removed (e.g. rm).
A typical usecase for such support would be to provide a means for
multiple invocations of the same (or different) tools to ensure that they
do not access the same shared resource simultaneously. For example,
ap-check, chzdev and lszdev all have a need to view and/or modify the AP
and vfio-ap configuration files; util_lockfile can be used to ensure that
only one instance of any of these utilities do that at a time by ensuring
they all use the same lockfile.
Additionally, providing the ability to specify the parent PID rather than
the current PID allows for a general purpose tool (like mdevctl) to
invoke a sub-program (ap-check) to acquire and release a lockfile as
necssary while allowing stale lock detection to be controlled by that
parent PID, allowing the lock to remain held over multiple sub-program
invocations.
Note that this implementation is sufficient for our current usage (e.g.
lockfiles placed in tmpfs) but does not take into consideration things
like NFS, which a more complete lockfile solution like liblockfile does.
GitHub-ID: https://github.com/ibm-s390-linux/s390-tools/issues/142
Suggested-by: Luca BRUNO <luca.bruno@coreos.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Set up the secure_boot_supported global variable at the
function bootmap_create() instead of bootmap_create_device()
to make sure that the secure boot status is checked for all
relevant jobs.
Fixes: 7b369318dd ("zipl: check for secure boot once")
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Sometimes dumping a virtual machine from the outside is the only way to
get the data that is needed. This can be the case if a dumping mechanism
like kdump hasn't been configured or data needs to be fetched at a
specific point. Dumping a protected guest from the outside without help
from FW/HW doesn't yield sufficient data to be useful. Hence we have
introduced Protected Virtualization (PV) dump support - also named
confidential dump support.
The confidential dump support works by integrating the firmware into the
dump process. New Ultravisor calls (UVC) are used to initiate the dump
process, dump CPU data, dump memory state and lastly complete the dump
process. The guest's data is fully encrypted and can only be decrypted
by the entity that owns the customer communication key (CCK) for the
dumped guest. The output format is very similar the normal s390 vmcore
ELF format, it's only enriched by new sections where the returned data
from the UVC "Complete Configuration Dump" and the UVC "Dump
Configuration Storage State" is stored. The encrypted CPU data is stored
in a new note type `NT_S390_PV_CPU_DATA`. The old note types do still
exists but without any confidential data stored. The memory data is
stored in the LOAD segment as usual but for PV dumps it's fully AES-XTS
encrypted.
This commit adds support for reading/decrypting PV guest dumps to
zgetdump by introducing a new DFI input module (`dfi_pv_elf.c`). For
specifying the customer communication key a new command line option
`--key` is added.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The functionalities of libpv are used in the next patch. Libpv itself
requires glib2 and libcrypto.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Consolidate error reporting to make sure that error messages are used
consistently. In addition, don't call `zg_exit()` directly, but instead
return the value 1 in `main()`.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Acked-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Prevent double free/close that happens in get_multipath_status()
when the output of "dmsetup status XXX" is empty
Fixes: 599b141 ("zipl: Rewrite helper script in C")
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Adapt the wrappers `zg_alloc`, `zg_realloc` and `zg_ioctl` to match the
signatures used by `calloc`, `realloc` and `ioctl`.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
lshwc displays counter values extracted from the /dev/hwctr device.
The counter values are retrieved using a loop and incremented instead
of just displayed on output.
This leads to the situation where a counter is incremented in large
numbers while the counter triggering program is active. When this
program terminates, the counter should not increase but remain steady.
This is not the case as this example shows:
# lshwc -i 2 -l90 -a :a | fgrep Total | \
awk -F ',' '{print $2 "," $152 "," $157}'
Report time and values of DFLT_ACCESS and DFLT_CC counters
sleep 10
# DFLTCC=1 python3 -c "import zlib; zlib.compress(b'A'*6000000000);
Increment counter DFLT_ACCESS and DFLT_CC, runs about 45 seconds
Output before:
15:24:20,0,0
15:24:22,0,0
15:24:24,0,0
15:24:26,0,0
15:24:28,0,0
15:24:30,0,0
15:24:32,2067027,592996481 <--- python3 program start
15:24:34,6953101,2039012580
15:24:36,14494585,4264340060
15:24:38,24759568,7346128396
....
15:24:56,232929262,70526362509
15:24:58,269037963,81464038124
15:25:00,307757248,93171809261
15:25:02,348900718,105620730492
15:25:04,392646075,118841031269 <--- python3 program stop
15:25:06,438956016,132853968029 <-- Value column two increased by 49148217
15:25:08,488104233,147709011658 <-- Similar high increase
The reason is that lshwc takes the last read counter value and keeps
adding it to the total count, even if there zero delta to the previous
read value. Fix this by clearing the total count value between ioctl()
read operations.
Output after:
15:39:26,0,0
15:39:28,0,0
15:39:30,0,0
15:39:32,0,0
15:39:34,0,0
15:39:36,1367250,380721127 <--- python3 program start
15:39:38,4104791,1108181711
15:39:40,6740994,1858843730
15:39:42,9277545,2646351211
15:39:44,11895180,3444375804
....
15:40:16,54060774,16315924126
15:40:18,57830349,17513712210
15:40:20,61628170,18690791102
15:40:22,65410470,19864086006
15:40:24,69070765,21028646754 <--- python3 program stop
15:40:26,70429758,21472772340 <-- No increase of value in column two
15:40:28,70429758,21472772340
15:40:30,70429758,21472772340
15:40:32,70429758,21472772340
15:40:34,70429758,21472772340
15:40:36,70429758,21472772340
15:40:38,70429758,21472772340
Fixes: 27a562da0a ("cpumf/lshwc: Program to extract complete counter sets")
Reported-by: Axel Busch <Axel.Busch@ibm.com>
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
pai dumps core when invoked with summary flag -S and
certain painnpa.XXXXX data files:
# ~/s390-tools/cpumf/pai -r -S
Segmentation fault (core dumped)
#
Fix this and check the existence of event raw data before
reading it. This avoid accessing NULL pointer trying to read raw
data when no counter values have been appended as raw data by the
kernel.
Fixes: dc73c77d73 ("cpumf/pai: Omit detailed event information when summary flag selected")
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
