chzdev ccwgroup qeth properties incorrect ordering with respect to online

[Dimitri John Ledkov]

For Canonical Openstack we are currently preseeding LPARs with bridge_role=primary setting.

This is achieved by setting the property with chzdeve e.g.:

$ chzdev --no-root-update -pVe c003 bridge_role=primary

On boot this sometimes results in generated udev rules failing to apply the bridge_role property:
systemd-udevd[2634]: error opening ATTR{/sys/devices/qeth/0.0.c003/bridge_role} for writing: Permission denied

The reason being, is that bridge_role attribute is attempted to written, before it exists, as the devices have not been onlined yet into a ccwgroup.

Updating zdev/src/qeth.c to use ordering after online and check for online only appears to resolve above race condition, for the property in question
 .order_cmp = ccw_online_only_order_cmp,
 .check = ccw_online_only_check,

However looking at that file, it would appear to me that most qeth properties should be ordered after online, as during boot they do not exist until after the qeth is onlined.

Please reverse proxy this bug report to IBM s390-tools engineering.

Regards,

Dimitri.

[Dimitri John Ledkov (xnox)]

Original bug report https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1618463

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-03-17 06:38 EDT-------
The qeth sysfs attributes can be devided into core-attributes, layer2-specific attributes, and layer3-specific attributes. core-attributes are available from the beginning of the qeth-device creation, and there is one very important attribute "layer2": layer2- or layer3-specific attributes are created, once the core-attribute "layer2" is defined to be either "0" (for layer3) or "1" (for layer2).

bridge_role is a layer2-specific attribute. Try to change your chzdev call to
chzdev --no-root-update -pVe c003 layer2=1 bridge_role=primary

[Dimitri John Ledkov (xnox)]

I do not see bridge_role file available until after the three devices in a group are online.
As in the file is not in sysfs when the qeth devices are offline (and have not yet been ever onlined yet aka absolutely fresh boot)

Why should I be specifying the layer2 attribute, if it is the default? That violates the DRY principle.

[Dimitri John Ledkov (xnox)]

Or specifically, shouldn't specifying bridge_role=primary; trigger generation of the layer2=1 attribute in the generated udev rules file?!

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-03-27 04:19 EDT-------
(In reply to comment #8)
> I do not see bridge_role file available until after the three devices in a
> group are online.
> As in the file is not in sysfs when the qeth devices are offline (and have
> not yet been ever onlined yet aka absolutely fresh boot)
>
> Why should I be specifying the layer2 attribute, if it is the default? That
> violates the DRY principle.
>
> Or specifically, shouldn't specifying bridge_role=primary; trigger
> generation of the layer2=1 attribute in the generated udev rules file?!

The qeth device driver registers the layer2-specific attributes either when the layer2 attribute is set, or when the device is set online and the driver determines that layer2=1 is the correct setting. This explains the original error reported in this bug report: the udev rule tried to write to the bridge_role attribute even though it did not yet exist, resulting in a "permission denied" error (because the directory is not writable).

This is the result of a somewhat incomplete design assumption - for z/VM guests, chzdev determines the layer2 setting based on Hypervisor information, so the sorting implemented by chzdev (bridge_role after layer2) works. It does not work however, when the value of the layer2-setting is left to the device driver, as in the LPAR case.

We cannot simply change the ordering of all layer2-specific attributes to "after online", because some of these (e.g. sniffer, hsuid) can only be set after layer2 was set and before online is set.

I think the idea you proposes in your latest comment sounds like a good approach: if a user specifies a layer2-specific attribute, and layer2 is not set, that is:
- not auto-detected by chzdev as under z/VM
- not set persistently by a previous invocation
- not set by this invocation,
then chzdev could generate layer=1 implicitly, and issue an informational message to indicate the same.

Additionally, if a layer2-specific attribute is set and the layer2-attribute is set to 0 (set persistently before, or specified during this invocation), chzdev should abort with an error.

We'll evaluate how this is best implemented in chzdev. In the mean-time, specifying layer=1 can be used as a work-around in such cases.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-05-24 10:52 EDT-------
We've implemented the change as described in the previous comment to fix this problem. This change will be published with the next s390-tools release.

[Frank Heimes (fheimes)]

Please can you leave a comment here once the new s390-tools package that incl. the change got released? Thx

[Dimitri John Ledkov (xnox)]

I think we close this ticket, as there will be a new ticket to upgrade to a new release of s390-tools.

Please note artful has feature freeze on 24th of August, it would be nice if the new s390-tools goes public well before that week. E.g. ~ august 10th.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-08-02 07:52 EDT-------
A new version of the s390-tools package containing a fix for this bug has been released. See:

https://www.ibm.com/developerworks/linux/linux390/s390-tools-1.38.0.html

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-08-02 08:16 EDT-------
IBM bugzilla Status -> closed . fix integrated with s390-tools 1.38.0