Skip to content
Commit 133b81f2 authored by Larry Chen's avatar Larry Chen Committed by Linus Torvalds
Browse files

ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level

ocfs2_inode_lock_tracker as a variant of ocfs2_inode_lock, is used to
prevent deadlock due to recursive lock acquisition.

But this function does not distinguish whether the requested level is EX
or PR.

If a RP lock has been attained, this function will immediately return
success afterwards even an EX lock is requested.

But actually the return value does not mean that the process got a EX
lock, because ocfs2_inode_lock has not been called.

When taking lock levels into account, we face some different situations:

1. no lock is held
   In this case, just lock the inode and return 0

2. We are holding a lock
   For this situation, things diverges into several cases

   wanted     holding	     what to do
   ex		ex	    see 2.1 below
   ex		pr	    see 2.2 below
   pr		ex	    see 2.1 below
   pr		pr	    see 2.1 below

   2.1 lock level that is been held is compatible
   with the wanted level, so no lock action will be tacken.

   2.2 Otherwise, an upgrade is needed, but it is forbidden.

Reason why upgrade within a process is forbidden is that lock upgrade
may cause dead lock.  The following illustrate how it happens.

        process 1                             process 2
ocfs2_inode_lock_tracker(ex=0)
                               <======   ocfs2_inode_lock_tracker(ex=1)

ocfs2_inode_lock_tracker(ex=1)

For the status quo of ocfs2, without this patch, neither a bug nor
end-user impact will be caused because the wrong logic is avoided.

But I'm afraid this generic interface, may be called by other developers
in future and used in this situation.

  a process
ocfs2_inode_lock_tracker(ex=0)
ocfs2_inode_lock_tracker(ex=1)

Link: http://lkml.kernel.org/r/20180510053230.17217-1-lchen@suse.com


Signed-off-by: default avatarLarry Chen <lchen@suse.com>
Reviewed-by: default avatarGang He <ghe@suse.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joseph Qi <jiangqi903@gmail.com>
Cc: Changwei Ge <ge.changwei@h3c.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 5bc55d65
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment