All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Michal Hocko <mhocko@kernel.org>, Mike Kravetz <mike.kravetz@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [PATCH v1] mm: hwpoison: disable memory error handling on 1GB hugepage
Date: Tue, 30 Jan 2018 01:39:22 +0000	[thread overview]
Message-ID: <20180130013919.GA19959@hori1.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <a1a921dc-3095-41f7-a4db-0de79bf65f8b@oracle.com>

Hi Michal, Mike,

On Mon, Jan 29, 2018 at 10:08:53AM -0800, Mike Kravetz wrote:
> On 01/29/2018 01:54 AM, Michal Hocko wrote:
> > On Mon 29-01-18 06:30:55, Naoya Horiguchi wrote:
> >> My apology, I forgot to CC to the mailing lists.
> >>
> >> On Mon, Jan 29, 2018 at 03:28:03PM +0900, Naoya Horiguchi wrote:
> >>> Recently the following BUG was reported:
> >>>
> >>>     Injecting memory failure for pfn 0x3c0000 at process virtual address 0x7fe300000000
> >>>     Memory failure: 0x3c0000: recovery action for huge page: Recovered
> >>>     BUG: unable to handle kernel paging request at ffff8dfcc0003000
> >>>     IP: gup_pgd_range+0x1f0/0xc20
> >>>     PGD 17ae72067 P4D 17ae72067 PUD 0
> >>>     Oops: 0000 [#1] SMP PTI
> >>>     ...
> >>>     CPU: 3 PID: 5467 Comm: hugetlb_1gb Not tainted 4.15.0-rc8-mm1-abc+ #3
> >>>     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
> >>>
> >>> You can easily reproduce this by calling madvise(MADV_HWPOISON) twice on
> >>> a 1GB hugepage. This happens because get_user_pages_fast() is not aware
> >>> of a migration entry on pud that was created in the 1st madvise() event.
> > 
> > Do pgd size pages work properly?

PGD size is unsupported now too, and this patch is also disabling that size.

> 
> Adding Anshuman and Aneesh as they added pgd support for power.  And,
> this patch will disable that as well IIUC.

Thanks Mike, I want to have some feedback from PowerPC developers too.

> 
> This patch makes sense for x86.  My only concern/question is for other
> archs which may have huge page sizes defined which are > MAX_ORDER and
> < PUD_SIZE.  These would also be classified as gigantic and impacted
> by this patch.  Do these also have the same issue?

Maybe one clearer way is to use more explicit condition like "page size > PMD_SIZE".

> 
> -- 
> Mike Kravetz
> 
> >>> I think that conversion to pud-aligned migration entry is working,
> >>> but other MM code walking over page table isn't prepared for it.
> >>> We need some time and effort to make all this work properly, so
> >>> this patch avoids the reported bug by just disabling error handling
> >>> for 1GB hugepage.
> > 
> > Can we also get some documentation which would describe all requirements
> > for HWPoison pages to work properly please?

OK, I'll add this.

> > 
> >>> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > 
> > Acked-by: Michal Hocko <mhocko@suse.com>
> > 
> > We probably want a backport to stable as well. Although regular process
> > cannot get giga pages easily without admin help it is still not nice to
> > oops like this.

I'll add CC to stable.

Thanks,
Naoya Horiguchi

WARNING: multiple messages have this Message-ID (diff)
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Michal Hocko <mhocko@kernel.org>, Mike Kravetz <mike.kravetz@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [PATCH v1] mm: hwpoison: disable memory error handling on 1GB hugepage
Date: Tue, 30 Jan 2018 01:39:22 +0000	[thread overview]
Message-ID: <20180130013919.GA19959@hori1.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <a1a921dc-3095-41f7-a4db-0de79bf65f8b@oracle.com>

Hi Michal, Mike,

On Mon, Jan 29, 2018 at 10:08:53AM -0800, Mike Kravetz wrote:
> On 01/29/2018 01:54 AM, Michal Hocko wrote:
> > On Mon 29-01-18 06:30:55, Naoya Horiguchi wrote:
> >> My apology, I forgot to CC to the mailing lists.
> >>
> >> On Mon, Jan 29, 2018 at 03:28:03PM +0900, Naoya Horiguchi wrote:
> >>> Recently the following BUG was reported:
> >>>
> >>>     Injecting memory failure for pfn 0x3c0000 at process virtual address 0x7fe300000000
> >>>     Memory failure: 0x3c0000: recovery action for huge page: Recovered
> >>>     BUG: unable to handle kernel paging request at ffff8dfcc0003000
> >>>     IP: gup_pgd_range+0x1f0/0xc20
> >>>     PGD 17ae72067 P4D 17ae72067 PUD 0
> >>>     Oops: 0000 [#1] SMP PTI
> >>>     ...
> >>>     CPU: 3 PID: 5467 Comm: hugetlb_1gb Not tainted 4.15.0-rc8-mm1-abc+ #3
> >>>     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
> >>>
> >>> You can easily reproduce this by calling madvise(MADV_HWPOISON) twice on
> >>> a 1GB hugepage. This happens because get_user_pages_fast() is not aware
> >>> of a migration entry on pud that was created in the 1st madvise() event.
> > 
> > Do pgd size pages work properly?

PGD size is unsupported now too, and this patch is also disabling that size.

> 
> Adding Anshuman and Aneesh as they added pgd support for power.  And,
> this patch will disable that as well IIUC.

Thanks Mike, I want to have some feedback from PowerPC developers too.

> 
> This patch makes sense for x86.  My only concern/question is for other
> archs which may have huge page sizes defined which are > MAX_ORDER and
> < PUD_SIZE.  These would also be classified as gigantic and impacted
> by this patch.  Do these also have the same issue?

Maybe one clearer way is to use more explicit condition like "page size > PMD_SIZE".

> 
> -- 
> Mike Kravetz
> 
> >>> I think that conversion to pud-aligned migration entry is working,
> >>> but other MM code walking over page table isn't prepared for it.
> >>> We need some time and effort to make all this work properly, so
> >>> this patch avoids the reported bug by just disabling error handling
> >>> for 1GB hugepage.
> > 
> > Can we also get some documentation which would describe all requirements
> > for HWPoison pages to work properly please?

OK, I'll add this.

> > 
> >>> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > 
> > Acked-by: Michal Hocko <mhocko@suse.com>
> > 
> > We probably want a backport to stable as well. Although regular process
> > cannot get giga pages easily without admin help it is still not nice to
> > oops like this.

I'll add CC to stable.

Thanks,
Naoya Horiguchi
--
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:[~2018-01-30  1:40 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1517207283-15769-1-git-send-email-n-horiguchi@ah.jp.nec.com>
2018-01-29  6:30 ` [PATCH v1] mm: hwpoison: disable memory error handling on 1GB hugepage Naoya Horiguchi
2018-01-29  6:30   ` Naoya Horiguchi
2018-01-29  9:54   ` Michal Hocko
2018-01-29  9:54     ` Michal Hocko
2018-01-29 18:08     ` Mike Kravetz
2018-01-29 18:08       ` Mike Kravetz
2018-01-30  1:39       ` Naoya Horiguchi [this message]
2018-01-30  1:39         ` Naoya Horiguchi
2018-01-30  3:54         ` [PATCH v2] " Naoya Horiguchi
2018-01-30  3:54           ` Naoya Horiguchi
2018-01-30 23:56           ` Mike Kravetz
2018-01-30 23:56             ` Mike Kravetz
2018-02-05 15:05           ` Punit Agrawal
2018-02-05 15:05             ` Punit Agrawal
2018-02-07  1:14             ` Naoya Horiguchi
2018-02-07  1:14               ` Naoya Horiguchi
2018-02-08 12:30               ` Punit Agrawal
2018-02-08 12:30                 ` Punit Agrawal
2018-02-08 20:17                 ` Andrew Morton
2018-02-08 20:17                   ` Andrew Morton
2018-02-09 11:06                   ` Punit Agrawal
2018-02-13  2:48                   ` Michael Ellerman
2018-02-13  2:48                     ` Michael Ellerman
2018-02-13 22:33                     ` Mike Kravetz
2018-02-13 22:33                       ` Mike Kravetz
2019-05-28  9:49                       ` Wanpeng Li
2019-05-28  9:49                         ` Wanpeng Li
2019-05-28  9:49                         ` Wanpeng Li
2019-05-29 23:31                         ` Mike Kravetz
2019-05-29 23:31                           ` Mike Kravetz
2019-06-10 23:50                           ` Naoya Horiguchi
2019-06-10 23:50                             ` Naoya Horiguchi
2019-06-11  8:42                             ` Wanpeng Li
2019-06-11  8:42                               ` Wanpeng Li
2019-06-11  8:42                               ` Wanpeng Li
2019-08-20  7:03                             ` Wanpeng Li
2019-08-20  7:03                               ` Wanpeng Li
2019-08-20  7:03                               ` Wanpeng Li
2019-08-21  5:39                               ` ##freemail## " Naoya Horiguchi
2019-08-21  5:39                                 ` Naoya Horiguchi
2019-08-21  7:15                                 ` Wanpeng Li
2019-08-21  7:15                                   ` Wanpeng Li
2019-08-21  7:15                                   ` Wanpeng Li
2018-02-09  1:17                 ` Naoya Horiguchi
2018-02-09  1:17                   ` Naoya Horiguchi
2018-02-13 19:01                   ` Punit Agrawal

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=20180130013919.GA19959@hori1.linux.bs1.fc.nec.co.jp \
    --to=n-horiguchi@ah.jp.nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@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.