This patch looks like it should be in the 3.8-stable tree, should we apply
it?
------------------
From: "Steven Whitehouse <[email protected]>"
commit c2952d202f710d326ac36a8ea6bd216b20615ec8 upstream
When withdraw occurs, we need to continue to allow unlocks of fcntl
locks to occur, however these will only be local, since the node has
withdrawn from the cluster. This prevents triggering a VFS level
bug trap due to locks remaining when a file is closed.
Signed-off-by: Steven Whitehouse <[email protected]>
Signed-off-by: Jonghwan Choi <[email protected]>
---
fs/gfs2/file.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 991ab2d..7af426b 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -924,8 +924,11 @@ static int gfs2_lock(struct file *file, int cmd, struct
file_lock *fl)
cmd = F_SETLK;
fl->fl_type = F_UNLCK;
}
- if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags)))
+ if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags))) {
+ if (fl->fl_type == F_UNLCK)
+ posix_lock_file_wait(file, fl);
return -EIO;
+ }
if (IS_GETLK(cmd))
return dlm_posix_get(ls->ls_dlm, ip->i_no_addr, file, fl);
else if (fl->fl_type == F_UNLCK)
--
1.7.9.5
Hi,
On Thu, 2013-04-11 at 11:05 +0900, Jonghwan Choi wrote:
> This patch looks like it should be in the 3.8-stable tree, should we apply
> it?
>
Yes, that seems reasonable to me,
Steve.
> ------------------
>
> From: "Steven Whitehouse <[email protected]>"
>
> commit c2952d202f710d326ac36a8ea6bd216b20615ec8 upstream
>
> When withdraw occurs, we need to continue to allow unlocks of fcntl
> locks to occur, however these will only be local, since the node has
> withdrawn from the cluster. This prevents triggering a VFS level
> bug trap due to locks remaining when a file is closed.
>
> Signed-off-by: Steven Whitehouse <[email protected]>
> Signed-off-by: Jonghwan Choi <[email protected]>
> ---
> fs/gfs2/file.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
> index 991ab2d..7af426b 100644
> --- a/fs/gfs2/file.c
> +++ b/fs/gfs2/file.c
> @@ -924,8 +924,11 @@ static int gfs2_lock(struct file *file, int cmd, struct
> file_lock *fl)
> cmd = F_SETLK;
> fl->fl_type = F_UNLCK;
> }
> - if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags)))
> + if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags))) {
> + if (fl->fl_type == F_UNLCK)
> + posix_lock_file_wait(file, fl);
> return -EIO;
> + }
> if (IS_GETLK(cmd))
> return dlm_posix_get(ls->ls_dlm, ip->i_no_addr, file, fl);
> else if (fl->fl_type == F_UNLCK)
On Thu, Apr 11, 2013 at 11:05:18AM +0900, Jonghwan Choi wrote:
> This patch looks like it should be in the 3.8-stable tree, should we apply
> it?
I believe this is also applicable to the 3.5 kernel. Queuing it
Cheers,
--
Luis
>
> ------------------
>
> From: "Steven Whitehouse <[email protected]>"
>
> commit c2952d202f710d326ac36a8ea6bd216b20615ec8 upstream
>
> When withdraw occurs, we need to continue to allow unlocks of fcntl
> locks to occur, however these will only be local, since the node has
> withdrawn from the cluster. This prevents triggering a VFS level
> bug trap due to locks remaining when a file is closed.
>
> Signed-off-by: Steven Whitehouse <[email protected]>
> Signed-off-by: Jonghwan Choi <[email protected]>
> ---
> fs/gfs2/file.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
> index 991ab2d..7af426b 100644
> --- a/fs/gfs2/file.c
> +++ b/fs/gfs2/file.c
> @@ -924,8 +924,11 @@ static int gfs2_lock(struct file *file, int cmd, struct
> file_lock *fl)
> cmd = F_SETLK;
> fl->fl_type = F_UNLCK;
> }
> - if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags)))
> + if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags))) {
> + if (fl->fl_type == F_UNLCK)
> + posix_lock_file_wait(file, fl);
> return -EIO;
> + }
> if (IS_GETLK(cmd))
> return dlm_posix_get(ls->ls_dlm, ip->i_no_addr, file, fl);
> else if (fl->fl_type == F_UNLCK)
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html