All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.com>
Cc: "ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"Mulumudi, Abhilash Kumar  <m.abhilash-kumar@hpe.com>,
	linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"brian.starkey@arm.com" <brian.starkey@arm.com>
Subject: Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
Date: Wed, 24 Aug 2016 14:40:07 +0000	[thread overview]
Message-ID: <1472049570.1532.10.camel@hpe.com> (raw)
In-Reply-To: <CAPcyv4hZEU3bnpiSCr3KFxF+MiGDGzB5NdopWkFB5CWazD1pkw@mail.gmail.com>

On Tue, 2016-08-23 at 21:48 -0700, Dan Williams wrote:
> On Tue, Aug 23, 2016 at 9:28 PM, Kani, Toshimitsu <toshi.kani@hpe.com
> > 
> > BTW, why does devm_memremap_pages() put a whole range to
> > pgmap_radix as device memory, but only initialize page->pgmap for
> > its data range?  Is there particular reason for this inconsistency?
>
> The radix tree is indexed by section number, but we don't always
> initialize a full section.  The cases when we don't use a full
> section is when it overlaps device metadata, or if a platform
> multiplexes the device memory range with another resource within the
> same section.

I see, but I still feel odd about making get_dev_pagemap() to work for
metadata, but get_page() -> get_zone_device_page() to crash like this.
 follow_devmap_pmd() assumes get_page() to work when get_dev_pagemap()
returns a valid pgmap...

Thanks,
-Toshi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.com>
Cc: "Mulumudi, Abhilash Kumar" <m.abhilash-kumar@hpe.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"brian.starkey@arm.com" <brian.starkey@arm.com>
Subject: Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
Date: Wed, 24 Aug 2016 14:40:07 +0000	[thread overview]
Message-ID: <1472049570.1532.10.camel@hpe.com> (raw)
In-Reply-To: <CAPcyv4hZEU3bnpiSCr3KFxF+MiGDGzB5NdopWkFB5CWazD1pkw@mail.gmail.com>

On Tue, 2016-08-23 at 21:48 -0700, Dan Williams wrote:
> On Tue, Aug 23, 2016 at 9:28 PM, Kani, Toshimitsu <toshi.kani@hpe.com
> > 
> > BTW, why does devm_memremap_pages() put a whole range to
> > pgmap_radix as device memory, but only initialize page->pgmap for
> > its data range?  Is there particular reason for this inconsistency?
>
> The radix tree is indexed by section number, but we don't always
> initialize a full section.  The cases when we don't use a full
> section is when it overlaps device metadata, or if a platform
> multiplexes the device memory range with another resource within the
> same section.

I see, but I still feel odd about making get_dev_pagemap() to work for
metadata, but get_page() -> get_zone_device_page() to crash like this.
 follow_devmap_pmd() assumes get_page() to work when get_dev_pagemap()
returns a valid pgmap...

Thanks,
-Toshi

  reply	other threads:[~2016-08-24 14:40 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 18:43 [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page() Toshi Kani
2016-08-23 18:43 ` Toshi Kani
     [not found] ` <1471977800-12688-1-git-send-email-toshi.kani-ZPxbGqLxI0U@public.gmane.org>
2016-08-23 20:42   ` Andrew Morton
2016-08-23 20:42     ` Andrew Morton
     [not found]     ` <20160823134216.8f8e8944581fe1ae202377d1-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2016-08-23 21:25       ` Kani, Toshimitsu
2016-08-23 21:25         ` Kani, Toshimitsu
2016-08-23 22:32 ` Dan Williams
2016-08-23 22:32   ` Dan Williams
2016-08-23 23:47   ` Kani, Toshimitsu
2016-08-23 23:47     ` Kani, Toshimitsu
2016-08-24  0:34     ` Dan Williams
2016-08-24  0:34       ` Dan Williams
2016-08-24  1:29       ` Kani, Toshimitsu
2016-08-24  1:29         ` Kani, Toshimitsu
2016-08-24  2:53         ` Dan Williams
2016-08-24  2:53           ` Dan Williams
2016-08-24  3:58           ` Dan Williams
2016-08-24  3:58             ` Dan Williams
2016-08-24  4:28             ` Kani, Toshimitsu
2016-08-24  4:28               ` Kani, Toshimitsu
2016-08-24  4:48               ` Dan Williams
2016-08-24  4:48                 ` Dan Williams
2016-08-24 14:40                 ` Kani, Toshimitsu [this message]
2016-08-24 14:40                   ` Kani, Toshimitsu
2016-08-24 14:55                   ` Dan Williams
2016-08-24 14:55                     ` Dan Williams
2016-08-24  5:48             ` Dan Williams
2016-08-24  5:48               ` Dan Williams
2016-08-24 15:21               ` Kani, Toshimitsu
2016-08-24 15:21                 ` Kani, Toshimitsu
2016-08-24  1:00     ` Dan Williams
2016-08-24  1:00       ` Dan Williams
2016-08-24  1:38       ` Kani, Toshimitsu
2016-08-24  1:38         ` Kani, Toshimitsu

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=1472049570.1532.10.camel@hpe.com \
    --to=toshi.kani@hpe.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=brian.starkey@arm.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@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.