All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] ocfs2: Should move ocfs2_start_trans out of lock_page
Date: Sun, 30 Jun 2013 11:10:13 +0800	[thread overview]
Message-ID: <51CFA195.1070403@huawei.com> (raw)
In-Reply-To: <20130629131732.GI13405@ZenIV.linux.org.uk>

Hi Joel,
Thanks very much for replying this message.
Actually we just met this issue in a case which did a mess of read/write
IOs.
And after analyzing, we found it is just the lock_page that caused this
issue.

We have tried to solve this issue by looking up ext4. Since there are 5
functions related, it requires a lot code changes. So firstly I'd like
to get a second opinion from you.

On 2013/6/29 21:17, Joel Becker wrote:
> I'm pretty sure we did it for a reason, which means we need to think
> about it more than just looking at ext4.  Remember that we get access
> coming from other node actions.
> 
> Joel
> 
> On Mon, Jun 24, 2013 at 04:55:20PM +0800, Joseph Qi wrote:
>> Any different opinion?
>>
>> On 2013/6/19 16:17, Joseph Qi wrote:
>>> Currently ocfs2_start_trans/ocfs2_commit_trans are in
>>> lock_page/unlock_page. This may cause dead lock.
>>>
>>> Here is the situation:
>>> write -> lock_page -> ocfs2_start_trans -> ocfs2_commit_trans -> unlock_page
>>> ocfs2_start_trans/ocfs2_commit_trans calls
>>> jbd2_journal_start/jbd2_journal_stop which may also call lock_page. So
>>> if the page operated is unfortunately the same with the page to be
>>> committed, dead lock happens.
>>>
>>> In ext4, lock_page/unlock_page are in
>>> ext4_journal_start/ext4_journal_stop, this can avoid such kind of dead
>>> lock. So I think we should move ocfs2_start_trans/ocfs2_commit_trans out
>>> of lock_page/unlock_page.
>>>
>>> Totally there are 5 related functions:
>>> ocfs2_write_begin_nolock
>>> ocfs2_write_begin_inline
>>> ocfs2_write_end_nolock
>>> ocfs2_write_zero_page
>>> ocfs2_convert_inline_data_to_extents
>>>
>>>
>>> _______________________________________________
>>> Ocfs2-devel mailing list
>>> Ocfs2-devel at oss.oracle.com
>>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Ocfs2-devel mailing list
>> Ocfs2-devel at oss.oracle.com
>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
> 

      reply	other threads:[~2013-06-30  3:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19  8:17 [Ocfs2-devel] ocfs2: Should move ocfs2_start_trans out of lock_page Joseph Qi
2013-06-24  8:55 ` Joseph Qi
2013-06-29 13:17   ` Joel Becker
2013-06-30  3:10     ` Joseph Qi [this message]

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=51CFA195.1070403@huawei.com \
    --to=joseph.qi@huawei.com \
    --cc=ocfs2-devel@oss.oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.