linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: ying.huang@intel.com, hannes@cmpxchg.org,
	torvalds@linux-foundation.org, rientjes@google.com,
	akpm@linux-foundation.org, david@fromorbit.com,
	linux-kernel@vger.kernel.org, lkp@01.org, linux-mm@kvack.org
Subject: Re: [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID:1atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380()
Date: Fri, 20 Mar 2015 15:34:10 +0100	[thread overview]
Message-ID: <20150320143410.GD4821@dhcp22.suse.cz> (raw)
In-Reply-To: <201503202302.EDF82384.OtFVHMFOLSJOFQ@I-love.SAKURA.ne.jp>

On Fri 20-03-15 23:02:09, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 20-03-15 22:34:21, Tetsuo Handa wrote:
> > > Huang Ying wrote:
> > > > > > BTW: the test is run on 32 bit system.
> > > > > 
> > > > > That sounds like the cause of your problem. The system might be out of
> > > > > address space available for the kernel (only 1GB if x86_32). You should
> > > > > try running tests on 64 bit systems.
> > > > 
> > > > We run test on 32 bit and 64 bit systems.  Try to catch problems on both
> > > > platforms.  I think we still need to support 32 bit systems?
> > > 
> > > Yes, testing on both platforms is good. But please read
> > > http://lwn.net/Articles/627419/ , http://lwn.net/Articles/635354/ and
> > > http://lwn.net/Articles/636017/ . Then please add __GFP_NORETRY to memory
> > > allocations in btrfs code if it is appropriate.
> > 
> > I guess you meant __GFP_NOFAIL?
> > 
> No. btrfs's selftest (which is not using __GFP_NOFAIL) is already looping
> forever. If we want to avoid btrfs's selftest from looping forever, btrfs
> needs __GFP_NORETRY than __GFP_NOFAIL (until we establish a way to safely
> allow small allocations to fail).

Sigh. If the code is using GFP_NOFS allocation (which seem to be the
case because it worked with the 9879de7373fc) and the proper fix for
this IMO is to simply not retry endlessly for these allocations.  We
have to sort some other issues before we can make NOFS allocations fail
but let's not pile more workarounds on top in the meantime. But if btrfs
people really think __GFP_NORETRY then I do not really care much.
-- 
Michal Hocko
SUSE Labs

--
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>

  reply	other threads:[~2015-03-20 14:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1426227621.6711.238.camel@intel.com>
2015-03-17 17:15 ` [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID: 1 at drivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380() Linus Torvalds
2015-03-17 17:28   ` Michal Hocko
2015-03-17 19:24   ` Johannes Weiner
2015-03-18  1:53     ` Huang Ying
2015-03-18 11:45       ` [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID: 1 atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380() Tetsuo Handa
2015-03-19  1:57         ` Huang Ying
2015-03-20 13:34           ` [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID: 1atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380() Tetsuo Handa
2015-03-20 13:38             ` Michal Hocko
2015-03-20 14:02               ` [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID:1atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380() Tetsuo Handa
2015-03-20 14:34                 ` Michal Hocko [this message]
2015-03-20 15:41                   ` [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID: 1 at drivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380() Tetsuo Handa

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=20150320143410.GD4821@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@01.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.huang@intel.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).