Details
-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
Lustre 2.16.0, Lustre 2.15.4
-
None
-
3
-
9223372036854775807
Description
Building Lustre codes on RHEL 9.3 with kernel 5.14.0-362.8.1.el9_3 failed as follows:
CC [M] /root/lustre-release/lustre/ptlrpc/gss/gss_svc_upcall.o /root/lustre-release/lustre/ptlrpc/gss/gss_svc_upcall.c: In function 'rsi_parse': /root/lustre-release/lustre/ptlrpc/gss/gss_svc_upcall.c:681:18: error: too few arguments to function 'get_expiry' 681 | expiry = get_expiry(&mesg); | ^~~~~~~~~~ In file included from /root/lustre-release/lustre/ptlrpc/gss/gss_svc_upcall.c:57: include/linux/sunrpc/cache.h:303:19: note: declared here 303 | static inline int get_expiry(char **bpp, time64_t *rvp) | ^~~~~~~~~~ /root/lustre-release/lustre/ptlrpc/gss/gss_svc_upcall.c: In function 'rsc_parse': /root/lustre-release/lustre/ptlrpc/gss/gss_svc_upcall.c:937:18: error: too few arguments to function 'get_expiry' 937 | expiry = get_expiry(&mesg); | ^~~~~~~~~~ In file included from /root/lustre-release/lustre/ptlrpc/gss/gss_svc_upcall.c:57: include/linux/sunrpc/cache.h:303:19: note: declared here 303 | static inline int get_expiry(char **bpp, time64_t *rvp) | ^~~~~~~~~~
The definition of get_expiry() in include/linux/sunrpc/cache.h was changed by the following linux kernel commit:
commit cf64b9bce95095b80f4589e4f54572cc5d8c1538 Author: NeilBrown <neilb@suse.de> AuthorDate: Wed Mar 8 17:51:00 2023 +1100 Commit: Chuck Lever <chuck.lever@oracle.com> CommitDate: Wed Apr 26 09:05:00 2023 -0400 SUNRPC: return proper error from get_expiry() The get_expiry() function currently returns a timestamp, and uses the special return value of 0 to indicate an error. Unfortunately this causes a problem when 0 is the correct return value. On a system with no RTC it is possible that the boot time will be seen to be "3". When exportfs probes to see if a particular filesystem supports NFS export it tries to cache information with an expiry time of "3". The intention is for this to be "long in the past". Even with no RTC it will not be far in the future (at most a second or two) so this is harmless. But if the boot time happens to have been calculated to be "3", then get_expiry will fail incorrectly as it converts the number to "seconds since bootime" - 0. To avoid this problem we change get_expiry() to report the error quite separately from the expiry time. The error is now the return value. The expiry time is reported through a by-reference parameter.