[v3,0/4] RELEASE_LOCKOWNER continued...

Message

Chuck Lever May 25, 2022, 3:47 p.m. UTC

I am still concerned that an approach that uses the lm_get/put_owner
methods is unworkable because that API is used in several unrelated
situations.

For example, a successful LOCK operation does a get_owner and
put_owner on the lockowner; the put_owner is called from
free_blocked_lock. A successful UNLOCK operation does two
put_owner calls; once from posix_lock_inode and once from
locks_free_lock.

Thus I believe it would be difficult to change fs/locks to count
locks accurately via the lm_get/put_owner API. Even if we could get
the lock counting right today, the API so far is confusing enough to
be vulnerable to breakage by subsequent changes in this area.

Therefore I'm leaning towards the so_count-based approach as shown
in this version of the patch series.

---

Chuck Lever (4):
      NFSD: Fix possible sleep during nfsd4_release_lockowner()
      NFSD: Modernize nfsd4_release_lockowner()
      NFSD: Add documenting comment for nfsd4_release_lockowner()
      NFSD: nfsd_file_put() can sleep


 fs/nfsd/filecache.c |  2 ++
 fs/nfsd/nfs4state.c | 63 ++++++++++++++++++++++-----------------------
 2 files changed, 33 insertions(+), 32 deletions(-)

--
Chuck Lever