Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1258626 > unrolled thread
| Started by | "Williams, Dan J" <dan.j.williams@intel.com> |
|---|---|
| First post | 2015-10-29 09:10 +0100 |
| Last post | 2015-10-29 21:10 +0100 |
| Articles | 4 — 4 participants |
Back to article view | Back to linux.kernel
[GIT PULL] memremap fix for 4.3 "Williams, Dan J" <dan.j.williams@intel.com> - 2015-10-29 09:10 +0100
Re: [GIT PULL] memremap fix for 4.3 Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-10-29 14:00 +0100
Re: [GIT PULL] memremap fix for 4.3 Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-29 18:20 +0100
Re: [GIT PULL] memremap fix for 4.3 Dan Williams <dan.j.williams@intel.com> - 2015-10-29 21:10 +0100
| From | "Williams, Dan J" <dan.j.williams@intel.com> |
|---|---|
| Date | 2015-10-29 09:10 +0100 |
| Subject | [GIT PULL] memremap fix for 4.3 |
| Message-ID | <qoQrv-66j-3@gated-at.bofh.it> |
SGkgTGludXMsIHBsZWFzZSBwdWxsIGZyb206DQoNCiAgZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHVi L3NjbS9saW51eC9rZXJuZWwvZ2l0L252ZGltbS9udmRpbW0gbGlibnZkaW1tLWZpeGVzDQoNCi4u LnRvIHJlY2VpdmUgYSBzbWFsbCBmaXhsZXQgZm9yIDQuMy4NCg0KVGhlIG5ldyBtZW1yZW1hcCgp IGFwaSBpbnRyb2R1Y2VkIGluIHRoZSA0LjMgY3ljbGUgdG8gdW5pZnkvcmVwbGFjZQ0KaW9yZW1h cF9jYWNoZSgpIGFuZCBpb3JlbWFwX3d0KCkgaXMgbWlzaGFuZGxpbmcgdGhlIGhpZ2htZW0gY2Fz ZS4gIFRoaXMNCnBhdGNoIGhhcyByZWNlaXZlZCBhIGJ1aWxkIHN1Y2Nlc3Mgbm90aWZpY2F0aW9u IGZyb20gYSAwZGF5LWtidWlsZC1yb2JvdA0KcnVuIGFuZCBoYXMgYmVlbiBvdXQgZm9yIGEgcmV2 aWV3IGZvciBhIGRheS4gIFJ1c3NlbGwgaGFzIG5vdCBoYWQgYQ0KY2hhbmNlIHRvIHdlaWdoIGlu IG9uIGl0IHlldC4NCg0KSSBkbyBub3QgdGhpbmsgdGhlIHVzYWdlIG9mIGttYXAgaXMgc3RyaWN0 bHkgbmVjZXNzYXJ5IGFzIHdlIHNob3VsZCBiZQ0KYWJsZSB0byBmYWxsIGJhY2sgdG8gaW9yZW1h cF9jYWNoZSgpLCBidXQgSSBpbmNsdWRlIGl0IGZvciB0d28gcmVhc29uczoNCg0KMS8gQVJNIGlv cmVtYXAoKSB3aWxsIFdBUk4gaWYgcGFzc2VkIGEgcGZuX3ZhbGlkKCkgYWRkcmVzcy4NCg0KMi8g YWNwaV9tYXAoKSBjYXJyaWVzIGEgc2ltaWxhciBrbWFwIGZhbGxiYWNrLCBhbmQgdGhhdCBxdWly ayBjYW4gbm93IGJlDQpjZW50cmFsbHkgY2FycmllZCBpbiB0aGlzIGNvbW1vbiByb3V0aW5lLg0K DQoNCi0tLQ0KDQpUaGUgZm9sbG93aW5nIGNoYW5nZXMgc2luY2UgY29tbWl0IDI1Y2I2MmI3NjQz MGE5MWNjNjE5NWY5MDJlNjFjMmNiODRhZGU2MjI6DQoNCiAgTGludXggNC4zLXJjNSAoMjAxNS0x MC0xMSAxMTowOTo0NSAtMDcwMCkNCg0KYXJlIGF2YWlsYWJsZSBpbiB0aGUgZ2l0IHJlcG9zaXRv cnkgYXQ6DQoNCiAgZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0 L252ZGltbS9udmRpbW0gbGlibnZkaW1tLWZpeGVzDQoNCmZvciB5b3UgdG8gZmV0Y2ggY2hhbmdl cyB1cCB0byBiY2FhNDIzNmI1NTgwOTJkZDVmZjE0ZWE5NDNlODlmZDk0NGZjZDI4Og0KDQogIG1l bXJlbWFwOiBmaXggaGlnaG1lbSBzdXBwb3J0ICgyMDE1LTEwLTI2IDE2OjU1OjU2IC0wNDAwKQ0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpEYW4gV2lsbGlhbXMgKDEpOg0KICAgICAgbWVtcmVtYXA6IGZpeCBoaWdobWVt IHN1cHBvcnQNCg0KIGluY2x1ZGUvbGludXgvaGlnaG1lbS5oIHwgMTIgKysrKysrKysrKysrDQog a2VybmVsL21lbXJlbWFwLmMgICAgICAgfCAyOCArKysrKysrKysrKysrKysrKysrKysrKysrLS0t DQogMiBmaWxlcyBjaGFuZ2VkLCAzNyBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQ0KDQpj b21taXQgYmNhYTQyMzZiNTU4MDkyZGQ1ZmYxNGVhOTQzZTg5ZmQ5NDRmY2QyOA0KQXV0aG9yOiBE YW4gV2lsbGlhbXMgPGRhbi5qLndpbGxpYW1zQGludGVsLmNvbT4NCkRhdGU6ICAgTW9uIE9jdCAy NiAxNjo1NTo1NiAyMDE1IC0wNDAwDQoNCiAgICBtZW1yZW1hcDogZml4IGhpZ2htZW0gc3VwcG9y dA0KICAgIA0KICAgIEN1cnJlbnRseSBtZW1yZW1hcCBjaGVja3MgaWYgdGhlIHJhbmdlIGlzICJT eXN0ZW0gUkFNIiBhbmQgcmV0dXJucyB0aGUNCiAgICBrZXJuZWwgbGluZWFyIGFkZHJlc3MuICBU aGlzIGlzIGJyb2tlbiBmb3IgaGlnaG1lbSBwbGF0Zm9ybXMgd2hlcmUgYQ0KICAgIHJhbmdlIG1h eSBiZSAiU3lzdGVtIFJBTSIsIGJ1dCBpcyBub3QgcGFydCBvZiB0aGUga2VybmVsIGxpbmVhciBt YXBwaW5nLg0KICAgIFNpbWlsYXIgdG8gYWNwaV9tYXAoKSwgdXNlIGttYXAoKSBmb3IgUEFHRV9T SVpFIG1lbXJlbWFwKCkgcmVxdWVzdHMgZm9yDQogICAgaGlnaG1lbSwgYW5kIGZhbGwgYmFjayB0 byBpb3JlbWFwX2NhY2hlKCkgb3RoZXJ3aXNlLg0KICAgIA0KICAgIFRoZSBpbXBhY3Qgb2YgdGhp cyBidWcgaXMgbG93IGZvciBub3cgc2luY2UgdGhlIHBtZW0gZHJpdmVyIGlzIHRoZSBvbmx5DQog ICAgdXNlciBvZiBtZW1yZW1hcCgpLCBidXQgdGhpcyBpcyBpbXBvcnRhbnQgdG8gZml4IGJlZm9y ZSBtb3JlIGNvbnZlcnNpb25zDQogICAgdG8gbWVtcmVtYXAgYXJyaXZlIGluIDQuNC4NCiAgICAN CiAgICBDYzogUmFmYWVsIEouIFd5c29ja2kgPHJhZmFlbC5qLnd5c29ja2lAaW50ZWwuY29tPg0K ICAgIFJlcG9ydGVkLWJ5OiBBcmQgQmllc2hldXZlbCA8YXJkLmJpZXNoZXV2ZWxAbGluYXJvLm9y Zz4NCiAgICBTaWduZWQtb2ZmLWJ5OiBEYW4gV2lsbGlhbXMgPGRhbi5qLndpbGxpYW1zQGludGVs LmNvbT4NCg0KZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvaGlnaG1lbS5oIGIvaW5jbHVkZS9s aW51eC9oaWdobWVtLmgNCmluZGV4IDZhZWZjZDAwMzFhNi4uYzIwY2YyNGM3NmRkIDEwMDY0NA0K LS0tIGEvaW5jbHVkZS9saW51eC9oaWdobWVtLmgNCisrKyBiL2luY2x1ZGUvbGludXgvaGlnaG1l bS5oDQpAQCAtNDEsNiArNDEsMTMgQEAgdm9pZCBrbWFwX2ZsdXNoX3VudXNlZCh2b2lkKTsNCiAN CiBzdHJ1Y3QgcGFnZSAqa21hcF90b19wYWdlKHZvaWQgKmFkZHIpOw0KIA0KK3N0YXRpYyBpbmxp bmUgYm9vbCBpc19rbWFwX2FkZHIoY29uc3Qgdm9pZCAqeCkNCit7DQorCXVuc2lnbmVkIGxvbmcg YWRkciA9ICh1bnNpZ25lZCBsb25nKSB4Ow0KKw0KKwlyZXR1cm4gYWRkciA+PSBQS01BUF9BRERS KDApICYmIGFkZHIgPCBQS01BUF9BRERSKExBU1RfUEtNQVApOw0KK30NCisNCiAjZWxzZSAvKiBD T05GSUdfSElHSE1FTSAqLw0KIA0KIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IG5yX2ZyZWVf aGlnaHBhZ2VzKHZvaWQpIHsgcmV0dXJuIDA7IH0NCkBAIC01MCw2ICs1NywxMSBAQCBzdGF0aWMg aW5saW5lIHN0cnVjdCBwYWdlICprbWFwX3RvX3BhZ2Uodm9pZCAqYWRkcikNCiAJcmV0dXJuIHZp cnRfdG9fcGFnZShhZGRyKTsNCiB9DQogDQorc3RhdGljIGlubGluZSBib29sIGlzX2ttYXBfYWRk cihjb25zdCB2b2lkICp4KQ0KK3sNCisJcmV0dXJuIGZhbHNlOw0KK30NCisNCiAjZGVmaW5lIHRv dGFsaGlnaF9wYWdlcyAwVUwNCiANCiAjaWZuZGVmIEFSQ0hfSEFTX0tNQVANCmRpZmYgLS1naXQg YS9rZXJuZWwvbWVtcmVtYXAuYyBiL2tlcm5lbC9tZW1yZW1hcC5jDQppbmRleCA3MmIwYzY2NjI4 YjYuLjkwMWQ3ZWMzNTgzYSAxMDA2NDQNCi0tLSBhL2tlcm5lbC9tZW1yZW1hcC5jDQorKysgYi9r ZXJuZWwvbWVtcmVtYXAuYw0KQEAgLTEwLDYgKzEwLDcgQEANCiAgKiBNRVJDSEFOVEFCSUxJVFkg b3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQ0KICAqIEdl bmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4NCiAgKi8NCisjaW5jbHVkZSA8 bGludXgvaGlnaG1lbS5oPg0KICNpbmNsdWRlIDxsaW51eC9kZXZpY2UuaD4NCiAjaW5jbHVkZSA8 bGludXgvdHlwZXMuaD4NCiAjaW5jbHVkZSA8bGludXgvaW8uaD4NCkBAIC0yNCw2ICsyNSwyNSBA QCBfX3dlYWsgdm9pZCBfX2lvbWVtICppb3JlbWFwX2NhY2hlKHJlc291cmNlX3NpemVfdCBvZmZz ZXQsIHVuc2lnbmVkIGxvbmcgc2l6ZSkNCiB9DQogI2VuZGlmDQogDQorc3RhdGljIHZvaWQgKnRy eV9yYW1fcmVtYXAocmVzb3VyY2Vfc2l6ZV90IG9mZnNldCwgc2l6ZV90IHNpemUpDQorew0KKwlz dHJ1Y3QgcGFnZSAqcGFnZSA9IHBmbl90b19wYWdlKG9mZnNldCA+PiBQQUdFX1NISUZUKTsNCisJ dW5zaWduZWQgaW50IHBnX29mZiA9IG9mZnNldCAmIH5QQUdFX01BU0s7DQorDQorCS8qIEluIHRo ZSBzaW1wbGUgY2FzZSBqdXN0IHJldHVybiB0aGUgZXhpc3RpbmcgbGluZWFyIGFkZHJlc3MgKi8N CisJaWYgKCFQYWdlSGlnaE1lbShwYWdlKSkNCisJCXJldHVybiBfX3ZhKG9mZnNldCk7DQorDQor CS8qDQorCSAqIFRyeSBrbWFwIGZpcnN0IHNpbmNlIHNvbWUgYXJjaCBpb3JlbWFwIGltcGxlbWVu dGF0aW9ucyBmYWlsIHdoZW4NCisJICogYmVpbmcgcGFzc2VkIGEgcmFtIGFkZHJlc3MuDQorCSAq Lw0KKwlpZiAocGdfb2ZmICsgc2l6ZSA8PSBQQUdFX1NJWkUpDQorCQlyZXR1cm4ga21hcChwYWdl KSArIHBnX29mZjsNCisNCisJcmV0dXJuIE5VTEw7DQorfQ0KKw0KIC8qKg0KICAqIG1lbXJlbWFw KCkgLSByZW1hcCBhbiBpb21lbV9yZXNvdXJjZSBhcyBjYWNoZWFibGUgbWVtb3J5DQogICogQG9m ZnNldDogaW9tZW0gcmVzb3VyY2Ugc3RhcnQgYWRkcmVzcw0KQEAgLTY2LDggKzg2LDggQEAgdm9p ZCAqbWVtcmVtYXAocmVzb3VyY2Vfc2l6ZV90IG9mZnNldCwgc2l6ZV90IHNpemUsIHVuc2lnbmVk IGxvbmcgZmxhZ3MpDQogCQkgKiB0aGUgcmVxdWVzdGVkIHJhbmdlIGlzIHBvdGVudGlhbGx5IGlu ICJTeXN0ZW0gUkFNIg0KIAkJICovDQogCQlpZiAoaXNfcmFtID09IFJFR0lPTl9JTlRFUlNFQ1RT KQ0KLQkJCWFkZHIgPSBfX3ZhKG9mZnNldCk7DQotCQllbHNlDQorCQkJYWRkciA9IHRyeV9yYW1f cmVtYXAob2Zmc2V0LCBzaXplKTsNCisJCWlmICghYWRkcikNCiAJCQlhZGRyID0gaW9yZW1hcF9j YWNoZShvZmZzZXQsIHNpemUpOw0KIAl9DQogDQpAQCAtOTQsNyArMTE0LDkgQEAgRVhQT1JUX1NZ TUJPTChtZW1yZW1hcCk7DQogDQogdm9pZCBtZW11bm1hcCh2b2lkICphZGRyKQ0KIHsNCi0JaWYg KGlzX3ZtYWxsb2NfYWRkcihhZGRyKSkNCisJaWYgKGlzX2ttYXBfYWRkcihhZGRyKSkNCisJCWt1 bm1hcChhZGRyKTsNCisJZWxzZSBpZiAoaXNfdm1hbGxvY19hZGRyKGFkZHIpKQ0KIAkJaW91bm1h cCgodm9pZCBfX2lvbWVtICopIGFkZHIpOw0KIH0NCiBFWFBPUlRfU1lNQk9MKG1lbXVubWFwKTsN Cg0K -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Ard Biesheuvel <ard.biesheuvel@linaro.org> |
|---|---|
| Date | 2015-10-29 14:00 +0100 |
| Message-ID | <qoUYa-gQ-1@gated-at.bofh.it> |
| In reply to | #1258626 |
On 29 October 2015 at 17:00, Williams, Dan J <dan.j.williams@intel.com> wrote:
> Hi Linus, please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
>
> ...to receive a small fixlet for 4.3.
>
> The new memremap() api introduced in the 4.3 cycle to unify/replace
> ioremap_cache() and ioremap_wt() is mishandling the highmem case. This
> patch has received a build success notification from a 0day-kbuild-robot
> run and has been out for a review for a day. Russell has not had a
> chance to weigh in on it yet.
>
> I do not think the usage of kmap is strictly necessary as we should be
> able to fall back to ioremap_cache(), but I include it for two reasons:
>
> 1/ ARM ioremap() will WARN if passed a pfn_valid() address.
>
It will also return NULL
> 2/ acpi_map() carries a similar kmap fallback, and that quirk can now be
> centrally carried in this common routine.
>
I *really* think we should remove the kmap() fallback. memremap() is
intended as a drop-in replacement for ioremap_cache(), and if the
latter does not allow pfn_valid() pages to be ioremap'ed() on ARM,
they shouldn't silently end up being kmap()'ed at some random time in
the future when a certain user of ioremap_cache() gets upgraded to
memremap().
Could we not merge this for 4.3 please, and give Russell and the other
ARM folks some time to chime in? In the mean time, we could fix just
the bug by adding the !PageHighmem() test in the code path that ends
up returning the __va() result of the input physical address.
Regards,
Ard.
>
> ---
>
> The following changes since commit 25cb62b76430a91cc6195f902e61c2cb84ade622:
>
> Linux 4.3-rc5 (2015-10-11 11:09:45 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
>
> for you to fetch changes up to bcaa4236b558092dd5ff14ea943e89fd944fcd28:
>
> memremap: fix highmem support (2015-10-26 16:55:56 -0400)
>
> ----------------------------------------------------------------
> Dan Williams (1):
> memremap: fix highmem support
>
> include/linux/highmem.h | 12 ++++++++++++
> kernel/memremap.c | 28 +++++++++++++++++++++++++---
> 2 files changed, 37 insertions(+), 3 deletions(-)
>
> commit bcaa4236b558092dd5ff14ea943e89fd944fcd28
> Author: Dan Williams <dan.j.williams@intel.com>
> Date: Mon Oct 26 16:55:56 2015 -0400
>
> memremap: fix highmem support
>
> Currently memremap checks if the range is "System RAM" and returns the
> kernel linear address. This is broken for highmem platforms where a
> range may be "System RAM", but is not part of the kernel linear mapping.
> Similar to acpi_map(), use kmap() for PAGE_SIZE memremap() requests for
> highmem, and fall back to ioremap_cache() otherwise.
>
> The impact of this bug is low for now since the pmem driver is the only
> user of memremap(), but this is important to fix before more conversions
> to memremap arrive in 4.4.
>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>
> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
> index 6aefcd0031a6..c20cf24c76dd 100644
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -41,6 +41,13 @@ void kmap_flush_unused(void);
>
> struct page *kmap_to_page(void *addr);
>
> +static inline bool is_kmap_addr(const void *x)
> +{
> + unsigned long addr = (unsigned long) x;
> +
> + return addr >= PKMAP_ADDR(0) && addr < PKMAP_ADDR(LAST_PKMAP);
> +}
> +
> #else /* CONFIG_HIGHMEM */
>
> static inline unsigned int nr_free_highpages(void) { return 0; }
> @@ -50,6 +57,11 @@ static inline struct page *kmap_to_page(void *addr)
> return virt_to_page(addr);
> }
>
> +static inline bool is_kmap_addr(const void *x)
> +{
> + return false;
> +}
> +
> #define totalhigh_pages 0UL
>
> #ifndef ARCH_HAS_KMAP
> diff --git a/kernel/memremap.c b/kernel/memremap.c
> index 72b0c66628b6..901d7ec3583a 100644
> --- a/kernel/memremap.c
> +++ b/kernel/memremap.c
> @@ -10,6 +10,7 @@
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> * General Public License for more details.
> */
> +#include <linux/highmem.h>
> #include <linux/device.h>
> #include <linux/types.h>
> #include <linux/io.h>
> @@ -24,6 +25,25 @@ __weak void __iomem *ioremap_cache(resource_size_t offset, unsigned long size)
> }
> #endif
>
> +static void *try_ram_remap(resource_size_t offset, size_t size)
> +{
> + struct page *page = pfn_to_page(offset >> PAGE_SHIFT);
> + unsigned int pg_off = offset & ~PAGE_MASK;
> +
> + /* In the simple case just return the existing linear address */
> + if (!PageHighMem(page))
> + return __va(offset);
> +
> + /*
> + * Try kmap first since some arch ioremap implementations fail when
> + * being passed a ram address.
> + */
> + if (pg_off + size <= PAGE_SIZE)
> + return kmap(page) + pg_off;
> +
> + return NULL;
> +}
> +
> /**
> * memremap() - remap an iomem_resource as cacheable memory
> * @offset: iomem resource start address
> @@ -66,8 +86,8 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
> * the requested range is potentially in "System RAM"
> */
> if (is_ram == REGION_INTERSECTS)
> - addr = __va(offset);
> - else
> + addr = try_ram_remap(offset, size);
> + if (!addr)
> addr = ioremap_cache(offset, size);
> }
>
> @@ -94,7 +114,9 @@ EXPORT_SYMBOL(memremap);
>
> void memunmap(void *addr)
> {
> - if (is_vmalloc_addr(addr))
> + if (is_kmap_addr(addr))
> + kunmap(addr);
> + else if (is_vmalloc_addr(addr))
> iounmap((void __iomem *) addr);
> }
> EXPORT_SYMBOL(memunmap);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-10-29 18:20 +0100 |
| Message-ID | <qoZ1M-34X-11@gated-at.bofh.it> |
| In reply to | #1258626 |
On Thu, Oct 29, 2015 at 08:00:13AM +0000, Williams, Dan J wrote: > Hi Linus, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes > > ...to receive a small fixlet for 4.3. > > The new memremap() api introduced in the 4.3 cycle to unify/replace > ioremap_cache() and ioremap_wt() is mishandling the highmem case. This > patch has received a build success notification from a 0day-kbuild-robot > run and has been out for a review for a day. Russell has not had a > chance to weigh in on it yet. Oh, was this merged for 4.3-rc1? I haven't noticed any problems if it has. > I do not think the usage of kmap is strictly necessary as we should be > able to fall back to ioremap_cache(), but I include it for two reasons: > > 1/ ARM ioremap() will WARN if passed a pfn_valid() address. We don't support ioremap() on system RAM on ARM, period. That's because ioremap() sets up page tables with incompatible attributes compared to those which are/will be setup by the lowmem/kmap* mappings, which leads to "unpredictable" behaviour. The only time RAM is mappable with ioremap() is if it's stolen from the kernel at boot time, which prevents the kernel from managing it and setting up memory-like mappings. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Dan Williams <dan.j.williams@intel.com> |
|---|---|
| Date | 2015-10-29 21:10 +0100 |
| Message-ID | <qp1Gi-4Oq-7@gated-at.bofh.it> |
| In reply to | #1258923 |
On Thu, Oct 29, 2015 at 10:09 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Oct 29, 2015 at 08:00:13AM +0000, Williams, Dan J wrote: >> Hi Linus, please pull from: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes >> >> ...to receive a small fixlet for 4.3. >> >> The new memremap() api introduced in the 4.3 cycle to unify/replace >> ioremap_cache() and ioremap_wt() is mishandling the highmem case. This >> patch has received a build success notification from a 0day-kbuild-robot >> run and has been out for a review for a day. Russell has not had a >> chance to weigh in on it yet. > > Oh, was this merged for 4.3-rc1? I haven't noticed any problems if it > has. > >> I do not think the usage of kmap is strictly necessary as we should be >> able to fall back to ioremap_cache(), but I include it for two reasons: >> >> 1/ ARM ioremap() will WARN if passed a pfn_valid() address. > > We don't support ioremap() on system RAM on ARM, period. That's because > ioremap() sets up page tables with incompatible attributes compared to > those which are/will be setup by the lowmem/kmap* mappings, which leads > to "unpredictable" behaviour. > > The only time RAM is mappable with ioremap() is if it's stolen from the > kernel at boot time, which prevents the kernel from managing it and > setting up memory-like mappings. > Ok, I read that as: "if someone calls memremap() on a 'System RAM' address on ARM and we can't find the kernel linear address then just pass it through to arch level remap code where it should rightly WARN." I'll reflow the patch with that change. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web