Bug 2226574

This issue may be caused by:
* kernel version definition is 64 bytes 
* driver version definition is 32 bytes
* in ioctl.c:
    * strlcpy(info.version, UTS_RELEASE, sizeof(info.version))  # this line will cutoff when the kernel version length is larger than 31 bytes/chars


As the default version string, it should be correct, not confused to users (in case some driver implementation will use the default kernel version not their own version format for intree driver)

Speaking in a "friend of the kernel" capacity...the width of the version string here is constrained by the pre-existing ethtool API, and the utility of duplicating information that can be obtained with uname is not sufficient to justify a RHEL-specific API extension. It would be better to consider some way to deprecate that feature of ethtool.

Hi @Ivan Vecera, 

Any comments for this issue from you?

As John mentioned... the problem is with ethtool's UAPI:

struct ethtool_drvinfo {
        __u32   cmd;
        char    driver[32];
        char    version[32];
...

Version cannot be longer than 32 chars... and we cannot extend this field as we would break UAPI.

As this ethtool_drvinfo struct definition is located in kernel source folder, who should be the correct contact for this fix, please help to involve here, thanks

(In reply to xijunli from comment #5)
> As this ethtool_drvinfo struct definition is located in kernel source
> folder, who should be the correct contact for this fix, please help to
> involve here, thanks

This cannot be fixed so easily... The existing UAPI has to be preserved. To provide wider string for version a new field has to be added in upstream and update ethtool userspace to handle it...

E.g.
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index f7fba0dc87e545..f1f8a3130a20aa 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -195,6 +195,7 @@ struct ethtool_drvinfo {
        __u32   testinfo_len;
        __u32   eedump_len;
        __u32   regdump_len;
+       char    version_long[64];
 };
 
However I'm not sure if upstream would like to extend this deprecated ioctl API this way.

John, what do you think?

Second possibility to read version for the driver:
1. Get driver (module) name
2. Fetch version of the loaded module

E.g.:
[root@cnb-06 ~]# DRV=$(ethtool -i enp2s0f0 | awk '/driver:/{ print $2 }')
[root@cnb-06 ~]# cat /sys/module/${DRV}/version
4.18.0-506.el8.x86_64

Right, it isn't about the technical challenge of changing things. I don't see upstream accepting such a change. The usefulness of driver-specific version information is at best unclear. A better solution would be some mechanism for a driver to publish something like feature or capability flags, and then some sort of standardization around an API to query and use such information. Perhaps something netlink based?

Yes, totally understand, 
And the original intention of raising this ticket is just to keep RHEL a unified response for all driver versions for customer usage, no confusion for some special cases

As it's not a functionality bug, So either "a longer fix period" or "even set with a known limitation/won't fix" works for me, just need a clear information for this ticket

If won't fix this, let me know, i will close this ticket, thanks

$ echo 'whatever the kernel version is' | wc -c
31
$ echo 'same as the kernel version' | wc -c
27
$ echo "same as what 'uname -r' says" | wc -c
29

Why not return one of these fixed strings? ;)


Seriously, unless the truncation can be shown to break some userspace software, I don't think it's worth fixing.

that's ok, i will close this ticket, and mark it with won't fix, thanks for support :)