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.