Bug 1764075
Summary: | [s390x] nsm_use_hostnames=1 shows 16777216 by `sysctl` in big-endian architectures | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Yongcheng Yang <yoyang> |
Component: | kernel | Assignee: | Alice Mitchell <ajmitchell> |
kernel sub component: | NFS | QA Contact: | Yongcheng Yang <yoyang> |
Status: | CLOSED WONTFIX | Docs Contact: | |
Severity: | low | ||
Priority: | low | CC: | ajmitchell, bcodding, smayhew, steved, swhiteho, thuth, xzhou |
Version: | 8.0 | Keywords: | Reopened, Reproducer, Triaged |
Target Milestone: | rc | ||
Target Release: | 8.6 | ||
Hardware: | s390x | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1355652 | Environment: | |
Last Closed: | 2022-05-03 07:27:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Yongcheng Yang
2019-10-22 08:25:48 UTC
As the parameter "Y" is correct (in file "/sys/module/lockd/parameters/nsm_use_hostnames") and only the `sysctl` get the messy value. Let's see if this is the sysctl tool's issue. (In reply to Yongcheng Yang from comment #0) ... > [root]# sysctl fs.nfs.nsm_use_hostnames > fs.nfs.nsm_use_hostnames = 16777216 <<<<<<<<<<<<<<<<< > [root@]# cat /sys/module/lockd/parameters/nsm_use_hostnames > Y > [root]# Some more tests shows `sysctl -w fs.nfs.nsm_use_hostnames=1` won't work as expected: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # sysctl -w fs.nfs.nsm_use_hostnames=0 fs.nfs.nsm_use_hostnames = 0 # cat /sys/module/lockd/parameters/nsm_use_hostnames N # sysctl -w fs.nfs.nsm_use_hostnames=1 fs.nfs.nsm_use_hostnames = 1 <<<< # cat /sys/module/lockd/parameters/nsm_use_hostnames N <<<< # sysctl -w fs.nfs.nsm_use_hostnames=16777216 fs.nfs.nsm_use_hostnames = 16777216 # cat /sys/module/lockd/parameters/nsm_use_hostnames Y I'm changing this back to kernel NFS again, apologize. Just find an upstream patch but it has not been accepted yet: https://patchwork.kernel.org/patch/9475657/ However, it suggests the culprit is in fs/lockd/svc.c ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 582 { 583 .procname = "nsm_use_hostnames", 584 .data = &nsm_use_hostnames, 585 .maxlen = sizeof(int), 586 .mode = 0644, 587 .proc_handler = proc_dointvec, <<<< 588 }, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Not a config file issue as this is a sysctl kernel parameter, but it looks to me that the error is that nsm_use_hostnames is defined as a type bool, which afaics is never done for sysctl parameters, they are all int type. which leads to the buffer overruns as the size field is set to that of an int not a bool. previous patch would not have been accepted as there is no proc_dobool() and no sysctl parameters are declared bool afaics. I expect the following patch will fix the issue :- --- fs/lockd/mon.c.orig 2020-03-12 12:32:16.614585321 +0000 +++ fs/lockd/mon.c 2020-03-12 12:32:19.968611359 +0000 @@ -58,7 +58,7 @@ * Local NSM state */ u32 __read_mostly nsm_local_state; -bool __read_mostly nsm_use_hostnames; +int __read_mostly nsm_use_hostnames; static inline struct sockaddr *nsm_addr(const struct nsm_handle *nsm) { After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. The patches for this problem have finally been accepted upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2071573d6346819cc4e5787b4206f2184985160 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d02a3a2cb25d384005a6e3446a445013342024b7 I think we can now fix this in downstream, too. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |