[PATCH] mm/nvdimm: Add is_ioremap_addr and use that to check ioremap address
by Aneesh Kumar K.V
Architectures like powerpc use different address range to map ioremap
and vmalloc range. The memunmap() check used by the nvdimm layer was
wrongly using is_vmalloc_addr() to check for ioremap range which fails for
ppc64. This result in ppc64 not freeing the ioremap mapping. The side effect
of this is an unbind failure during module unload with papr_scm nvdimm driver
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
---
arch/powerpc/include/asm/pgtable.h | 14 ++++++++++++++
include/linux/mm.h | 5 +++++
kernel/iomem.c | 2 +-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index 3f53be60fb01..64145751b2fd 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -140,6 +140,20 @@ static inline void pte_frag_set(mm_context_t *ctx, void *p)
}
#endif
+#ifdef CONFIG_PPC64
+#define is_ioremap_addr is_ioremap_addr
+static inline bool is_ioremap_addr(const void *x)
+{
+#ifdef CONFIG_MMU
+ unsigned long addr = (unsigned long)x;
+
+ return addr >= IOREMAP_BASE && addr < IOREMAP_END;
+#else
+ return false;
+#endif
+}
+#endif /* CONFIG_PPC64 */
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_H */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 973ebf71f7b6..65b2eb6c9f0a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -633,6 +633,11 @@ static inline bool is_vmalloc_addr(const void *x)
return false;
#endif
}
+
+#ifndef is_ioremap_addr
+#define is_ioremap_addr(x) is_vmalloc_addr(x)
+#endif
+
#ifdef CONFIG_MMU
extern int is_vmalloc_or_module_addr(const void *x);
#else
diff --git a/kernel/iomem.c b/kernel/iomem.c
index 93c264444510..62c92e43aa0d 100644
--- a/kernel/iomem.c
+++ b/kernel/iomem.c
@@ -121,7 +121,7 @@ EXPORT_SYMBOL(memremap);
void memunmap(void *addr)
{
- if (is_vmalloc_addr(addr))
+ if (is_ioremap_addr(addr))
iounmap((void __iomem *) addr);
}
EXPORT_SYMBOL(memunmap);
--
2.21.0
2 years, 10 months
[PATCH v5 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework
by Brendan Higgins
## TL;DR
A not so quick follow-up to Stephen's suggestions on PATCH v4. Nothing
that really changes any functionality or usage with the minor exception
of a couple public functions that Stephen asked me to rename.
Nevertheless, a good deal of clean up and fixes. See changes below.
As for our current status, right now we got Reviewed-bys on all patches
except:
- [PATCH v5 08/18] objtool: add kunit_try_catch_throw to the noreturn
list
However, it would probably be good to get reviews/acks from the
subsystem maintainers on:
- [PATCH v5 06/18] kbuild: enable building KUnit
- [PATCH v5 08/18] objtool: add kunit_try_catch_throw to the noreturn
list
- [PATCH v5 15/18] Documentation: kunit: add documentation for KUnit
- [PATCH v5 17/18] kernel/sysctl-test: Add null pointer test for
sysctl.c:proc_dointvec()
- [PATCH v5 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC
SYSCTL section
Other than that, I think we should be good to go.
One last thing, I updated the background to include my thoughts on KUnit
vs. in kernel testing with kselftest in the background sections as
suggested by Frank in the discussion on PATCH v2.
## Background
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
(however, KUnit still allows you to run tests on test machines or in VMs
if you want[1]) and does not require tests to be written in userspace
running on a host kernel. Additionally, KUnit is fast: From invocation
to completion KUnit can run several dozen tests in under a second.
Currently, the entire KUnit test suite for KUnit runs in under a second
from the initial invocation (build time excluded).
KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining
unit test cases, grouping related test cases into test suites, providing
common infrastructure for running tests, mocking, spying, and much more.
### But wait! Doesn't kselftest support in kernel testing?!
In a previous version of this patchset Frank pointed out that kselftest
already supports writing a test that resides in the kernel using the
test module feature[2]. LWN did a really great summary on this
discussion here[3].
Kselftest has a feature that allows a test module to be loaded into a
kernel using the kselftest framework; this does allow someone to write
tests against kernel code not directly exposed to userland; however, it
does not provide much of a framework around how to structure the tests.
The kselftest test module feature just provides a header which has a
standardized way of reporting test failures, and then provides
infrastructure to load and run the tests using the kselftest test
harness.
The kselftest test module does not seem to be opinionated at all in
regards to how tests are structured, how they check for failures, how
tests are organized. Even in the method it provides for reporting
failures is pretty simple; it doesn't have any more advanced failure
reporting or logging features. Given what's there, I think it is fair to
say that it is not actually a framework, but a feature that makes it
possible for someone to do some checks in kernel space.
Furthermore, kselftest test module has very few users. I checked for all
the tests that use it using the following grep command:
grep -Hrn -e 'kselftest_module\.h'
and only got three results: lib/test_strscpy.c, lib/test_printf.c, and
lib/test_bitmap.c.
So despite kselftest test module's existence, there really is no feature
overlap between kselftest and KUnit, save one: that you can use either
to write an in-kernel test, but this is a very small feature in
comparison to everything that KUnit allows you to do. KUnit is a full
x-unit style unit testing framework, whereas kselftest looks a lot more
like an end-to-end/functional testing framework, with a feature that
makes it possible to write in-kernel tests.
### What's so special about unit testing?
A unit test is supposed to test a single unit of code in isolation,
hence the name. There should be no dependencies outside the control of
the test; this means no external dependencies, which makes tests orders
of magnitudes faster. Likewise, since there are no external dependencies,
there are no hoops to jump through to run the tests. Additionally, this
makes unit tests deterministic: a failing unit test always indicates a
problem. Finally, because unit tests necessarily have finer granularity,
they are able to test all code paths easily solving the classic problem
of difficulty in exercising error handling code.
### Is KUnit trying to replace other testing frameworks for the kernel?
No. Most existing tests for the Linux kernel are end-to-end tests, which
have their place. A well tested system has lots of unit tests, a
reasonable number of integration tests, and some end-to-end tests. KUnit
is just trying to address the unit test space which is currently not
being addressed.
### More information on KUnit
There is a bunch of documentation near the end of this patch set that
describes how to use KUnit and best practices for writing unit tests.
For convenience I am hosting the compiled docs here[4].
Additionally for convenience, I have applied these patches to a
branch[5]. The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/rfc/v5.2-rc4/v5 branch.
## Changes Since Last Version
Aside from a couple public function renames, there isn't really anything
in here that changes any functionality.
- Went through and fixed a couple of anti-patterns suggested by Stephen
Boyd. Things like:
- Dropping an else clause at the end of a function.
- Dropping the comma on the closing sentinel, `{}`, of a list.
- Inlines a bunch of functions in the test case running logic in patch
01/18 to make it more readable as suggested by Stephen Boyd
- Found and fixed bug in resource deallocation logic in patch 02/18. Bug
was discovered as a result of making a change suggested by Stephen
Boyd. This does not substantially change how any of the code works
conceptually.
- Renamed new_string_stream() to alloc_string_stream() as suggested by
Stephen Boyd.
- Made string-stream a KUnit managed object - based on a suggestion made
by Stephen Boyd.
- Renamed kunit_new_stream() to alloc_kunit_stream() as suggested by
Stephen Boyd.
- Removed the ability to set log level after allocating a kunit_stream,
as suggested by Stephen Boyd.
[1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#ku...
[2] https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html#test-module
[3] https://lwn.net/Articles/790235/
[4] https://google.github.io/kunit-docs/third_party/kernel/docs/
[5] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.2-rc4/v5
--
2.22.0.410.gd8fdbe21b5-goog
2 years, 10 months
Re: [PATCH 20/22] mm: move hmm_vma_fault to nouveau
by Christoph Hellwig
On Wed, Jul 03, 2019 at 03:03:56PM -0300, Jason Gunthorpe wrote:
> I was thinking about doing exactly this too, but amdgpu started using
> this already obsolete API in their latest driver :(
>
> So, we now need to get both drivers to move to the modern API.
Actually the AMD folks fixed this up after we pointed it out to them,
so even in linux-next it just is nouveau that needs fixing.
2 years, 10 months
Re: [PATCH 22/22] mm: remove the legacy hmm_pfn_* APIs
by Christoph Hellwig
On Wed, Jul 03, 2019 at 03:01:25PM -0300, Jason Gunthorpe wrote:
> Christoph, I guess you didn't mean to send this branch to the mailing
> list?
>
> In any event some of these, like this one, look obvious and I could
> still grab a few for hmm.git.
>
> Let me know what you'd like please
>
> Reviewed-by: Jason Gunthorpe <jgg(a)mellanox.com>
Thanks. I was going to send this series out as soon as you had
applied the previous one. Now that it leaked I'm happy to collect
reviews. But while I've got your attention: the rdma.git hmm
branch is still at the -rc7 merge and doen't have my series, is that
intentional?
2 years, 10 months
dev_pagemap related cleanups v4
by Christoph Hellwig
Hi Dan, Jérôme and Jason,
below is a series that cleans up the dev_pagemap interface so that
it is more easily usable, which removes the need to wrap it in hmm
and thus allowing to kill a lot of code
Note: this series is on top of Linux 5.2-rc6 and has some minor
conflicts with the hmm tree that are easy to resolve.
Diffstat summary:
34 files changed, 379 insertions(+), 1016 deletions(-)
Git tree:
git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.4
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-devme...
Changes since v3:
- pull in "mm/swap: Fix release_pages() when releasing devmap pages" and
rebase the other patches on top of that
- fold the hmm_devmem_add_resource into the DEVICE_PUBLIC memory removal
patch
- remove _vm_normal_page as it isn't needed without DEVICE_PUBLIC memory
- pick up various ACKs
Changes since v2:
- fix nvdimm kunit build
- add a new memory type for device dax
- fix a few issues in intermediate patches that didn't show up in the end
result
- incorporate feedback from Michal Hocko, including killing of
the DEVICE_PUBLIC memory type entirely
Changes since v1:
- rebase
- also switch p2pdma to the internal refcount
- add type checking for pgmap->type
- rename the migrate method to migrate_to_ram
- cleanup the altmap_valid flag
- various tidbits from the reviews
2 years, 10 months
[PATCH v4 00/10] EFI Specific Purpose Memory Support
by Dan Williams
Changes since v3 [1]:
- Clarify in the changelog that the policy decision of how to treat
specific-purpose memory is x86 only until other archs grow a
translation to IORES_DESC_APPLICATION_RESERVED. The EFI spec does not
mandate a behavior for the EFI_MEMORY_SP attribute so the decision is
kept out of the core EFI implementation. (prompted by Ard)
- Merge the memregion ida into kernel/resource.c and provide a static
inline wrappers around an exported 'struct ida memregion_ids'
instance. (Willy)
- Fix a set of compile errors in the CONFIG_EFI_FAKE_MEMMAP=n case.
(0day)
- Collect Dave's reviewed-by on the series.
[1]: https://lore.kernel.org/lkml/155993563277.3036719.17400338098057706494.st...
---
Merge logistics: These patches touch core-efi, acpi, device-dax, and
x86. Given the regression risk is highest for the x86 changes it seems
tip.git is the best tree to host the series.
---
The EFI 2.8 Specification [2] introduces the EFI_MEMORY_SP ("specific
purpose") memory attribute. This attribute bit replaces the deprecated
ACPI HMAT "reservation hint" that was introduced in ACPI 6.2 and removed
in ACPI 6.3.
Given the increasing diversity of memory types that might be advertised
to the operating system, there is a need for platform firmware to hint
which memory ranges are free for the OS to use as general purpose memory
and which ranges are intended for application specific usage. For
example, an application with prior knowledge of the platform may expect
to be able to exclusively allocate a precious / limited pool of high
bandwidth memory. Alternatively, for the general purpose case, the
operating system may want to make the memory available on a best effort
basis as a unique numa-node with performance properties by the new
CONFIG_HMEM_REPORTING [3] facility.
In support of optionally allowing either application-exclusive and
core-kernel-mm managed access to differentiated memory, claim
EFI_MEMORY_SP ranges for exposure as device-dax instances by default.
Such instances can be directly owned / mapped by a
platform-topology-aware application. Alternatively, with the new kmem
facility [4], the administrator has the option to instead designate that
those memory ranges be hot-added to the core-kernel-mm as a unique
memory numa-node. In short, allow for the decision about what software
agent manages specific-purpose memory to be made at runtime.
The patches build on the new HMAT+HMEM_REPORTING facilities merged
for v5.2-rc1. The implementation is tested with qemu emulation of HMAT
[5] plus the efi_fake_mem facility for applying the EFI_MEMORY_SP
attribute.
[2]: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
[4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
[5]: http://patchwork.ozlabs.org/cover/1096737/
---
Dan Williams (10):
acpi/numa: Establish a new drivers/acpi/numa/ directory
acpi/numa/hmat: Skip publishing target info for nodes with no online memory
efi: Enumerate EFI_MEMORY_SP
x86, efi: Push EFI_MEMMAP check into leaf routines
x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax
x86, efi: Add efi_fake_mem support for EFI_MEMORY_SP
resource: Uplevel the pmem "region" ida to a global allocator
device-dax: Add a driver for "hmem" devices
acpi/numa/hmat: Register HMAT at device_initcall level
acpi/numa/hmat: Register "specific purpose" memory as an "hmem" device
arch/x86/Kconfig | 23 +++++
arch/x86/boot/compressed/eboot.c | 5 +
arch/x86/boot/compressed/kaslr.c | 3 -
arch/x86/include/asm/e820/types.h | 9 ++
arch/x86/include/asm/efi.h | 34 ++++++++
arch/x86/kernel/e820.c | 12 ++-
arch/x86/kernel/setup.c | 21 +++--
arch/x86/platform/efi/efi.c | 40 +++++++++
arch/x86/platform/efi/quirks.c | 3 +
drivers/acpi/Kconfig | 9 --
drivers/acpi/Makefile | 3 -
drivers/acpi/hmat/Makefile | 2
drivers/acpi/numa/Kconfig | 8 ++
drivers/acpi/numa/Makefile | 3 +
drivers/acpi/numa/hmat.c | 148 +++++++++++++++++++++++++++++++----
drivers/acpi/numa/srat.c | 0
drivers/dax/Kconfig | 27 +++++-
drivers/dax/Makefile | 2
drivers/dax/hmem.c | 57 +++++++++++++
drivers/firmware/efi/Makefile | 5 +
drivers/firmware/efi/efi.c | 5 +
drivers/firmware/efi/esrt.c | 3 +
drivers/firmware/efi/fake_mem.c | 26 +++---
drivers/firmware/efi/fake_mem.h | 10 ++
drivers/firmware/efi/x86-fake_mem.c | 69 ++++++++++++++++
drivers/nvdimm/Kconfig | 1
drivers/nvdimm/core.c | 1
drivers/nvdimm/nd-core.h | 1
drivers/nvdimm/region_devs.c | 12 +--
include/linux/efi.h | 3 -
include/linux/ioport.h | 32 ++++++++
kernel/resource.c | 6 +
lib/Kconfig | 3 +
33 files changed, 504 insertions(+), 82 deletions(-)
delete mode 100644 drivers/acpi/hmat/Makefile
rename drivers/acpi/{hmat/Kconfig => numa/Kconfig} (70%)
create mode 100644 drivers/acpi/numa/Makefile
rename drivers/acpi/{hmat/hmat.c => numa/hmat.c} (81%)
rename drivers/acpi/{numa.c => numa/srat.c} (100%)
create mode 100644 drivers/dax/hmem.c
create mode 100644 drivers/firmware/efi/fake_mem.h
create mode 100644 drivers/firmware/efi/x86-fake_mem.c
2 years, 10 months
inquiry for quote
by Tran Thi Thanh Tra
Dear Sir/Madam!
I am Tra from Dong Tay Investment at Viet Nam.
I want to buy your product .
Please: check and send me a quote
1
PeakTech 5310, PH Meter
PCS
2
We would highly appreciate it if you could send us your quotation
for the items stated below before 3 July, 2019:
- The Delivery Term: at Ho Chi Minh, Viet Nam.
- Please also inform us the payment terms, delivery time, name of
original maker, country of origin (Made in where) and warranty
period of the goods you quote us
- Document required: Technical Data Sheet; Drawing; (C/O; C/Q in
shipping documents)
Should you have any questions, please feel free to contact us. We
look forwards to hearing from you.
----------------------------------------------
Thanks & Best regards
Ms Thanh Tra
Mobile: +84 983175450
DONG TAY INVESTMENT
Add:, No. 05, Road 518, Phu Huu Ward, District 9, Ho Chi Minh
City.
Tel: + 028 3620 9395 -3620 9396 Fax: + 028 3620 9397 Hotline:
+84 902 425 111
Email: sales10(a)dongtaycorp.vn
Vung Tau Branch & Showroom:
Add: 69 Nguyen An Ninh Str., Thanh Nhi Ward, Vung Tau City,
Vietnam.
Tel: + 84 643 626 632 Fax: + 84 643 576 836
Quang Ngai Branch & Showroom:
Add: Floor 1,2 Dong Tay Building 28 Tra Bong Khoi Nghia Str.,
Nghia Chanh Ward, Quang Ngai City, Vietnam.
Tel: +84 255 222 555 7 Fax: +84 255 222 555 8
Website: www.Dongtaycorp.vn www.dongtayinvestment.com
www.Dongtayco.com
www.thietbithuyluc.net
www.giangiaodongtay.vn www.dongtaytools.com
2 years, 10 months
dev_pagemap related cleanups v3
by Christoph Hellwig
Hi Dan, Jérôme and Jason,
below is a series that cleans up the dev_pagemap interface so that
it is more easily usable, which removes the need to wrap it in hmm
and thus allowing to kill a lot of code
Note: this series is on top of Linux 5.2-rc5 and has some minor
conflicts with the hmm tree that are easy to resolve.
Diffstat summary:
32 files changed, 361 insertions(+), 1012 deletions(-)
Git tree:
git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.3
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-devme...
Changes since v2:
- fix nvdimm kunit build
- add a new memory type for device dax
- fix a few issues in intermediate patches that didn't show up in the end
result
- incorporate feedback from Michal Hocko, including killing of
the DEVICE_PUBLIC memory type entirely
Changes since v1:
- rebase
- also switch p2pdma to the internal refcount
- add type checking for pgmap->type
- rename the migrate method to migrate_to_ram
- cleanup the altmap_valid flag
- various tidbits from the reviews
2 years, 10 months
