With the introduction of zdev for device configuration in v1.33.0,
it used a hardcoded "/" to refer to the root-fs.
Dracut has its own mechanism to find the root file system and to walk its
device dependencies.
Mkdumprd also has its own mechanism to interpret the kdump target
and invokes dracut so that dracut only considers arguments from mkdumprd
without any root-fs dracut would default to [--no-hostonly-default-device].
Use the dracut mechanism to walk device dependencies and individually
have chzdev treat each leaf-node in the dependency tree.
See also https://github.com/dracutdevs/dracut commit
83e0dc7a3dca ("Add for_each_host_dev_and_slaves for device only checking").
This enables the use of dracut options such as --add-device or
--mount used in turn by mkdumprd.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This avoids exporting explicit settings if it's the default anyway.
I.e. avoid the last line in the example below:
$ chzdev --export - --active --type --all
[active zfcp-lun 0.0.1941:0x500507630904d...:0x4055408f00000000]
scsi_dev/queue_depth=32
Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@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 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>
Export and import the configurations with zdev:early on the
site-specific configurations as well. Filter the site-specific
configurations by attribute "zdev:early" and import the output
to the corresponding sites.
Note that --site parameter does not work with the device type.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add export and import support for site-specific settings. For each
site-specific configuration, a new site-block will be generated as
below. The same format can be interpreted by the import function and use
the values on the device's site-specific configuration.
Typical example of a site-block in the export file:
[site3 dasd-fba 0.0.f001]
online=1
cmb_enable=0
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Introduce --deconfigure-all feature, which will remove all available
settings from the mentioned device. A typical device can have 10
different site-specific settings, active settings, persistent
settings and sometimes auto-configured settings configured in it.
--deconfigure-all can be used to remove all of them with a single
command.
usage: chzdev -D <device-id>
chzdev --deconfigure-all <device-id>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
lszdev must be modified to share the site-specific configuration
information from the persistent settings. The persistent configuration
array will be read and tabularized based on the site-id input from the
user.
This patch also accommodates the site specific information in the
lszdev --info command. New information about the site-ids are integrated
with the command. For example,
DEVICE dasd-eckd 0.0.f001
Names : -
Modules : dasd_eckd_mod dasd_mod
Online : no
Exists : yes
Persistent : yes
Sites : 1,2
ATTRIBUTE ACTIVE PERSISTENT SITE1 SITE2
cmb_enable "0" "0" "1" -
eer_enabled "0" - - -
erplog "0" - - -
failfast "0" - - -
last_known_reservation_state "none" - - -
online "0" "1" "1" "1"
raw_track_access "0" - - -
readonly "0" - - -
reservation_policy "ignore" - - -
use_diag "0" - - -
Each available site specific configuration will be shown as column. The
"Sites" parameter in the above output indicates the available site
configurations and the SITE1 and SITE2 colums indicates the detailed
configuration for the respective sites.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Modify the dev_get_setting_list function to get the site-specific
attributes of the device. The new site_id parameter for this function
must be less than SITE_FALLBACK to read the site-specific attributes.
As SITE_FALLBACK setting is same as persistent setting, we do not need
a separate read function for it.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The udev-rules must be modified to make it site-specific. The site
specific part of the rule should be executed only on the sites where the
devices belong. Change the generic udev rule to support the site-specific
udev-rule.
During boot, the current site-id is read from the LOADPARM which is
located at /sys/firmware/ipl. The zdev_id command reads this LOADPARM
and prints the SITE_ID based on the value. This SITE_ID is the
current site where the udev-rule is executing. Based on this assumption,
the rule is divided in to multiple blocks where each site block is executed
only for the corresponding sites.
The rule executes based on the value read from the LOADPARM.
1. When the LOADPARM specifies a site-id and if the current device has
an associated configuration settings, it will be used.
2. When the LOADPARM specifies a site, and the current device does not
have any associated configuration set, the udev rule uses the
fallback configuration settings.
3. If the device does not have a fallback-configuration settings or any
site-specific settings, no configurations will be used.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The currently active site can be found from the loadparm attribute which
is located at /sys/firmware/ipl/loadparm. Read the value of loadparm and
extract the site_id.
The loadparm is an 8 byte alphanumerical IPL parameter. The content of
loadparm can be of different forms to indicate different boot menu
options, which are used by Linux for selecting the respective boot menu
entries. To indicate the site-id, loadparm adds a 'S' character. Where,
the following character after 'S' indicates either the site-id or
indivcation to derive the site-id from SSID.
For example,
If the loadparm value is Sn,'n' is the integer which could be one of the
valid site_ids from 0 to 9; i.e when booted on site-1, loadparm value will
be S1.
If loadparm value is "SS", zdev_id extracts the site_id from the SSID of
the current ipl device. For ccw and zfcp devices, the current ipl device-id
can be found at /sys/firmware/ipl/device.
In any case, if the loadparm contains invalid value, or empty, the
site_id will be default to the common-site.
After the first invocation of the zdev_id from udev-rule, the site-id
information is stored in /run/zdev_id.env file. This will reduce the
number of further invocation of zdev_id from within udev-rules.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently zdev supports the configuration and maintenance of one single
persistent device state. With the introduction of sites, zdev should be
able to store, configure and maintaine NUM_SITES number of states in
the persistent configuration. This patch modifies the struct device and
adds a new site_specific device_state array, which stores the
persistent configuration for all the available sites.
Total number of available sites are configured with NUM_SITES. Where,
10 site-specific configurations and 1 common configuration.
1. during read, all site data is always read and update the
site_specific[] array.
2. dev->persistent is a copy of dev->site_specific[global_site_id]
3. modifications are only done on dev->persistent, and during write
dev->persistent overlays dev->site_specific[global_site_id]
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In some high-availability setups, root and boot disks of a Linux
installation are copied to remote sites that can take over execution
of a Linux workload in case of an outage of the original site.
A site in this context is an execution environment such as an LPAR
or z/VM guest.
Each site may provide a different set of devices, or require different
parameters to be applied per device. chzdev supports site-specific
device configuration for up to 10 sites. Each site is identified by
a number in the range 0 to 9. You can provide a separate set of persistent
device configuration for each site. The IPL Load parameter value specified
during boot determines the currently active site. Only the device
configuration of the active site is applied during boot and when new
devices become available. A common configuration can be provided that is
applied when no site-specific configuration is available for a device in
the active site.
User can use the --site parameter to configure devices for a specific
site only. Configuration actions without a site parameter apply to the
common configuration.
During the boot, the active site configuration is chosed based on the
IPL LOADPARM variable. If the LOADPARM contains no valid site-id (0 to 9),
the fallback-site id will be used. The fallback-site-id can also be
configured with the zdev tools by not specifying the --site parameter.
Some of the new chzdev/lszdev commands with site-parameter can be as
follows
1. chzdev -ep f001 --site 3
This command is used to configure the device f001 for the site 3. During
boot, if the LOADPARM value is S3, this device configuration will be
used.
2. lszdev --site 3
This command lists all the devices which are configured for site 3.
3. chzdev -ep f001
Above command does not have a --site parameter. This device settings
will be used for the following conditions
1. When the loadparm specifies a site, (e.g S3), and the device does not
have an associated config-set, zdev uses fallback config set.
2. When the loadparm does not specify any site information, then the
fallback config set will be used.
When the loadparm specifies a site, and the device does not have an
associated config set, nor a fallback site, nothing is configured for this
device.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The dracut installation directory is referenced from `chreipl-fcp-mpath`,
`zdev`, and `zipl`; in each with its own individual definition and
variable name. This makes it unnecessarily hard to change it when
installing from the top level directory of s390-tools and passing
variable overwrites via the command line.
Fix this by defining a common `DRACUTDIR` variable in the shared
`common.mak` file, and referencing this in each tool as base directory.
With this a user can simply pass `DRACUTDIR=/foo/bar/baz` on the
commandline and change the installation for all three tools.
Further, also derive common `DRACUTCONFDIR` and `DRACUTMODDIR` variables
from `DRACUTDIR` in `common.mak`, so that `zdev` and `zipl` don't use
different variable names for the same directory anymore, and all these
are defined together in a common place.
Semantically nothing changes for a default build/installation.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
UDEVDIR is used in both `chreipl-fcp-mpath` and `zdev`, but with a
different meaning. In the former it points to the base udev directory,
not the rules directory; in the later it points to the rules directory.
If someone was to call `make` from the top level directory, and set
UDEVDIR for the whole build/installation, it would either break `zdev`
or `chreipl-fcp-mpath` (depending on what it was set to).
Fix this by pulling the definition of it in the shared `common.mak`
file, and giving it a common meaning. Point UDEVDIR to the base udev
directory, and UDEVRULESDIR to the rules directory below it.
Semantically nothing changes for a default build/installation.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The static analysis tool for Debian packages 'lintian', especially if called
like 'lintian -EvIL +pedantic', checks manual pages for correctness and typos.
This commit fixes typos that were identified by lintian and marked with
'typo-in-manual-page' while s390-tools version 2.20.0 was packaged.
Closes: https://github.com/ibm-s390-linux/s390-tools/pull/134
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Acked-by: Steffen Maier maier@linux.ibm.com [ziomon]
Acked-by: Ingo Franzki ifranzki@linux.ibm.com [zkey]
[hoeppner@linux.ibm.com: fix commit message]
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
chzdev fails to generate correct cio_ignore udev-rules for a CCW device
with device number 0xffff. Also chzdev aborts due to a segmentation
fault when a CCW device with CSSID 0xff is configured. Both issues are
caused by off-by-one errors while interpreting CCW device ID limits
CSSID_MAX, SSID_MAX and DEVNO_MAX.
Fix these errors by correctly interpreting CCW device ID limits.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently, a device type setting being --removed from both the active and
persistent configuration via 'chzdev -t' can result in a scenario where
the setting is not removed from the active configuration (and an error
message is presented) but chzdev still proceeds to remove the setting from
the persistent configuration.
Update this logic so that devtype_remove_settings behaves the same way as
device_remove_settings and only perform the removal when no errors are
encountered.
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zdev provides path resolution logic to determine which z-specific
devices contribute to the file system mounted at a specific mount point.
This logic is used by command-line option --by-path, but also to
determine the list of devices needed to enable the root file system.
Path resolution fails when a device provides multiple mount points such
as, for example, when using btrfs subvolumes, or when mounting the same
file system at multiple mount points. The failure is caused by zdev
relying on the MOUNTPOINT attribute of lsblk's output which only
contains a single mount point.
Fix this by making use of lsblk's MOUNTPOINTS attribute that contains
the full list of mount points. Note that MOUNTPOINTS was only introduced
with util-linux v2.37, therefore a fall-back to the old format is
needed.
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/129
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Eduard Shishkin <edward6@linux.ibm.com>
Reported-by: Dan Horák <dan@danny.cz>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since version 2.37.x, with the commit 58b510e58 ("libsmartcols: sanitize
variable names on export output"), util-linux changes the output
characters of lsblk, where the ":" is replaced with an "_". Align the
lsblk output parser function in lszdev as per this change.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
PCI and crypto devices defined using the IBM Z Dynamic Partition Manager
(DPM) will start in an offline/unconfigured state that requires manual
intervention before the associated Linux function can be used. This
results for example in PCI networking interfaces being unavailable in a
distribution installer system.
Fix this by providing a udev rule and initial RAM-disk logic that
automatically enables PCI and crypto devices either during boot, or when
they are defined at run-time. This processing can be suppressed by
specifying the "rd.zdev=no-auto" parameter on the kernel command line.
Auto-configuration is limited to Linux running in DPM LPARs because
PCI-functions and crypto devices defined by DPM are always intended for
use by a single LPAR only.
For Linux running in classic-mode LPARs or virtual machines, leaving PCI
and crypto devices in an offline state may be useful to allow defining a
device as available to multiple systems, where only the system that
intends to make use of the device should enable it.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add an internal tool intended to be used by udev rules to determine
zdev and hypervisor related system information in key=value format.
Supported keys are:
ZDEV_NEST_LEVEL=n
Virtualization nesting level of running system
ZDEV_HYPERVISOR_<n>=LPAR|z/VM|KVM/Linux
Type of hypervisor that provides virtualization at nesting level <n>
ZDEV_IS_DPM=0|1
Indicator if top-level LPAR is managed by Dynamic Partition Manager
ZDEV_NO_AUTO=0|1
Indicator if auto-configuration is requested
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Some Linux distributions always include a copy of all persistent device
configuration data when updating the initial RAM-disk. This makes
chzdev's persistent device configuration changes ineffective because
device configuration directives applied in the RAM-disk take precedence
over those stored in the root filesystem.
This patch introduces a new build-time switch which allows distributions
to specify that whenever there is a persistent device configuration
change, the RAM-disk is updated automatically.
This feature can be enabled by adding 'ZDEV_ALWAYS_UPDATE_INITRD=1' as
a zdev build option. Where, by default ZDEV_ALWAYS_UPDATE_INITRD is 0.
Co-developed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Provide information for the DASD device attribute 'fc_security'.
The help output for this attribute can be queried like this:
chzdev dasd --help-attribute
The lszdev tool can be used to display the current state of the FC
Endpoint Security information:
lszdev dasd -a -c TYPE,ID,ATTR:fc_security,ATTRPATH:fc_security
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This attribute is a no-op and never provided the described functionality.
It will be removed in the 5.7 kernel release with
commit 5f4019a80839 ("s390/qeth: remove fake_broadcast attribute").
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support to report Fibre Channel (FC) Endpoint Security
related information for zfcp-host and zfcp-lun devices.
Allow to query (lszdev) and provide help for (chzdev) the FC Endpoint
Security capability of a FCP device (zfcp-host). Provide this
information by defining the FCP device attribute fc_security in zdev
zfcp-host.
Allow to query (lszdev) and provide help for (chzdev) the FC Endpoint
Security in use on a connection between a FCP device and a FC remote
port. Provide this information by introducing a virtual zdev zfcp-lun
attribute fc_security. It returns the fc_security attribute value of
the zfcp port object representing the FC remote port used to access the
LUN.
This approach allows users of lszdev to easily query the FC Endpoint
Security in use on the connections to one or more FCP LUNs. It also
does not require the effort to introduce a zfcp-port device type in
zdev.
The fc_security attribute help for both zfcp-host and zfcp-lun can be
queried for example as follows:
chzdev zfcp --help-attribute
The fc_security attribute values and path of all active zfcp devices
can be queried for example as follows:
lszdev zfcp -a -c TYPE,ID,ATTR:fc_security,ATTRPATH:fc_security
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
As preparation for a following commit reorder the path logic in function
zfcp_lun_st_get_active_attrib_path(). This then allows to handle
subsequent special cases more easily. Additionally it also enhances the
readability of the expression.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support for defining read-only attributes in the chzdev/lszdev
tools. These attributes can be used to provide online documentation
for specific attributes via the --help-attribute and --list-attributes
tool functions.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Consolidate `ALIGN, __ALIGN_MASK, ARRAY_SIZE` macros and add them to
lib/zt_common.h. While at it, adapt coding style.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zdev incorrectly reports an invalid udev rule for zfcp-lun type rules.
This is caused by a faulty check for an empty udev rule file. This
commit fixes the check to only report invalid rules when there was no
valid configuration directive found in a zfcp-lun type udev rule.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reported-by: Steffen Maier <maier@linux.ibm.com>
Reported-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add basic checking when reading udev rules and print a warning when an
invalid udev rule file is found. This addresses the current inconsistent
behavior:
- CCW devices: invalid udev rules are considered valid
- CCW group devices: invalid udev rules are silently ignored
- zFCP LUNs: invalid rules cause chzdev/lszdev to silently terminate
with non-zero exit code
Checks include a test for empty or truncated rule files that might be
the result of an interrupted chzdev operation, or a file system or I/O
error.
Note: The recommended way to correct invalid udev rules is to either
remove the offending rules file, or to repeat the associated persistent
configuration step.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reported-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zfcp kernel module was changed to introduce separate parameters for
selecting DIF and DIF&DIX. This commit implements the corresponding
changes in chzdev and lszdev.
Signed-off-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The header exit_code.h is required for the exit_code_t type and
the header misc.h for the err_t type.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The function util_path_exists() consumes its first parameter as format
string. Passing the user input specified to the chzdev option --export
as-is to the function opens up the possibility for a format string
injection.
Fixes: d542138868 ("zdev: use libutil provided path functions")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since commit d542138868 ("zdev: use libutil provided path functions")
lszdev fails to correctly report most read-only sysfs attributes as such
in its detailed information output (options -i or -ii). This is because
the libutil function util_path_is_writable() is not equivalent to the
former function file_writable().
util_path_is_writable() always returns true (the underlying function
access() indicates the file is writable), if the path exists and the user
is root, regardless of the path's effective access permissions. This is
correct for most use cases, as root can effectively read/write any path
regardless of its effective access permissions). util_path_is_writable()
behaves exactly like Bash -w in this regard.
The former function file_writable() examined the file's access permissions
to check if one or more of user, group, and other have write permission.
For lszdev it is irrelevant whether a file is effectively writable by
the current user. Instead it needs to determine whether sysfs attributes
access permissions contain write access in any form. If not it lists
those sysfs attributes in a separate read-only section.
Use the new function util_path_is_readonly_file(), which does explicitly
check the file's effective read and write access permissions. It behaves
similar to the former function file_writable(), except that it does test
whether any of user, group, and other have read permission.
Fixes: d542138868 ("zdev: use libutil provided path functions")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For some device driver SysFS attributes, values read may not be
acceptable input values for that attribute.
An example would be the group of qeth VNICC attributes that return "n/a"
when VNICC setup is not supported, but only accept "0" and "1" as valid
values that can be written to it.
This leads to errors such as the following when data for such attributes
is imported:
# chzdev f500 --import test.conf
Importing configuration data from test.conf
QETH device 0.0.f500:0.0.f501:0.0.f502 configure failed
Error: Invalid value for qeth attribute: vnicc/flooding=n/a (*)
Acceptable values:
- Integers in the range 0 - 1
Use 'chzdev qeth --help-attribute vnicc/flooding' for more information
Note: You can use --force to override safety checks (*)
To fix this, change chzdev's --export function to skip any attribute
value that is not acceptable for that attribute.
Fixes: e831269e74 ("zdev: Add support for VNIC Characteristics")
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Make sure strings are copied correctly by using util_strlcpy().
Also, rename the NIC_{OWNER,NAME}_LEN definitions to *_SIZE to make it
more clear that the terminating null byte ('\0') is included in this
buffer size. Using *_LEN would mean only the number of characters in the
string fit in.
Furthermore, use these definitions rather than sizeof().
This fixes the following GCC8 compile warning:
nic.c: In function ‘nic_data_get’:
nic.c:58:2: warning: ‘strncpy’ specified bound 9 equals destination size
[-Wstringop-truncation]
strncpy(data.owner, argv[11], sizeof(data.owner));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nic.c:59:2: warning: ‘strncpy’ specified bound 9 equals destination size
[-Wstringop-truncation]
strncpy(data.name, argv[12], sizeof(data.name));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
