RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1310691 - "--rdma" option of rpc.nfsd enables the wrong port
Summary: "--rdma" option of rpc.nfsd enables the wrong port
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nfs-utils
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Yongcheng Yang
URL:
Whiteboard:
Depends On: 1337599
Blocks: 1313501
TreeView+ depends on / blocked
 
Reported: 2016-02-22 14:23 UTC by Chuck Lever
Modified: 2016-11-04 05:03 UTC (History)
4 users (show)

Fixed In Version: nfs-utils-1.3.0-0.27.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1313501 (view as bug list)
Environment:
Last Closed: 2016-11-04 05:03:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2383 0 normal SHIPPED_LIVE nfs-utils bug fix and enhancement update 2016-11-03 13:53:02 UTC

Description Chuck Lever 2016-02-22 14:23:56 UTC 
Description of problem:
"man rpc.nfsd" says:

       -r  or  --rdma
              specify that NFS requests on the standard RDMA  port  ("nfsrdma",  port
              20049) should be honored.

Instead "rpc.nfsd --rdma" enables RDMA on a random port. To work around the problem, use

rpc.nfsd --rdma=20049"

Version-Release number of selected component (if applicable):
nfs-utils-1.3.0-0.21.el7_2.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. Add "--rdma" or "-R" to the rpc.nfsd options in /etc/sysconfig/nfs
2. Restart the nfs-server service
3. # cat /proc/fs/nfsd/portlist

Actual results:
On my system, the NFS/RDMA service was enabled on port 20814.

Expected results:
When the port is not specified, the NFS/RDMA service should be enabled on port 20049.

Additional info:
Failing code is in utils/nfsd/nfssvc.c:

int
nfssvc_set_rdmaport(const char *port)
{
        struct servent *sv = getservbyname(port, "tcp");

getservbyname(3) returns the wrong value (20418 in my case). (Tested with a stand-alone C program that just calls getservbyname(3) and prints the result). There is no entry specifying port 20418 in my /etc/services file.

The entries in /etc/services on this system have:

nfsrdma         20049/tcp               # Network File System (NFS) over RDMA
nfsrdma         20049/udp               # Network File System (NFS) over RDMA
nfsrdma         20049/sctp              # Network File System (NFS) over RDMA

This seems wrong to me: shouldn't it be:

nfs             20049/rdma

?

But if RDMA services are not allowed to be listed in /etc/services correctly, then perhaps getservbyname(3) shouldn't be used for this purpose. We already have the ability to specify the port on the rpc.nfsd command line. Using /etc/services for this doesn't appear to add configuration flexibility.
Comment 2 Steve Dickson 2016-03-01 17:31:40 UTC 
upstream commit
commit 269b74437be92b6a3f2e02242c893b258965953f
Author: Steve Dickson <steved>
Date:   Tue Mar 1 12:23:00 2016 -0500

    nfsd: use correct byte order on rdma port
Comment 4 Yongcheng Yang 2016-05-17 02:52:51 UTC 
I always *cannot* enable RDMA on the standard RDMA port ("nfsrdma",  port 20049), even using the workaround provided in comment 0.

An warning is emitted: "rpc.nfsd: Unable to request RDMA services: Protocol not supported"

So is this the deemed reproducing results? Or there is something wrong with my steps? Thanks in advance.

[root@hp-dl585g7-04 ~]# 
[root@hp-dl585g7-04 ~]# rpm -q nfs-utils
nfs-utils-1.3.0-0.21.el7_2.x86_64
[root@hp-dl585g7-04 ~]# 
[root@hp-dl585g7-04 ~]# echo 'RPCNFSDARGS="--rdma"' >/etc/sysconfig/nfs
[root@hp-dl585g7-04 ~]# systemctl restart nfs-config; systemctl restart nfs
[root@hp-dl585g7-04 ~]# cat /proc/fs/nfsd/portlist
tcp 2049
udp 2049
[root@hp-dl585g7-04 ~]# 
[root@hp-dl585g7-04 ~]# echo 'RPCNFSDARGS="--rdma=20049"' >/etc/sysconfig/nfs
[root@hp-dl585g7-04 ~]# systemctl restart nfs-config; systemctl restart nfs
[root@hp-dl585g7-04 ~]# cat /proc/fs/nfsd/portlist
tcp 2049
udp 2049
[root@hp-dl585g7-04 ~]# 
[root@hp-dl585g7-04 ~]# rpc.nfsd 0
[root@hp-dl585g7-04 ~]# rpc.nfsd --rdma=20049
rpc.nfsd: Unable to request RDMA services: Protocol not supported
[root@hp-dl585g7-04 ~]# cat /proc/fs/nfsd/portlist
tcp 2049
udp 2049
[root@hp-dl585g7-04 ~]# 
[root@hp-dl585g7-04 ~]# rpc.nfsd 0
[root@hp-dl585g7-04 ~]# rpc.nfsd --rdma="20049"
rpc.nfsd: Unable to request RDMA services: Protocol not supported
[root@hp-dl585g7-04 ~]# cat /proc/fs/nfsd/portlist
tcp 2049
udp 2049
[root@hp-dl585g7-04 ~]# 
[root@hp-dl585g7-04 ~]# rpc.nfsd 0
[root@hp-dl585g7-04 ~]# rpc.nfsd -r
rpc.nfsd: Unable to request RDMA services: Protocol not supported
[root@hp-dl585g7-04 ~]# cat /proc/fs/nfsd/portlist
tcp 2049
udp 2049
[root@hp-dl585g7-04 ~]# 
[root@hp-dl585g7-04 ~]# rpc.nfsd 0
[root@hp-dl585g7-04 ~]# rpc.nfsd --rdma
rpc.nfsd: Unable to request RDMA services: Protocol not supported
[root@hp-dl585g7-04 ~]# cat /proc/fs/nfsd/portlist
tcp 2049
udp 2049
[root@hp-dl585g7-04 ~]#
Comment 5 Steve Dickson 2016-05-17 17:36:29 UTC 
(In reply to Yongcheng Yang from comment #4)
> I always *cannot* enable RDMA on the standard RDMA port ("nfsrdma",  port
> 20049), even using the workaround provided in comment 0.
> 
> An warning is emitted: "rpc.nfsd: Unable to request RDMA services: Protocol
> not supported"
> 
> So is this the deemed reproducing results? Or there is something wrong with
> my steps? Thanks in advance.
> 

The rpcrdma kernel module has be loaded for the rdma protocol to
be registered. 

modprobe rpcrdma should do the trick. 

Maybe the bug should be how that module should get loaded??
Comment 8 Steve Dickson 2016-05-19 15:06:07 UTC 
(In reply to Yongcheng Yang from comment #4)
> I always *cannot* enable RDMA on the standard RDMA port ("nfsrdma",  port
> 20049), even using the workaround provided in comment 0.
> 
> An warning is emitted: "rpc.nfsd: Unable to request RDMA services: Protocol
> not supported"
> 
> So is this the deemed reproducing results? Or there is something wrong with
> my steps? Thanks in advance.
FYI... https://bugzilla.redhat.com/show_bug.cgi?id=1337599
was open to fix this problem...
Comment 10 Yongcheng Yang 2016-06-21 08:53:11 UTC 
Move to VERIFIED as comment 9, and continue to run the automatic case.
Comment 12 errata-xmlrpc 2016-11-04 05:03:20 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2383.html
Note You need to log in before you can comment on or make changes to this bug.