On 25 Apr 2019, at 10:04, J. Bruce Fields wrote:
From: "J. Bruce Fields" <bfields@xxxxxxxxxx>
Add open modes, device numbers, inode numbers, and open owners to each
line of nfsd/clients/#/opens.
Open owners are totally opaque but seem to sometimes have some useful
ascii strings included, so passing through printable ascii characters
and escaping the rest seems useful while still being machine-readable.
---
fs/nfsd/nfs4state.c | 40
++++++++++++++++++++++++++++------
fs/nfsd/state.h | 2 +-
fs/seq_file.c | 17 +++++++++++++++
include/linux/seq_file.h | 2 ++
include/linux/string_helpers.h | 1 +
lib/string_helpers.c | 5 +++--
6 files changed, 57 insertions(+), 10 deletions(-)
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 829d1e5440d3..f53621a65e60 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -42,6 +42,7 @@
#include <linux/sunrpc/svcauth_gss.h>
#include <linux/sunrpc/addr.h>
#include <linux/jhash.h>
+#include <linux/string_helpers.h>
#include "xdr4.h"
#include "xdr4cb.h"
#include "vfs.h"
@@ -2261,16 +2262,41 @@ static void opens_stop(struct seq_file *s,
void *v)
static int opens_show(struct seq_file *s, void *v)
{
struct nfs4_stid *st = v;
- struct nfs4_ol_stateid *os;
- u64 stateid;
+ struct nfs4_ol_stateid *ols;
+ struct nfs4_file *nf;
+ struct file *file;
+ struct inode *inode;
+ struct nfs4_stateowner *oo;
+ unsigned int access, deny;
if (st->sc_type != NFS4_OPEN_STID)
return 0; /* XXX: or SEQ_SKIP? */
- os = openlockstateid(st);
- /* XXX: get info about file, etc., here */
+ ols = openlockstateid(st);
+ oo = ols->st_stateowner;
+ nf = st->sc_file;
+ file = find_any_file(nf);
+ inode = d_inode(file->f_path.dentry);
+
+ seq_printf(s, STATEID_FMT, STATEID_VAL(&st->sc_stateid));
Should we match the byte order printed with what wireshark/tshark sees?
For example, this will print:
5ccb016e/6d028c97/00000002/00000002 -w -- fd:00:9163439 'open
id:\x00\x00\x00.\x00\x00\x00\x00\x00\x00\x021\x8dp\xbe\xc7'
But, tshark -V prints:
Opcode: OPEN (18)
Status: NFS4_OK (0)
stateid
[StateID Hash: 0x8298]
seqid: 0x00000002
Data: 6e01cb5c978c026d02000000
[Data hash (CRC-32): 0x8391069f]
I think this is the first time we've exposed state ids to users from
knfsd,
I wonder if we should make it easier for everyone that might want to try
to
correlate this information with what they can see in a packet capture.
Ben
