public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Ren <zren@suse.com>
To: ocfs2-devel@oss.oracle.com
Cc: akpm@linux-foundation.org, mfasheh@versity.com,
	jlbec@evilplan.org, ghe@suse.com, junxiao.bi@oracle.com,
	jiangqi903@gmail.com, sfr@canb.auug.org.au, hch@lst.de,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/2] fix deadlock caused by recursive cluster locking
Date: Mon, 16 Jan 2017 14:42:18 +0800	[thread overview]
Message-ID: <20170116064220.23720-1-zren@suse.com> (raw)

This is a formal patch set v2 to solve the deadlock issue on which I
previously started a RFC (draft patch), and the discussion happened here:
[https://oss.oracle.com/pipermail/ocfs2-devel/2016-October/012455.html]

Compared to the previous draft patch, this one is much simple and neat.
It neither messes up the dlmglue core, nor has a performance penalty on
the whole cluster locking system. Instead, it is only used in places where
such recursive cluster locking may happen.
 
Changes since v1: 
1. Let ocfs2_is_locked_by_me() just return true/false to indicate if the
process gets the cluster lock - suggested by: Joseph Qi <jiangqi903@gmail.com>
and Junxiao Bi <junxiao.bi@oracle.com>.
 
2. Change "struct ocfs2_holder" to a more meaningful name "ocfs2_lock_holder",
suggested by: Junxiao Bi <junxiao.bi@oracle.com>.
 
3. Add debugging output at ocfs2_setattr() and ocfs2_permission() to
catch exceptional cases, suggested by: Junxiao Bi <junxiao.bi@oracle.com>.
 
4. Do not inline functions whose bodies are not in scope, changed by:
Stephen Rothwell <sfr@canb.auug.org.au>.
 
Your comments and feedbacks are always welcomed.

Eric Ren (2):
  ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
  ocfs2: fix deadlock issue when taking inode lock at vfs entry points

 fs/ocfs2/acl.c     | 39 ++++++++++++++++++++++++----
 fs/ocfs2/dlmglue.c | 48 +++++++++++++++++++++++++++++++---
 fs/ocfs2/dlmglue.h | 18 +++++++++++++
 fs/ocfs2/file.c    | 76 +++++++++++++++++++++++++++++++++++++++++++++++-------
 fs/ocfs2/ocfs2.h   |  1 +
 5 files changed, 164 insertions(+), 18 deletions(-)

-- 
2.10.2

             reply	other threads:[~2017-01-16  6:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16  6:42 Eric Ren [this message]
2017-01-16  6:42 ` [PATCH v2 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock Eric Ren
2017-01-16  6:42 ` [PATCH v2 2/2] ocfs2: fix deadlock issue when taking inode lock at vfs entry points Eric Ren
2017-01-16  6:58   ` Junxiao Bi
2017-01-16  7:35     ` Eric Ren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170116064220.23720-1-zren@suse.com \
    --to=zren@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=ghe@suse.com \
    --cc=hch@lst.de \
    --cc=jiangqi903@gmail.com \
    --cc=jlbec@evilplan.org \
    --cc=junxiao.bi@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfasheh@versity.com \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox