ocfs2-devel.oss.oracle.com archive mirror
 help / color / mirror / Atom feed
From: Wengang Wang <wen.gang.wang@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2: Move orphan scan work to ocfs2_wq.
Date: Fri, 28 May 2010 17:21:28 +0800	[thread overview]
Message-ID: <20100528092128.GC2575@laptop.us.oracle.com> (raw)
In-Reply-To: <20100528091211.GB2575@laptop.us.oracle.com>

Sorry, I made a mistake.

The quotum worker is on the system work queue, so the ocfs2_truncate_log_worker
will not block it.

regards,
wengang.
On 10-05-28 17:12, Wengang Wang wrote:
> Hi Tao,
> 
> Checking the workers in ocfs2_wq, I found osb_truncate_log_wq. The worker
> function ocfs2_truncate_log_worker() can with the following call trace.
> 
> ocfs2_truncate_log_worker()
> ocfs2_flush_truncate_log()
> __ocfs2_flush_truncate_log()
> ocfs2_inode_lock()
> 
> So I think during ocfs2_inode_lock(), we still have the possibility that
> it hang the work queue at dlm_wait_for_node_death().
> 
> So maybe a dedicated work queue is the only choice?
> 
> regards,
> wengang.
> On 10-05-28 14:22, Tao Ma wrote:
> > We used to let orphan scan work in the default work queue,
> > but there is a corner case which will make the system deadlock.
> > The scenario is like this:
> > 1. set heartbeat threadshold to 200. this will allow us to have a
> >    great chance to have a orphan scan work before our quorum decision.
> > 2. mount node 1.
> > 3. after 1~2 minutes, mount node 2(in order to make the bug easier
> >    to reproduce, better add maxcpus=1 to kernel command line).
> > 4. node 1 do orphan scan work.
> > 5. node 2 do orphan scan work.
> > 6. node 1 do orphan scan work. After this, node 1 hold the orphan scan
> >    lock while node 2 know node 1 is the master.
> > 7. ifdown eth2 in node 2(eth2 is what we do ocfs2 interconnection).
> > 
> > Now when node 2 begins orphan scan, the system queue is blocked.
> > 
> > The root cause is that both orphan scan work and quorum decision work
> > will use the system event work queue. orphan scan has a chance of
> > blocking the event work queue(in dlm_wait_for_node_death) so that there
> > is no chance for quorum decision work to proceed.
> > 
> > This patch resolve it by moving orphan scan work to ocfs2_wq.
> > 
> > Signed-off-by: Tao Ma <tao.ma@oracle.com>
> > ---
> >  fs/ocfs2/journal.c |    6 +++---
> >  1 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c
> > index 57e3fef..e02788f 100644
> > --- a/fs/ocfs2/journal.c
> > +++ b/fs/ocfs2/journal.c
> > @@ -1938,7 +1938,7 @@ void ocfs2_orphan_scan_work(struct work_struct *work)
> >  	mutex_lock(&os->os_lock);
> >  	ocfs2_queue_orphan_scan(osb);
> >  	if (atomic_read(&os->os_state) == ORPHAN_SCAN_ACTIVE)
> > -		schedule_delayed_work(&os->os_orphan_scan_work,
> > +		queue_delayed_work(ocfs2_wq, &os->os_orphan_scan_work,
> >  				      ocfs2_orphan_scan_timeout());
> >  	mutex_unlock(&os->os_lock);
> >  }
> > @@ -1978,8 +1978,8 @@ void ocfs2_orphan_scan_start(struct ocfs2_super *osb)
> >  		atomic_set(&os->os_state, ORPHAN_SCAN_INACTIVE);
> >  	else {
> >  		atomic_set(&os->os_state, ORPHAN_SCAN_ACTIVE);
> > -		schedule_delayed_work(&os->os_orphan_scan_work,
> > -				      ocfs2_orphan_scan_timeout());
> > +		queue_delayed_work(ocfs2_wq, &os->os_orphan_scan_work,
> > +				   ocfs2_orphan_scan_timeout());
> >  	}
> >  }
> >  
> > -- 
> > 1.5.5
> > 
> > 
> > _______________________________________________
> > Ocfs2-devel mailing list
> > Ocfs2-devel at oss.oracle.com
> > http://oss.oracle.com/mailman/listinfo/ocfs2-devel
> 
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel

  reply	other threads:[~2010-05-28  9:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-28  6:22 [Ocfs2-devel] [PATCH] ocfs2: Move orphan scan work to ocfs2_wq Tao Ma
2010-05-28  9:12 ` Wengang Wang
2010-05-28  9:21   ` Wengang Wang [this message]
2010-06-01 22:07 ` Sunil Mushran
2010-06-15 23:47 ` Joel Becker

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=20100528092128.GC2575@laptop.us.oracle.com \
    --to=wen.gang.wang@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).