From: Xue jiufei <xuejiufei@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] A deadlock when system do not has sufficient memory
Date: Wed, 27 Aug 2014 09:57:38 +0800 [thread overview]
Message-ID: <53FD3B12.5070802@huawei.com> (raw)
In-Reply-To: <CAEeiSHXmTbTJsEFbE4C1oZxNFwgR08P+f7KmC3r3usLeUMC1DQ@mail.gmail.com>
Hi, Sunil
On 2014/8/26 1:13, Sunil Mushran wrote:
> On Sun, Aug 24, 2014 at 11:05 PM, Joseph Qi <joseph.qi at huawei.com <mailto:joseph.qi@huawei.com>> wrote:
>
> On 2014/8/25 13:45, Sunil Mushran wrote:
> > Please could you expand on that.
> >
> In our scenario, one node can mount multiple volumes across the
> cluster.
> For instance, N1 has mounted ocfs2 volumes say volume1, volume2,
> volume3. And volume3 may do umount/mount during runtime of other
> volumes.
>
>
> I meant expand on the deadlock. Say we are mounting a new volume and that triggers a inode cleanup. That inode being cleaned up will have to be from one of the mounted volumes. How can this lead to a deadlock?
>
> Two variations:
> a) Node death leading to recovery during the mount.
> b) Mount atop a mount.
>
> But I cannot still see a deadlock in either scenario.
The deadlock situation is just the same as the I described in my first mail.
o2net_wq
-> dlm_query_region_handler
-> kmalloc(no sufficient memory)
-> triggers ocfs2 inodes cleanup
-> ocfs2_drop_lock
-> call o2net_send_message to send unlock message
-> wait_event(nsw.ns_wq, o2net_nsw_completed(nn, &nsw))
to wait for the reply from master
-> tcp layer receive the reply, call o2net_data_ready
-> queue sc_rx_work, but o2net_wq cannot handle this work
so it triggers the deadlock, o2net_wq is waiting itself to
handle unlock reply and complete the nsw.
Thanks.
Xuejiufei
next prev parent reply other threads:[~2014-08-27 1:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-20 3:57 [Ocfs2-devel] A deadlock when system do not has sufficient memory Xue jiufei
2014-08-22 8:30 ` Xue jiufei
2014-08-22 17:08 ` Sunil Mushran
2014-08-25 2:05 ` Xue jiufei
2014-08-25 5:00 ` Sunil Mushran
2014-08-25 5:41 ` Joseph Qi
2014-08-25 5:45 ` Sunil Mushran
2014-08-25 6:05 ` Joseph Qi
2014-08-25 17:13 ` Sunil Mushran
2014-08-27 1:57 ` Xue jiufei [this message]
2014-08-28 1:16 ` Sunil Mushran
2014-08-25 1:50 ` Junxiao Bi
2014-08-28 8:16 ` Xue jiufei
2014-08-29 3:26 ` Junxiao Bi
2014-08-29 7:22 ` Xue jiufei
2014-08-29 7:30 ` Junxiao Bi
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=53FD3B12.5070802@huawei.com \
--to=xuejiufei@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.