> On May 23, 2022, at 1:43 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote:
>
> IOW: the number of lm_get_owner and lm_put_owner calls should always be
> 100% balanced once all the locks belonging to a specific lock owner are
> removed.
It doesn't look like that's the case. If we rely solely on
lm_get/put_owner, the lockcnt quickly becomes negative, even
without the presence of lock conflicts:
nfsd-999 [001] 155.888211: nfsd_compound: xid=0x0000001c opcnt=2
nfsd-999 [001] 155.888260: nfsd_compound_status: op=1/2 OP_PUTFH status=0
nfsd-999 [001] 155.888283: nfsd_preprocess: seqid=2 client 628c04a3:f2adef0d stateid 00000002:00000002
nfsd-999 [001] 155.888419: bprint: nfsd4_lm_get_owner: lo=0xffff8881955b1050 conflict=false lockcnt=1 so_count=3
nfsd-999 [001] 155.888431: bprint: nfsd4_lm_put_owner.part.0: lo=0xffff8881955b1050 conflict=false lockcnt=1 so_count=3
nfsd-999 [001] 155.888441: nfsd_file_put: hash=0x339 inode=0xffff88816770d908 ref=3 flags=HASHED|REFERENCED may=WRITE|READ file=0xffff88811232f7c0
nfsd-999 [001] 155.888453: nfsd_compound_status: op=2/2 OP_LOCK status=0
nfsd-999 [003] 155.890388: nfsd_compound: xid=0x0000001d opcnt=2
nfsd-999 [003] 155.890457: nfsd_compound_status: op=1/2 OP_PUTFH status=0
nfsd-999 [003] 155.890459: nfsd_preprocess: seqid=1 client 628c04a3:f2adef0d stateid 00000003:00000001
nfsd-999 [003] 155.890479: bprint: nfsd4_lm_put_owner.part.0: lo=0xffff8881955b1050 conflict=false lockcnt=0 so_count=4
nfsd-999 [003] 155.890490: nfsd_file_put: hash=0x339 inode=0xffff88816770d908 ref=3 flags=HASHED|REFERENCED may=WRITE|READ file=0xffff88811232f7c0
nfsd-999 [003] 155.890492: bprint: nfsd4_lm_put_owner.part.0: lo=0xffff8881955b1050 conflict=false lockcnt=-1 so_count=3
nfsd-999 [003] 155.890502: nfsd_compound_status: op=2/2 OP_LOCKU status=0
nfsd-999 [003] 155.892494: nfsd_compound: xid=0x0000001e opcnt=5
nfsd-999 [003] 155.892498: nfsd_compound_status: op=1/5 OP_PUTROOTFH status=0
nfsd-999 [003] 155.892528: nfsd_compound_status: op=2/5 OP_LOOKUP status=0
nfsd-999 [003] 155.892552: nfsd_compound_status: op=3/5 OP_LOOKUP status=0
nfsd-999 [003] 155.892576: nfsd_compound_status: op=4/5 OP_LOOKUP status=0
nfsd-999 [003] 155.892604: nfsd_file_fsnotify_handle_event: inode=0xffff88816770d908 nlink=0 mode=0100644 mask=0x4
nfsd-999 [003] 155.892605: nfsd_file_unhash_and_release_locked: hash=0x339 inode=0xffff88816770d908 ref=2 flags=HASHED|REFERENCED may=WRITE|READ file=0xffff88811232f7c0
nfsd-999 [003] 155.892606: nfsd_file_unhash: hash=0x339 inode=0xffff88816770d908 ref=2 flags=REFERENCED may=WRITE|READ file=0xffff88811232f7c0
nfsd-999 [003] 155.892607: nfsd_file_close_inode: hash=0x339 inode=0xffff88816770d908 found=0
nfsd-999 [003] 155.892610: nfsd_compound_status: op=5/5 OP_REMOVE status=0
nfsd-999 [001] 155.894663: nfsd_compound: xid=0x0000001f opcnt=1
nfsd-999 [001] 155.894667: bprint: nfsd4_release_lockowner: lo=0xffff8881955b1050 lockcnt=-2 so_count=1
nfsd-999 [001] 155.894670: nfsd_file_put: hash=0x339 inode=0xffff88816770d908 ref=2 flags=REFERENCED may=WRITE|READ file=0xffff88811232f7c0
nfsd-999 [001] 155.894706: nfsd_compound_status: op=1/1 OP_RELEASE_LOCKOWNER status=0
There are other places inside NFSD that call nfs4_get/
put_stateowner on a lockowner. That seems to be what keeps
the so_count above water.
Or, another way to look at it: simply saving the value of
the conflict boolean in file_lock and passing that to
lm_put_owner() doesn't seem to be adequate.
--
Chuck Lever
