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>
When realloc() fails to allocate memory it returns NULL and the original
block is left untouched. In that case return the potentially larger
original block.
Found using Cppcheck:
[zdev/src/misc.c:1106]: (error) Memory leak: name
Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
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>
The modified flag was actually never copied during merge of setting lists.
Copy the modified flag if requested.
Found using Cppcheck:
[zdev/src/setting.c:553]: (warning) Redundant assignment of 'n->modified' to itself.
Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
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>
Unfortunately zdev hook already exists in Ubuntu, from an unrelated
project. ZFS uses zdev/zpool names, and ships a zdev hook to do ZFS
specific initialisation. It is available on s390x and thus results in
file-conflict upon installing both. Thus renaming this zdev hook to
s390-tools-zdev.
Closes: https://github.com/ibm-s390-tools/s390-tools/pull/41
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This patch fixes false positives when attributes are checked for
conflicts between BridgePort and VNICC.
Signed-off-by: Hans Wippel <hwippel@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
mk-pxelinux-ramfs, mod_fsstatd|procd.service, zfcpdump all use
/sbin/modprobe path. Adjust zdev to use that path as well. This works
universally on both usr-merge systems (e.g. Debian/Ubuntu with
usrmerge package installed), and split-usr systems alike
(Debian/Ubuntu current stable releases default).
Closes: #31
Link: https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1777600
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Changing the cmb_enable attribute of a CCW device can cause a blocked
chzdev process or udev rule. This problem occurs when the device is
offline, cmb_enable is 0, and chzdev is used to set cmb_enable=1 and
online=1 at the same time.
The following call will block:
chzdev 190d -a cmb_enable=1 online=1
The following call will generate a udev rule that will block subsequent
calls to 'udevadm settle':
chzdev 190d -p online=1 cmb_enable=1
Fix this by ensuring that cmb_enable is only set when the CCW device
is not online.
Reported-by: André Wild <wild@linux.vnet.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Enable user to specify that a device should be configured early, that is
during the initial RAM-disk boot phase. This may be necessary, e.g. to
override auto-configuration for a device which is also applied during
that boot phase. It may also be used to manually specify devices that
are required to access the root file system, such as networking devices.
Users can mark devices as requiring early configuration by specifying
a value of 1 for the newly added internal attribute zdev:early:
# chzdev dasd-eckd 0.0.1234 -p zdev:early=1
This can be changed back by removing the attribute setting, or by
setting the attribute value to 0:
# chzdev dasd-eckd 0.0.1234 -p -r zdev:early
or
# chzdev dasd-eckd 0.0.1234 -p zdev:early=0
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This change adds base infrastructure for implementing internal device
attributes. In the context of the zdev tools, an internal device
attribute is a new type of device attribute with the following
characteristics:
- Can be set and removed like normal device attributes
- Affects zdev-internal handling only
- Does not correspond to an actual device attribute, that is
it has no representation in SysFS
- Can not be set in the active configuration
- Name starts with "zdev:" to prevent conflicts with actual
device attributes
Values for internal device attributes are stored in udev rules alongside
the normal persistent configuration of a device. They are encoded as
udev environment variables. Note that they have no further effect on
udev processing.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add initramfs-tools scripts that apply firmware-provided I/O
configuration data as auto-configuration during boot. This way, all I/O
devices configured by DPM are automatically brought online without
further user interaction.
This mechanism is active by default. It can be deactivated by specifying
the following parameter on the kernel command line:
rd.zdev=no-auto
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a dracut hook that applies firmware-provided I/O configuration data
as auto-configuration during boot. This way, all I/O devices configured
by DPM are automatically brought online without further user
interaction.
This mechanism is active by default. It can be deactivated by specifying
the following parameter on the kernel command line:
rd.zdev=no-auto
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Auto-configuration is the name of a new configuration target that is
supported by chzdev and lszdev besides the existing active and
persistent configuration targets. Directives created in this new
configuration are stored as udev rules in the /run/udev/rules.d
directory.
Auto-configuration directives are only in effect if there are no
directives for the same device in the user-provided persistent
configuration. This allows users to override auto-configuration
directives if necessary.
Due to the volatile nature of the /run directory, auto-configuration
directives are cleared on reboot. Therefore mechanisms that generate
auto-configuration directives must recreate them on every boot.
The lszdev tool displays auto-configuration data both in list view
as well as in detail view. Users can specify the new option --auto-conf
to only show data from this configuration target.
Mechanisms that generate automated configuration directives can use
chzdev together with the --auto-conf option to create the corresponding
udev rules.
Note: This change does not include a mechanism that generates
auto-configuration directives.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Change chzdev's udev rule generation from the previous approach of
combining all zfcp-lun udev rules associated with an FCP device into a
single file to storing zfcp-lun udev rules in one file per zfcp-lun.
This is done to enable per-device udev rule masking.
With udev rule masking, if a udev rule file by the same name exists in
both /etc and /run, the udev daemon will only consider the rules found
in /etc.
The auto-configuration feature will make use of per-device udev rule
masking to introduce a new class of configuration data (stored in /run)
that is only active if no user-provided configuration data (in /etc)
exists.
In addition, change chzdev to allow the regeneration of udev rules by
using the --force command line like in the following example:
# chzdev zfcp-lun --configured --enable --persistent --force
This can be used to convert all existing zfcp-lun udev rules from the
old format to the new one.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
There are some situations where running "udevadm settle" can result in
a deadlock, such as in the early stages of initial RAM-disk processing.
Introduce a new command-line option --no-settle that can be used to
suppress calling "udevadm settle" to allow chzdev to be run in such
situations.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support for reading firmware-provided I/O configuration data files.
Such configuration files are generated by the Dynamic Partition Manager
and made available via a kernel interface for consumption by Linux.
To read a firmware configuration file, use the existing --import option:
# chzdev --import /sys/firmware/sclp_sd/config/data
This will apply all I/O configuration data found in the specified file
to the persistent configuration.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Apply some changes to existing functions and data structures to simplify
the firmware configuration file support implementation.
- Make qeth and dasd subtype objects non-static
- Change the existing helper functions for reading file contents into
memory to also support binary functions
- Move some configuration file import functions to make them available
for use in other source files
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Running dracut when the root device is not known to zdev (for example
because it is located on a virtio block device) will cause the zdev
dracut module to incorrectly return an error in the installkernel()
function. As a result dracut aborts with an error.
Fix this by ensuring that the non-zero exit code resulting from lszdev
not being able to determine the root device is not passed on to the
calling function. Also remove unnecessary error output in this case
by leaving the install() function early when the root device is not
known to zdev.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
When a persistent device configuration is changed, chzdev tries to
find out if it needs to perform additional steps to make this change
persistent. If this check fails, for example because the root device
is located on a RAM-disk, or on a device type not managed by chzdev,
the tool reports an error and exits with non-zero exit code:
chzdev: Could not determine device that provides /
or
chzdev: Could not determine device that provides loop0
This behavior unnecessarily restricts chzdev from being used in
scripted environments like an installation initial RAM-disk.
Fix this by removing the non-zero exit code and moving the message to
verbose output mode only.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
The zdev tools use a hard-coded path to locate the vmcp binary. Since
this path may differ between distributions, the vmcp binary may not be
successfully located in all cases. Fix this by using the BINDIR macro
to determine the correct path. This macro is also used during
installation of the vmcp binary itself.
Reviewed-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This patch fixes a segfault in the qeth get_layer function that occurs
when an unknown attribute is used in combination with the force option.
Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This patch adds support for the qeth attributes that are used to
configure VNIC Characteristics.
VNIC Characteristics and BridgePort are mutually exclusive. Thus, this
patch also adds a check function for conflicting settings to the qeth
code. Also, the output when VNIC Characteristics is active is added to
the BridgePort attribute descriptions.
Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Currently, the qeth attributes that are used to configure IPv6 NDP proxy
are described as ARP proxy attributes. This patch changes the titles and
descriptions from ARP to NDP.
Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
During processing, the zdev-provided dracut module creates a temporary
file using the mktemp tool. Due to a missing path specification
in the filename template, mktemp tries to create the temporary file
in the current working directory which fails if that directory is not
writable:
# cd /sys
# dracut -Nf
mktemp: failed to create file via template 'dracut-zdev.XXXX': No such
file or directory
chzdev: Could not write to file : No such file or directory
sed: can't read : No such file or directory
chzdev: Could not open file : No such file or directory
Fix this by specifying option --tmpdir when calling mktemp.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
