2020-04-23 20:36:25

by J. Bruce Fields

[permalink] [raw]
Subject: [PATCH 2/2] nfsd4: stid display should preserve on-the-wire byte order

From: "J. Bruce Fields" <[email protected]>

When we decode the stateid we byte-swap si_generation.

But for simplicity's sake and ease of comparison with network traces,
it's better to display the whole thing in network order.

Reported-by: Scott Mayhew <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
---
fs/nfsd/nfs4state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 7537f2f5156e..a6e0a7f77eb0 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -2422,7 +2422,8 @@ static void nfs4_show_owner(struct seq_file *s, struct nfs4_stateowner *oo)

static void nfs4_show_stateid(struct seq_file *s, stateid_t *stid)
{
- seq_printf(s, "0x%16phN", stid);
+ seq_printf(s, "0x%.8x", stid->si_generation);
+ seq_printf(s, "%12phN", &stid->si_opaque);
}

static int nfs4_show_open(struct seq_file *s, struct nfs4_stid *st)
--
2.25.3


2020-04-23 20:51:32

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH 2/2] nfsd4: stid display should preserve on-the-wire byte order

By the way, one other thing I noticed, in the "states" file there's a
field like:

superblock: "fd:10:114"

That's major:minor:inode number, which is the same thing /proc/locks
uses to identify files. "superblock" makes sense for the "major:minor"
part, but the inode number is for the one file, not the superblock. So
that probably should have been

superblock: "fd:10:114", inode: 114

or something. Oh well. It's been that way in a few kernel versions now
so I guess it's not worth breaking backwards compatibility.

--b.