nfs: initialize timeout variable in nfs4_proc_setclientid_confirm
Subsystems (2)
RFC PATCH 1/1 nfs: initialize timeout variable in nfs4_proc_setclientid_confirm
gcc (4.3.0) rightfully warns about this:
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/fs/nfs/nfs4proc.c: In = function =91nfs4_proc_setclientid_confirm=92:
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/fs/nfs/nfs4proc.c:2936= : warning: =91timeout=92 may be used uninitialized in this function
nfs4_delay that's passed a pointer to 'timeout' is looking at its value and sets it up to some value in the range: NFS4_POLL_RETRY_MIN..NFS4_PO= LL_RETRY_MAX
if (*timeout <=3D 0) *timeout =3D NFS4_POLL_RETRY_MIN; if (*timeout > NFS4_POLL_RETRY_MAX) *timeout =3D NFS4_POLL_RETRY_MAX;
Therefore it will end up set to some sane, though rather indeterministi= c, value.
---
Trond, this patch merely initializes timeout to 0 which will result in it set eventually to NFS4_POLL_RETRY_MIN. Is this appropriate?
Benny
fs/nfs/nfs4proc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
fs/nfs/nfs4proc.c +0 -0
@@ -2933,7 +2933,7 @@ static int _nfs4_proc_setclientid_confirm(struct =
nfs_client *clp, struct rpc_cre
=20
int nfs4_proc_setclientid_confirm(struct nfs_client *clp, struct rpc_c=
red *cred)
{
- long timeout;
+ long timeout =3D 0;
int err;
do {
err =3D _nfs4_proc_setclientid_confirm(clp, cred);
--=20
1.5.6.GIT
Quoted 2 lines · Benny Halevy
gcc (4.3.0) rightfully warns about this:
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/fs/nfs/nfs4proc.c: I=
n function =E2=80=98nfs4_proc_setclientid_confirm=E2=80=99:
Quoted 1 line
/usr0/export/dev/bhalevy/git/linux-pnfs-bh-nfs41/fs/nfs/nfs4proc.c:29=
36: warning: =E2=80=98timeout=E2=80=99 may be used uninitialized in thi= s function
Quoted 2 lines
=20
nfs4_delaythat's passed a pointer to 'timeout' is looking at its val=
ue
Quoted 1 line
and sets it up to some value in the range: NFS4_POLL_RETRY_MIN..NFS4_=
POLL_RETRY_MAX
Quoted 6 lines
if (*timeout <=3D 0) *timeout =3D NFS4_POLL_RETRY_MIN; if (*timeout > NFS4_POLL_RETRY_MAX) *timeout =3D NFS4_POLL_RETRY_MAX;=20
Therefore it will end up set to some sane, though rather indeterminis=
tic, value.
Quoted 7 lines
=20
Signed-off-by Benny Halevy <[email protected]>---
=20
Trond, this patch merely initializes timeout to 0 which will result in it set eventually toNFS4_POLL_RETRY_MIN. Is this appropriate?
ACK. Since the existing will always return sane values, and nobody has complained yet, I'll queue this up for 2.6.27 rather than pushing it as a hotfix.
Thanks!
Trond