From: Richard Davies <richard@arachsys.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-btrfs@vger.kernel.org,
Vladimir Davydov <vdavydov@parallels.com>
Subject: Re: Kernel crash triggered by dd to file with memcg, worst on btrfs
Date: Thu, 24 Apr 2014 11:59:33 +0100 [thread overview]
Message-ID: <20140424105933.GD32011@alpha.arachsys.com> (raw)
In-Reply-To: <20140423215852.GA6651@dhcp22.suse.cz>
Michal Hocko wrote:
> Richard Davies wrote:
> > I have a test case in which I can often crash an entire machine by running
> > dd to a file with a memcg with relatively generous limits. This is
> > simplified from real world problems with heavy disk i/o inside containers.
...
> > [I have also just reported a different but similar bug with untar in a memcg
> > http://marc.info/?l=linux-mm&m=139766321822891 That one is not btrfs-linked]
...
> Does this happen even if no kmem limit is specified?
No, it only happens with a kmem limit.
So it is due to the kmem limiting being broken, as we discussed in the other
"untar" thread lined above.
> The kmem limit would explain allocation failures for ext3 logged below
> but I would be interested about the "Thread overran stack, or stack
> corrupted" message reported for btrfs. The stack doesn't seem very deep
> there. I would expect some issues in the writeback path during the limit
> reclaim but this looks quite innocent. Rulling out kmem accounting would
> be a good first step though . (I am keepinng the full email for Vladimir)
The btrfs problems only occur with a kmem limit. So this is also kmem-linked
even if that is surprising.
Richard.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Richard Davies <richard@arachsys.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-btrfs@vger.kernel.org,
Vladimir Davydov <vdavydov@parallels.com>
Subject: Re: Kernel crash triggered by dd to file with memcg, worst on btrfs
Date: Thu, 24 Apr 2014 11:59:33 +0100 [thread overview]
Message-ID: <20140424105933.GD32011@alpha.arachsys.com> (raw)
In-Reply-To: <20140423215852.GA6651@dhcp22.suse.cz>
Michal Hocko wrote:
> Richard Davies wrote:
> > I have a test case in which I can often crash an entire machine by running
> > dd to a file with a memcg with relatively generous limits. This is
> > simplified from real world problems with heavy disk i/o inside containers.
...
> > [I have also just reported a different but similar bug with untar in a memcg
> > http://marc.info/?l=linux-mm&m=139766321822891 That one is not btrfs-linked]
...
> Does this happen even if no kmem limit is specified?
No, it only happens with a kmem limit.
So it is due to the kmem limiting being broken, as we discussed in the other
"untar" thread lined above.
> The kmem limit would explain allocation failures for ext3 logged below
> but I would be interested about the "Thread overran stack, or stack
> corrupted" message reported for btrfs. The stack doesn't seem very deep
> there. I would expect some issues in the writeback path during the limit
> reclaim but this looks quite innocent. Rulling out kmem accounting would
> be a good first step though . (I am keepinng the full email for Vladimir)
The btrfs problems only occur with a kmem limit. So this is also kmem-linked
even if that is surprising.
Richard.
next prev parent reply other threads:[~2014-04-24 10:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 17:42 Kernel crash triggered by dd to file with memcg, worst on btrfs Richard Davies
2014-04-16 17:42 ` Richard Davies
2014-04-16 17:58 ` Marian Marinov
2014-04-16 17:58 ` Marian Marinov
[not found] ` <534EC4C8.1090106-NV7Lj0SOnH0@public.gmane.org>
2014-04-16 18:05 ` Richard Davies
2014-04-16 18:05 ` Richard Davies
2014-04-16 18:05 ` Richard Davies
2014-04-16 17:58 ` Richard Davies
2014-04-16 17:58 ` Richard Davies
[not found] ` <20140416174210.GA11486-2oeHp4OYwSjPZs67QiJbJtBPR1lH4CV8@public.gmane.org>
2014-04-23 21:58 ` Michal Hocko
2014-04-23 21:58 ` Michal Hocko
2014-04-23 21:58 ` Michal Hocko
2014-04-24 10:59 ` Richard Davies [this message]
2014-04-24 10:59 ` Richard Davies
2014-04-24 12:26 ` Michal Hocko
2014-04-24 12:26 ` Michal Hocko
2014-04-24 12:19 ` Vladimir Davydov
2014-04-24 12:19 ` Vladimir Davydov
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=20140424105933.GD32011@alpha.arachsys.com \
--to=richard@arachsys.com \
--cc=cgroups@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=vdavydov@parallels.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.