Skip to contentSkip to conversation

Typo in nfsd_vers()

PATCH Applied Steve Dickson 3 participants 5 messages Jan 17, 2008 – Jan 18, 2008 2 messages not in the archive

Subsystems (2)
NFS client NFS server
lore
Share & tools
lore

Steve Dickson

author
#0 lore raw

PATCH 1/1 Typo in nfsd_vers()

During my travels I found a small typo in nfsd_vers() (the routine used by rpc.nfsd to set the protocol version(s) in NFS server)

When testing to see which versions are available, nfsd_vers() should use nfsd_versions[] not nfsd_version[]. The reason this typo is not noticeable is due to the fact this availability info is used in a reply that rpc.nfsd ignores.

steved.

Author: Steve Dickson <[email protected]>
Date:   Thu Jan 17 06:50:57 2008 -0500
    In nfsd_vers() the NFSD_AVAIL command should be using nfsd_versions[]
    not nfsd_version[]

    Signed-off-by: Steve Dickson <[email protected]>
fs/nfsd/nfssvc.c +1 -1
index 1190aea..f0c66e0 100644
@@ -134,7 +134,7 @@ int nfsd_vers(int vers, enum vers_op change)
    case NFSD_TEST:
        return nfsd_versions[vers] != NULL;
    case NFSD_AVAIL:
-       return nfsd_version[vers] != NULL;
+       return nfsd_versions[vers] != NULL;
    }
    return 0;
 }
Applied
#2 lore raw
In reply to a message not in the archive
Quoted 7 lines · Steve Dickson

During my travels I found a small typo in nfsd_vers() (the routine used by rpc.nfsd to set the protocol version(s) in NFS server)

When testing to see which versions are available, nfsd_vers() should use nfsd_versions[] not nfsd_version[]. The reason this typo is not noticeable is due to the fact this availability info is used in a reply that rpc.nfsd ignores.

Thanks, applied!

Your mailer's messing up the whitespace, though--might want to fix that for next time.

--b.

Quoted 25 lines

steved.

Author: Steve Dickson <[email protected]>
Date:   Thu Jan 17 06:50:57 2008 -0500
    In nfsd_vers() the NFSD_AVAIL command should be using nfsd_versions[]
    not nfsd_version[]

    Signed-off-by: Steve Dickson <[email protected]>
fs/nfsd/nfssvc.c +1 -1
index 1190aea..f0c66e0 100644
@@ -134,7 +134,7 @@ int nfsd_vers(int vers, enum vers_op change)
    case NFSD_TEST:
        return nfsd_versions[vers] != NULL;
    case NFSD_AVAIL:
-       return nfsd_version[vers] != NULL;
+       return nfsd_versions[vers] != NULL;
    }
    return 0;
 }
#3 lore raw
In reply to a message not in the archive
Quoted 24 lines · On Thu, 17 Jan 2008 07:16:47 -0500 Steve Dickson <[email protected]> wrote:

During my travels I found a small typo in nfsd_vers() (the routine used by rpc.nfsd to set the protocol version(s) in NFS server)

When testing to see which versions are available, nfsd_vers() should use nfsd_versions[] not nfsd_version[]. The reason this typo is not noticeable is due to the fact this availability info is used in a reply that rpc.nfsd ignores.

steved.

Author: Steve Dickson <[email protected]>
Date:   Thu Jan 17 06:50:57 2008 -0500
    In nfsd_vers() the NFSD_AVAIL command should be using nfsd_versions[]
    not nfsd_version[]

    Signed-off-by: Steve Dickson <[email protected]>
fs/nfsd/nfssvc.c +0 -0
index 1190aea..f0c66e0 100644

fs/nfsd/nfssvc.c int nfsd_vers(int vers, enum vers_op change) · line 140

Quoted 8 lines
fs/nfsd/nfssvc.c +1 -1
@@ -134,7 +134,7 @@ int nfsd_vers(int vers, enum vers_op change)
    case NFSD_TEST:
        return nfsd_versions[vers] != NULL;
    case NFSD_AVAIL:
-       return nfsd_version[vers] != NULL;
+       return nfsd_versions[vers] != NULL;
    }
    return 0;
 }

This doesn't look right to me. With this, NFSD_TEST and NFSD_AVAIL do exactly the same thing. Why do we need both?

It also changes the output of /proc/fs/nfsd/versions. It should show a number for every version compiled into the kernel, with a corresponding
+ or - depending on whether that version is enabled. With this patch, it'll only ever show versions that are enabled, never ones that are compiled in and disabled.

Signature · 1 line
Jeff Layton <[email protected]>
#5 lore raw
In reply to a message not in the archive
Quoted 39 lines · Jeff Layton
Quoted 24 lines · On Thu, 17 Jan 2008 07:16:47 -0500 Steve Dickson <[email protected]> wrote:

During my travels I found a small typo in nfsd_vers() (the routine used by rpc.nfsd to set the protocol version(s) in NFS server)

When testing to see which versions are available, nfsd_vers() should use nfsd_versions[] not nfsd_version[]. The reason this typo is not noticeable is due to the fact this availability info is used in a reply that rpc.nfsd ignores.

steved.

Author: Steve Dickson <[email protected]>
Date:   Thu Jan 17 06:50:57 2008 -0500
    In nfsd_vers() the NFSD_AVAIL command should be using nfsd_versions[]
    not nfsd_version[]

    Signed-off-by: Steve Dickson <[email protected]>
fs/nfsd/nfssvc.c +0 -0
index 1190aea..f0c66e0 100644

fs/nfsd/nfssvc.c int nfsd_vers(int vers, enum vers_op change) · line 140

Quoted 8 lines
fs/nfsd/nfssvc.c +1 -1
@@ -134,7 +134,7 @@ int nfsd_vers(int vers, enum vers_op change)
    case NFSD_TEST:
        return nfsd_versions[vers] != NULL;
    case NFSD_AVAIL:
-       return nfsd_version[vers] != NULL;
+       return nfsd_versions[vers] != NULL;
    }
    return 0;
 }

This doesn't look right to me. With this, NFSD_TEST and NFSD_AVAIL do exactly the same thing. Why do we need both?

Quoted 5 lines

It also changes the output of /proc/fs/nfsd/versions. It should show a number for every version compiled into the kernel, with a corresponding
+ or - depending on whether that version is enabled. With this patch, it'll only ever show versions that are enabled, never ones that are compiled in and disabled.

Oops, looks to me like you're correct--so nfsd_version[] is the versions which this kernel was built to support, and nfsd_versions[] is the subset of those that the server is currently accepting?

We could maybe give those two arrays names that were more helpful....

--b.

#6 lore raw
Quoted 3 lines · On Fri, 18 Jan 2008 17:06:41 -0500 "J. Bruce Fields" <[email protected]>…

We could maybe give those two arrays names that were more helpful....

That would be a definite improvement :-)

Signature · 1 line
Jeff Layton <[email protected]>