mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Toshi Kani <toshi.kani@hpe.com>
To: Borislav Petkov <bp@alien8.de>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	henning.schild@siemens.com, linux-nvdimm@ml01.01.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86/mm/vmfault: Make vmalloc_fault() handle large pages
Date: Tue, 16 Feb 2016 08:21:48 -0700	[thread overview]
Message-ID: <1455636108.2925.135.camel@hpe.com> (raw)
In-Reply-To: <20160213115418.GB15973@pd.tnic>

On Sat, 2016-02-13 at 12:54 +0100, Borislav Petkov wrote:
> On Thu, Feb 11, 2016 at 05:27:16PM -0700, Toshi Kani wrote:
> > The following oops was observed when a read syscall was made to
> > a pmem device after a huge amount (>512GB) of vmalloc ranges was
> > allocated by ioremap() on a x86_64 system.
> > 
> >  BUG: unable to handle kernel paging request at ffff880840000ff8
> >  IP: [<ffffffff810664ae>] vmalloc_fault+0x1be/0x300
> >  PGD c7f03a067 PUD 0
> >  Oops: 0000 [#1] SM
> >    :
> >  Call Trace:
> >  [<ffffffff81067335>] __do_page_fault+0x285/0x3e0
> >  [<ffffffff810674bf>] do_page_fault+0x2f/0x80
> >  [<ffffffff810d6d85>] ? put_prev_entity+0x35/0x7a0
> >  [<ffffffff817a6888>] page_fault+0x28/0x30
> >  [<ffffffff813bb976>] ? memcpy_erms+0x6/0x10
> >  [<ffffffff817a0845>] ? schedule+0x35/0x80
> >  [<ffffffffa006350a>] ? pmem_rw_bytes+0x6a/0x190 [nd_pmem]
> >  [<ffffffff817a3713>] ? schedule_timeout+0x183/0x240
> >  [<ffffffffa028d2b3>] btt_log_read+0x63/0x140 [nd_btt]
> >    :
> >  [<ffffffff811201d0>] ? __symbol_put+0x60/0x60
> >  [<ffffffff8122dc60>] ? kernel_read+0x50/0x80
> >  [<ffffffff81124489>] SyS_finit_module+0xb9/0xf0
> >  [<ffffffff817a4632>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> 
> Please remove those virtual addresses and offsets here as they're
> meaningless and leave only the callstack.

Will do.

 :
> > ---
> > When this patch is accepted, please copy to stable up to 4.1.
> 
> You can do that yourself when submitting by adding this to the CC-list
> above.
> 
> Cc: <stable@vger.kernel.org> # 4.1..

I see.  I will add it to the next version.

> Rest looks ok to me.

Great!  Thanks,
-Toshi

      reply	other threads:[~2016-02-16 14:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12  0:27 Toshi Kani
2016-02-13 11:54 ` Borislav Petkov
2016-02-16 15:21   ` Toshi Kani [this message]

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=1455636108.2925.135.camel@hpe.com \
    --to=toshi.kani@hpe.com \
    --cc=bp@alien8.de \
    --cc=henning.schild@siemens.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®