lkml.org 
[lkml]   [2020]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 4.19 114/131] ocfs2: avoid inode removal while nfsd is accessing it
On Thu, Jul 2, 2020 at 2:17 PM Pavel Machek <pavel@denx.de> wrote:
>
>
> > commit 4cd9973f9ff69e37dd0ba2bd6e6423f8179c329a upstream.
> >
> > Patch series "ocfs2: fix nfsd over ocfs2 issues", v2.
>
> This causes locking imbalance:

This sems to be true upstream too.

> When ocfs2_nfs_sync_lock() returns error, caller can not know if the
> lock was taken or not.

Right you are.

And your patch looks sane:

> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
> index c141b06811a6..8149fb6f1f0d 100644
> --- a/fs/ocfs2/dlmglue.c
> +++ b/fs/ocfs2/dlmglue.c
> @@ -2867,9 +2867,15 @@ int ocfs2_nfs_sync_lock(struct ocfs2_super *osb, int ex)
>
> status = ocfs2_cluster_lock(osb, lockres, ex ? LKM_EXMODE : LKM_PRMODE,
> 0, 0);
> - if (status < 0)
> + if (status < 0) {
> mlog(ML_ERROR, "lock on nfs sync lock failed %d\n", status);
>
> + if (ex)
> + up_write(&osb->nfs_sync_rwlock);
> + else
> + up_read(&osb->nfs_sync_rwlock);
> + }
> +
> return status;
> }

although the whole thing looks messy.

If the issue is a lifetime thing (like that commit says), the proper
model isn't a lock, but a refcount.

Oh well. Junxiao?

Linus

\
 
 \ /
  Last update: 2020-07-03 00:24    [W:0.161 / U:3.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site