All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Ying <ying.huang@intel.com>
To: lkp@lists.01.org
Subject: Re: [mm] cc87317726f: WARNING: CPU: 0 PID: 1 atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380()
Date: Thu, 19 Mar 2015 09:57:02 +0800	[thread overview]
Message-ID: <1426730222.5570.41.camel@intel.com> (raw)
In-Reply-To: <201503182045.DEC48482.OtSOQOLVFFHFJM@I-love.SAKURA.ne.jp>

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

On Wed, 2015-03-18 at 20:45 +0900, Tetsuo Handa wrote:
> Huang Ying wrote:
> > On Tue, 2015-03-17 at 15:24 -0400, Johannes Weiner wrote:
> > > On Tue, Mar 17, 2015 at 10:15:29AM -0700, Linus Torvalds wrote:
> > > > Explicitly adding the emails of other people involved with that commit
> > > > and the original oom thread to make sure people are aware, since this
> > > > didn't get any response.
> > > > 
> > > > Commit cc87317726f8 fixed some behavior, but also seems to have turned
> > > > an oom situation into a complete hang. So presumably we shouldn't loop
> > > > *forever*. Hmm?
> > > 
> > > It seems we are between a rock and a hard place here, as we reverted
> > > specifically to that endless looping on request of filesystem people.
> > > They said[1] they rely on these allocations never returning NULL, or
> > > they might fail inside a transactions and corrupt on-disk data.
> > > 
> > > Huang, against which kernels did you first run this test on this exact
> > > setup?  Is there a chance you could try to run a kernel without/before
> > > 9879de7373fc?  I want to make sure I'm not missing something, but all
> > > versions preceding this commit should also have the same hang.  There
> > > should only be a tiny window between 9879de7373fc and cc87317726f8 --
> > > v3.19 -- where these allocations are allowed to fail.
> > 
> > I checked the test result of v3.19-rc6.  It shows that boot will hang at
> > the same position.
> 
> OK. That's the expected result. We are discussing about how to safely
> allow small allocations to fail, including how to handle stalls caused by
> allocations without __GFP_FS.
> 
> > 
> > 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?

Best Regards,
Huang, Ying



WARNING: multiple messages have this Message-ID (diff)
From: Huang Ying <ying.huang@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: hannes@cmpxchg.org, torvalds@linux-foundation.org,
	mhocko@suse.cz, 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: 1 atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380()
Date: Thu, 19 Mar 2015 09:57:02 +0800	[thread overview]
Message-ID: <1426730222.5570.41.camel@intel.com> (raw)
In-Reply-To: <201503182045.DEC48482.OtSOQOLVFFHFJM@I-love.SAKURA.ne.jp>

On Wed, 2015-03-18 at 20:45 +0900, Tetsuo Handa wrote:
> Huang Ying wrote:
> > On Tue, 2015-03-17 at 15:24 -0400, Johannes Weiner wrote:
> > > On Tue, Mar 17, 2015 at 10:15:29AM -0700, Linus Torvalds wrote:
> > > > Explicitly adding the emails of other people involved with that commit
> > > > and the original oom thread to make sure people are aware, since this
> > > > didn't get any response.
> > > > 
> > > > Commit cc87317726f8 fixed some behavior, but also seems to have turned
> > > > an oom situation into a complete hang. So presumably we shouldn't loop
> > > > *forever*. Hmm?
> > > 
> > > It seems we are between a rock and a hard place here, as we reverted
> > > specifically to that endless looping on request of filesystem people.
> > > They said[1] they rely on these allocations never returning NULL, or
> > > they might fail inside a transactions and corrupt on-disk data.
> > > 
> > > Huang, against which kernels did you first run this test on this exact
> > > setup?  Is there a chance you could try to run a kernel without/before
> > > 9879de7373fc?  I want to make sure I'm not missing something, but all
> > > versions preceding this commit should also have the same hang.  There
> > > should only be a tiny window between 9879de7373fc and cc87317726f8 --
> > > v3.19 -- where these allocations are allowed to fail.
> > 
> > I checked the test result of v3.19-rc6.  It shows that boot will hang at
> > the same position.
> 
> OK. That's the expected result. We are discussing about how to safely
> allow small allocations to fail, including how to handle stalls caused by
> allocations without __GFP_FS.
> 
> > 
> > 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?

Best Regards,
Huang, Ying


--
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: Huang Ying <ying.huang@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: hannes@cmpxchg.org, torvalds@linux-foundation.org,
	mhocko@suse.cz, 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: 1 atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380()
Date: Thu, 19 Mar 2015 09:57:02 +0800	[thread overview]
Message-ID: <1426730222.5570.41.camel@intel.com> (raw)
In-Reply-To: <201503182045.DEC48482.OtSOQOLVFFHFJM@I-love.SAKURA.ne.jp>

On Wed, 2015-03-18 at 20:45 +0900, Tetsuo Handa wrote:
> Huang Ying wrote:
> > On Tue, 2015-03-17 at 15:24 -0400, Johannes Weiner wrote:
> > > On Tue, Mar 17, 2015 at 10:15:29AM -0700, Linus Torvalds wrote:
> > > > Explicitly adding the emails of other people involved with that commit
> > > > and the original oom thread to make sure people are aware, since this
> > > > didn't get any response.
> > > > 
> > > > Commit cc87317726f8 fixed some behavior, but also seems to have turned
> > > > an oom situation into a complete hang. So presumably we shouldn't loop
> > > > *forever*. Hmm?
> > > 
> > > It seems we are between a rock and a hard place here, as we reverted
> > > specifically to that endless looping on request of filesystem people.
> > > They said[1] they rely on these allocations never returning NULL, or
> > > they might fail inside a transactions and corrupt on-disk data.
> > > 
> > > Huang, against which kernels did you first run this test on this exact
> > > setup?  Is there a chance you could try to run a kernel without/before
> > > 9879de7373fc?  I want to make sure I'm not missing something, but all
> > > versions preceding this commit should also have the same hang.  There
> > > should only be a tiny window between 9879de7373fc and cc87317726f8 --
> > > v3.19 -- where these allocations are allowed to fail.
> > 
> > I checked the test result of v3.19-rc6.  It shows that boot will hang at
> > the same position.
> 
> OK. That's the expected result. We are discussing about how to safely
> allow small allocations to fail, including how to handle stalls caused by
> allocations without __GFP_FS.
> 
> > 
> > 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?

Best Regards,
Huang, Ying



  reply	other threads:[~2015-03-19  1:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13  6:20 [mm] cc87317726f: WARNING: CPU: 0 PID: 1 at drivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380() Huang Ying
2015-03-13  6:20 ` [LKP] " Huang Ying
2015-03-17 17:15 ` Linus Torvalds
2015-03-17 17:15   ` [LKP] " Linus Torvalds
2015-03-17 17:15   ` Linus Torvalds
2015-03-17 17:28   ` Michal Hocko
2015-03-17 17:28     ` [LKP] " Michal Hocko
2015-03-17 17:28     ` Michal Hocko
2015-03-17 19:24   ` Johannes Weiner
2015-03-17 19:24     ` [LKP] " Johannes Weiner
2015-03-17 19:24     ` Johannes Weiner
2015-03-18  1:53     ` Huang Ying
2015-03-18  1:53       ` [LKP] " Huang Ying
2015-03-18  1:53       ` Huang Ying
2015-03-18 11:45       ` [mm] cc87317726f: WARNING: CPU: 0 PID: 1 atdrivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380() Tetsuo Handa
2015-03-18 11:45         ` [LKP] " Tetsuo Handa
2015-03-18 11:45         ` Tetsuo Handa
2015-03-19  1:57         ` Huang Ying [this message]
2015-03-19  1:57           ` Huang Ying
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:34             ` Tetsuo Handa
2015-03-20 13:38             ` Michal Hocko
2015-03-20 13:38               ` [LKP] " Michal Hocko
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:02                 ` Tetsuo Handa
2015-03-20 14:34                 ` Michal Hocko
2015-03-20 14:34                   ` [LKP] " Michal Hocko
2015-03-20 14:34                   ` Michal Hocko
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
2015-03-20 15:41                     ` 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=1426730222.5570.41.camel@intel.com \
    --to=ying.huang@intel.com \
    --cc=lkp@lists.01.org \
    /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.