[PATCH V8] mm/debug: Add tests validating architecture page table helpers
This adds tests which will validate architecture page table helpers and other accessors in their compliance with expected generic MM semantics. This will help various architectures in validating changes to existing page table helpers or addition of new ones. This test covers basic page table entry transformations including but not limited to old, young, dirty, clean, write, write protect etc at various level along with populating intermediate entries with next page table page and validating them. Test page table pages are allocated from system memory with required size and alignments. The mapped pfns at page table levels are derived from a real pfn representing a valid kernel text symbol. This test gets called right after page_alloc_init_late(). This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along with CONFIG_VM_DEBUG. Architectures willing to subscribe this test also need to select CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE which for now is limited to x86 and arm64. Going forward, other architectures too can enable this after fixing build or runtime problems (if any) with their page table helpers. Folks interested in making sure that a given platform's page table helpers conform to expected generic MM semantics should enable the above config which will just trigger this test during boot. Any non conformity here will be reported as an warning which would need to be fixed. This test will help catch any changes to the agreed upon semantics expected from generic MM and enable platforms to accommodate it thereafter. Cc: Andrew Morton Cc: Vlastimil Babka Cc: Greg Kroah-Hartman Cc: Thomas Gleixner Cc: Mike Rapoport Cc: Jason Gunthorpe Cc: Dan Williams Cc: Peter Zijlstra Cc: Michal Hocko Cc: Mark Rutland Cc: Mark Brown Cc: Steven Price Cc: Ard Biesheuvel Cc: Masahiro Yamada Cc: Kees Cook Cc: Tetsuo Handa Cc: Matthew Wilcox Cc: Sri Krishna chowdary Cc: Dave Hansen Cc: Russell King - ARM Linux Cc: Michael Ellerman Cc: Paul Mackerras Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: "David S. Miller" Cc: Vineet Gupta Cc: James Hogan Cc: Paul Burton Cc: Ralf Baechle Cc: Kirill A. Shutemov Cc: Gerald Schaefer Cc: Christophe Leroy Cc: Ingo Molnar Cc: linux-snps-...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-i...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: x...@kernel.org Cc: linux-ker...@vger.kernel.org Tested-by: Christophe Leroy#PPC32 Suggested-by: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Christophe Leroy Signed-off-by: Anshuman Khandual --- This adds a test validation for architecture exported page table helpers. Patch adds basic transformation tests at various levels of the page table. This test was originally suggested by Catalin during arm64 THP migration RFC discussion earlier. Going forward it can include more specific tests with respect to various generic MM functions like THP, HugeTLB etc and platform specific tests. https://lore.kernel.org/linux-mm/20190628102003.ga56...@arrakis.emea.arm.com/ Needs to be applied on linux-next (next-20191025). Changes in V8: - Enabled ARCH_HAS_DEBUG_VM_PGTABLE on PPC32 platform per Christophe - Updated feature documentation as DEBUG_VM_PGTABLE is now enabled on PPC32 platform - Moved ARCH_HAS_DEBUG_VM_PGTABLE earlier to indent it with DEBUG_VM per Christophe - Added an information message in debug_vm_pgtable() per Christophe - Dropped random_vaddr boundary condition checks per Christophe and Qian - Replaced virt_addr_valid() check with pfn_valid() check in debug_vm_pgtable() - Slightly changed pr_fmt(fmt) information Changes in V7: (https://patchwork.kernel.org/project/linux-mm/list/?series=193051) - Memory allocation and free routines for mapped pages have been droped - Mapped pfns are derived from standard kernel text symbol per Matthew - Moved debug_vm_pgtaable() after page_alloc_init_late() per Michal and Qian - Updated the commit message per Michal - Updated W=1 GCC warning problem on x86 per Qian Cai - Addition of new alloc_contig_pages() helper has been submitted separately Changes in V6: (https://patchwork.kernel.org/project/linux-mm/list/?series=187589) - Moved alloc_gigantic_page_order() into mm/page_alloc.c per Michal - Moved alloc_gigantic_page_order() within CONFIG_CONTIG_ALLOC in the test - Folded Andrew's include/asm-generic/pgtable.h fix into the test patch 2/2 Changes in V5: (https://patchwork.kernel.org/project/linux-mm/list/?series=185991) - Redefined and moved X86 mm_p4d_folded() into a different header per Kirill/Ingo - Updated the config option comment per Ingo and dropped 'kernel module' reference - Updated the commit message and dropped 'kernel module' reference - Changed DEBUG_ARCH_PGTABLE_TEST into DEBUG_VM_PGTABLE per Ingo - Moved config option from mm/Kconfig.debug into lib/Kconfig.debug -
Re: [PATCH 09/10] powerpc: Enable OpenCAPI Storage Class Memory driver on bare metal
On Fri, Oct 25, 2019 at 3:51 PM Alastair D'Silva wrote: > > From: Alastair D'Silva > > Enable OpenCAPI Storage Class Memory driver on bare metal > > Signed-off-by: Alastair D'Silva > --- > arch/powerpc/configs/powernv_defconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/powerpc/configs/powernv_defconfig > b/arch/powerpc/configs/powernv_defconfig > index 6658cceb928c..45c0eff94964 100644 > --- a/arch/powerpc/configs/powernv_defconfig > +++ b/arch/powerpc/configs/powernv_defconfig > @@ -352,3 +352,7 @@ CONFIG_KVM_BOOK3S_64=m > CONFIG_KVM_BOOK3S_64_HV=m > CONFIG_VHOST_NET=m > CONFIG_PRINTK_TIME=y > +CONFIG_OCXL_SCM=m > +CONFIG_DEV_DAX=y > +CONFIG_DEV_DAX_PMEM=y These should probably be modules. Having them as builtins will force their dependencies (i.e. libnvdimm) to be built into the kernel too. > +CONFIG_FS_DAX=y > -- > 2.21.0 > ___ > Linux-nvdimm mailing list -- linux-nvd...@lists.01.org > To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
[RFC PATCH] nvdimm: scm_get() can be static
Fixes: 0d40f55b9035 ("nvdimm: Add driver for OpenCAPI Storage Class Memory")
Signed-off-by: kbuild test robot
---
ocxl-scm.c |4 ++--
ocxl-scm_internal.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/nvdimm/ocxl-scm.c b/drivers/nvdimm/ocxl-scm.c
index f4e6cc022de8a..c169cb0bc71d4 100644
--- a/drivers/nvdimm/ocxl-scm.c
+++ b/drivers/nvdimm/ocxl-scm.c
@@ -733,7 +733,7 @@ static void scm_put(struct scm_data *scm_data)
put_device(_data->dev);
}
-struct scm_data *scm_get(struct scm_data *scm_data)
+static struct scm_data *scm_get(struct scm_data *scm_data)
{
return (get_device(_data->dev) == NULL) ? NULL : scm_data;
}
@@ -2142,7 +2142,7 @@ static int scm_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return -ENXIO;
}
-struct pci_driver scm_pci_driver = {
+static struct pci_driver scm_pci_driver = {
.name = "ocxl-scm",
.id_table = scm_pci_tbl,
.probe = scm_probe,
diff --git a/drivers/nvdimm/ocxl-scm_internal.c
b/drivers/nvdimm/ocxl-scm_internal.c
index e7c247835817b..ee11fb72e1ecd 100644
--- a/drivers/nvdimm/ocxl-scm_internal.c
+++ b/drivers/nvdimm/ocxl-scm_internal.c
@@ -64,8 +64,8 @@ int scm_admin_command_request(struct scm_data *scm_data, u8
op_code)
return scm_command_request(scm_data, _data->admin_command, op_code);
}
-int scm_command_response(const struct scm_data *scm_data,
-const struct command_metadata *cmd)
+static int scm_command_response(const struct scm_data *scm_data,
+ const struct command_metadata *cmd)
{
u64 val;
u16 id;
Re: linux-next: build warning after merge of the bpf-next tree
Hi all,
On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> WARNING: 2 bad relocations
> c1998a48 R_PPC64_ADDR64_binary__btf_vmlinux_bin_start
> c1998a50 R_PPC64_ADDR64_binary__btf_vmlinux_bin_end
>
> Introduced by commit
>
> 8580ac9404f6 ("bpf: Process in-kernel BTF")
This warning now appears in the net-next tree build.
--
Cheers,
Stephen Rothwell
pgpI1m7wrJHG7.pgp
Description: OpenPGP digital signature
Re: [PATCH 02/10] nvdimm: remove prototypes for nonexistent functions
On 25/10/19 3:46 pm, Alastair D'Silva wrote: From: Alastair D'Silva These functions don't exist, so remove the prototypes for them. Signed-off-by: Alastair D'Silva Indeed, they do not. Reviewed-by: Andrew Donnellan --- drivers/nvdimm/nd-core.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h index 25fa121104d0..9f121a6aeb02 100644 --- a/drivers/nvdimm/nd-core.h +++ b/drivers/nvdimm/nd-core.h @@ -124,11 +124,7 @@ void nd_region_create_dax_seed(struct nd_region *nd_region); int nvdimm_bus_create_ndctl(struct nvdimm_bus *nvdimm_bus); void nvdimm_bus_destroy_ndctl(struct nvdimm_bus *nvdimm_bus); void nd_synchronize(void); -int nvdimm_bus_register_dimms(struct nvdimm_bus *nvdimm_bus); -int nvdimm_bus_register_regions(struct nvdimm_bus *nvdimm_bus); -int nvdimm_bus_init_interleave_sets(struct nvdimm_bus *nvdimm_bus); void __nd_device_register(struct device *dev); -int nd_match_dimm(struct device *dev, void *data); struct nd_label_id; char *nd_label_gen_id(struct nd_label_id *label_id, u8 *uuid, u32 flags); bool nd_is_uuid_unique(struct device *dev, u8 *uuid); -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH 08/10] nvdimm: Add driver for OpenCAPI Storage Class Memory
Hi Alastair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on char-misc/char-misc-testing]
[cannot apply to v5.4-rc5 next-20191025]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Alastair-D-Silva/Add-support-for-OpenCAPI-SCM-devices/20191028-043750
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
da80d2e516eb858eb5bcca7fa5f5a13ed86930e4
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-14) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/nvdimm/ocxl-scm.c: In function 'scm_register_lpc_mem':
>> drivers/nvdimm/ocxl-scm.c:476:16: error: implicit declaration of function
>> 'of_node_to_nid'; did you mean 'zone_to_nid'?
>> [-Werror=implicit-function-declaration]
target_node = of_node_to_nid(scm_data->pdev->dev.of_node);
^~
zone_to_nid
cc1: some warnings being treated as errors
--
drivers/misc/ocxl/main.c: In function 'init_ocxl':
>> drivers/misc/ocxl/main.c:12:7: error: 'tlbie_capable' undeclared (first use
>> in this function); did you mean 'ptracer_capable'?
if (!tlbie_capable)
^
ptracer_capable
drivers/misc/ocxl/main.c:12:7: note: each undeclared identifier is reported
only once for each function it appears in
--
>> drivers/misc/ocxl/config.c:4:10: fatal error: asm/pnv-ocxl.h: No such file
>> or directory
#include
^~~~
compilation terminated.
--
>> drivers/misc/ocxl/file.c:9:10: fatal error: asm/reg.h: No such file or
>> directory
#include
^~~
compilation terminated.
--
drivers/misc/ocxl/mmio.c: In function 'ocxl_global_mmio_read32':
>> drivers/misc/ocxl/mmio.c:20:10: error: implicit declaration of function
>> 'readl_be'; did you mean 'readsb'? [-Werror=implicit-function-declaration]
*val = readl_be((char *)afu->global_mmio_ptr + offset);
^~~~
readsb
drivers/misc/ocxl/mmio.c: In function 'ocxl_global_mmio_read64':
>> drivers/misc/ocxl/mmio.c:45:10: error: implicit declaration of function
>> 'readq_be'; did you mean 'readsb'? [-Werror=implicit-function-declaration]
*val = readq_be((char *)afu->global_mmio_ptr + offset);
^~~~
readsb
drivers/misc/ocxl/mmio.c: In function 'ocxl_global_mmio_write32':
>> drivers/misc/ocxl/mmio.c:70:3: error: implicit declaration of function
>> 'writel_be'; did you mean 'writesb'? [-Werror=implicit-function-declaration]
writel_be(val, (char *)afu->global_mmio_ptr + offset);
^
writesb
drivers/misc/ocxl/mmio.c: In function 'ocxl_global_mmio_write64':
>> drivers/misc/ocxl/mmio.c:96:3: error: implicit declaration of function
>> 'writeq_be'; did you mean 'writesb'? [-Werror=implicit-function-declaration]
writeq_be(val, (char *)afu->global_mmio_ptr + offset);
^
writesb
cc1: some warnings being treated as errors
--
>> drivers/misc/ocxl/link.c:7:10: fatal error: asm/copro.h: No such file or
>> directory
#include
^
compilation terminated.
--
drivers/misc/ocxl/context.c: In function 'ocxl_context_attach':
>> drivers/misc/ocxl/context.c:82:21: error: 'mm_context_t {aka struct
>> }' has no member named 'id'
pidr = mm->context.id;
^
--
>> drivers/misc/ocxl/afu_irq.c:4:10: fatal error: asm/pnv-ocxl.h: No such file
>> or directory
#include
^~~~
compilation terminated.
--
drivers/misc/ocxl/core.c: In function 'ocxl_function_open':
>> drivers/misc/ocxl/core.c:546:7: error: implicit declaration of function
>> 'radix_enabled'; did you mean 'pat_enabled'?
>> [-Werror=implicit-function-declaration]
if (!radix_enabled()) {
^
pat_enabled
cc1: some warnings being treated as errors
vim +476 drivers/nvdimm/ocxl-scm.c
402
403 /**
404 * scm_register_lpc_mem() - Discover persistent memory on a device and
register it with the NVDIMM subsystem
405 * @scm_data: The SCM device data
406 * Return: 0 on success
407 */
408 static int scm_register_lpc_mem(struct scm_data *scm_data)
409 {
410 struct nd_region_desc region_desc;
411 struct nd_mapping_desc nd_mapping_desc;
412 struct resource *lpc_mem;
413 const struct ocxl_afu_config *config;
414 const struct ocxl_fn_config *fn_config;
415 int rc;
416 unsigned long nvdimm_cmd_mask = 0;
417
Re: [PATCH v6 05/10] mm/memory_hotplug: Shrink zones when offlining memory
On 06.10.19 10:56, David Hildenbrand wrote:
We currently try to shrink a single zone when removing memory. We use the
zone of the first page of the memory we are removing. If that memmap was
never initialized (e.g., memory was never onlined), we will read garbage
and can trigger kernel BUGs (due to a stale pointer):
:/# [ 23.912993] BUG: unable to handle page fault for address:
353d
[ 23.914219] #PF: supervisor write access in kernel mode
[ 23.915199] #PF: error_code(0x0002) - not-present page
[ 23.916160] PGD 0 P4D 0
[ 23.916627] Oops: 0002 [#1] SMP PTI
[ 23.917256] CPU: 1 PID: 7 Comm: kworker/u8:0 Not tainted
5.3.0-rc5-next-20190820+ #317
[ 23.918900] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.4
[ 23.921194] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 23.922249] RIP: 0010:clear_zone_contiguous+0x5/0x10
[ 23.923173] Code: 48 89 c6 48 89 c3 e8 2a fe ff ff 48 85 c0 75 cf 5b 5d c3
c6 85 fd 05 00 00 01 5b 5d c3 0f 1f 840
[ 23.926876] RSP: 0018:ad2400043c98 EFLAGS: 00010246
[ 23.927928] RAX: RBX: 0002 RCX:
[ 23.929458] RDX: 0020 RSI: 0014 RDI: 2f40
[ 23.930899] RBP: 00014000 R08: R09: 0001
[ 23.932362] R10: R11: R12: 0014
[ 23.933603] R13: 0014 R14: 2f40 R15: 9e3e7aff3680
[ 23.934913] FS: () GS:9e3e7bb0()
knlGS:
[ 23.936294] CS: 0010 DS: ES: CR0: 80050033
[ 23.937481] CR2: 353d CR3: 5861 CR4: 06e0
[ 23.938687] DR0: DR1: DR2:
[ 23.939889] DR3: DR6: fffe0ff0 DR7: 0400
[ 23.941168] Call Trace:
[ 23.941580] __remove_pages+0x4b/0x640
[ 23.942303] ? mark_held_locks+0x49/0x70
[ 23.943149] arch_remove_memory+0x63/0x8d
[ 23.943921] try_remove_memory+0xdb/0x130
[ 23.944766] ? walk_memory_blocks+0x7f/0x9e
[ 23.945616] __remove_memory+0xa/0x11
[ 23.946274] acpi_memory_device_remove+0x70/0x100
[ 23.947308] acpi_bus_trim+0x55/0x90
[ 23.947914] acpi_device_hotplug+0x227/0x3a0
[ 23.948714] acpi_hotplug_work_fn+0x1a/0x30
[ 23.949433] process_one_work+0x221/0x550
[ 23.950190] worker_thread+0x50/0x3b0
[ 23.950993] kthread+0x105/0x140
[ 23.951644] ? process_one_work+0x550/0x550
[ 23.952508] ? kthread_park+0x80/0x80
[ 23.953367] ret_from_fork+0x3a/0x50
[ 23.954025] Modules linked in:
[ 23.954613] CR2: 353d
[ 23.955248] ---[ end trace 93d982b1fb3e1a69 ]---
Instead, shrink the zones when offlining memory or when onlining failed.
Introduce and use remove_pfn_range_from_zone(() for that. We now properly
shrink the zones, even if we have DIMMs whereby
- Some memory blocks fall into no zone (never onlined)
- Some memory blocks fall into multiple zones (offlined+re-onlined)
- Multiple memory blocks that fall into different zones
Drop the zone parameter (with a potential dubious value) from
__remove_pages() and __remove_section().
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Andrew Morton
Cc: Mark Rutland
Cc: Steve Capper
Cc: Mike Rapoport
Cc: Anshuman Khandual
Cc: Yu Zhao
Cc: Jun Yao
Cc: Robin Murphy
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: "Matthew Wilcox (Oracle)"
Cc: Christophe Leroy
Cc: "Aneesh Kumar K.V"
Cc: Pavel Tatashin
Cc: Gerald Schaefer
Cc: Halil Pasic
Cc: Tom Lendacky
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Dan Williams
Cc: Wei Yang
Cc: Qian Cai
Cc: Jason Gunthorpe
Cc: Logan Gunthorpe
Cc: Ira Weiny
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug")
Signed-off-by: David Hildenbrand
---
arch/arm64/mm/mmu.c| 4 +---
arch/ia64/mm/init.c| 4 +---
arch/powerpc/mm/mem.c | 3 +--
arch/s390/mm/init.c| 4 +---
arch/sh/mm/init.c | 4 +---
arch/x86/mm/init_32.c | 4 +---
arch/x86/mm/init_64.c | 4 +---
include/linux/memory_hotplug.h | 7 +--
mm/memory_hotplug.c| 31 ---
mm/memremap.c | 2 +-
10 files changed, 29 insertions(+), 38 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 60c929f3683b..d10247fab0fd 100644
---
Re: [PATCH 08/10] nvdimm: Add driver for OpenCAPI Storage Class Memory
Hi Alastair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on char-misc/char-misc-testing]
[cannot apply to v5.4-rc5 next-20191025]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Alastair-D-Silva/Add-support-for-OpenCAPI-SCM-devices/20191028-043750
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
da80d2e516eb858eb5bcca7fa5f5a13ed86930e4
config: s390-allmodconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=s390
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/misc/ocxl/main.c: In function 'init_ocxl':
>> drivers/misc/ocxl/main.c:12:7: error: 'tlbie_capable' undeclared (first use
>> in this function); did you mean 'iommu_capable'?
if (!tlbie_capable)
^
iommu_capable
drivers/misc/ocxl/main.c:12:7: note: each undeclared identifier is reported
only once for each function it appears in
--
drivers/misc/ocxl/core.c: In function 'ocxl_function_open':
>> drivers/misc/ocxl/core.c:546:7: error: implicit declaration of function
>> 'radix_enabled'; did you mean 'zdev_enabled'?
>> [-Werror=implicit-function-declaration]
if (!radix_enabled()) {
^
zdev_enabled
cc1: some warnings being treated as errors
vim +12 drivers/misc/ocxl/main.c
5ef3166e8a32d7 Frederic Barrat 2018-01-23 7
5ef3166e8a32d7 Frederic Barrat 2018-01-23 8 static int __init init_ocxl(void)
5ef3166e8a32d7 Frederic Barrat 2018-01-23 9 {
5ef3166e8a32d7 Frederic Barrat 2018-01-23 10 int rc = 0;
5ef3166e8a32d7 Frederic Barrat 2018-01-23 11
2275d7b5754a57 Nicholas Piggin 2019-09-03 @12 if (!tlbie_capable)
2275d7b5754a57 Nicholas Piggin 2019-09-03 13 return -EINVAL;
2275d7b5754a57 Nicholas Piggin 2019-09-03 14
5ef3166e8a32d7 Frederic Barrat 2018-01-23 15 rc = ocxl_file_init();
5ef3166e8a32d7 Frederic Barrat 2018-01-23 16 if (rc)
5ef3166e8a32d7 Frederic Barrat 2018-01-23 17 return rc;
5ef3166e8a32d7 Frederic Barrat 2018-01-23 18
5ef3166e8a32d7 Frederic Barrat 2018-01-23 19 rc =
pci_register_driver(_pci_driver);
5ef3166e8a32d7 Frederic Barrat 2018-01-23 20 if (rc) {
5ef3166e8a32d7 Frederic Barrat 2018-01-23 21 ocxl_file_exit();
5ef3166e8a32d7 Frederic Barrat 2018-01-23 22 return rc;
5ef3166e8a32d7 Frederic Barrat 2018-01-23 23 }
5ef3166e8a32d7 Frederic Barrat 2018-01-23 24 return 0;
5ef3166e8a32d7 Frederic Barrat 2018-01-23 25 }
5ef3166e8a32d7 Frederic Barrat 2018-01-23 26
:: The code at line 12 was first introduced by commit
:: 2275d7b5754a573ffb2ca9e40bd0546eeb986696 powerpc/64s/radix: introduce
options to disable use of the tlbie instruction
:: TO: Nicholas Piggin
:: CC: Michael Ellerman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 04/10] powerpc: Map & release OpenCAPI LPC memory
Hi Alastair, Thank you for the patch! Yet something to improve: [auto build test ERROR on char-misc/char-misc-testing] [cannot apply to v5.4-rc5 next-20191025] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Alastair-D-Silva/Add-support-for-OpenCAPI-SCM-devices/20191028-043750 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git da80d2e516eb858eb5bcca7fa5f5a13ed86930e4 config: mips-allmodconfig (attached as .config) compiler: mips-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=mips If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from include/linux/mmzone.h:811:0, from include/linux/gfp.h:6, from include/linux/xarray.h:14, from include/linux/radix-tree.h:18, from include/linux/idr.h:15, from include/linux/kernfs.h:13, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/of.h:17, from include/linux/clk-provider.h:9, from arch/mips/generic/init.c:8: >> include/linux/memory_hotplug.h:342:5: error: "CONFIG_MEMORY_HOTPLUG_SPARSE" >> is not defined, evaluates to 0 [-Werror=undef] #if CONFIG_MEMORY_HOTPLUG_SPARSE ^~~~ cc1: all warnings being treated as errors vim +/CONFIG_MEMORY_HOTPLUG_SPARSE +342 include/linux/memory_hotplug.h 341 > 342 #if CONFIG_MEMORY_HOTPLUG_SPARSE 343 int check_hotplug_memory_addressable(unsigned long pfn, 344 unsigned long nr_pages); 345 #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */ 346 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 04/10] powerpc: Map & release OpenCAPI LPC memory
Hi Alastair, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on char-misc/char-misc-testing] [also build test WARNING on v5.4-rc5] [cannot apply to next-20191025] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Alastair-D-Silva/Add-support-for-OpenCAPI-SCM-devices/20191028-043750 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git da80d2e516eb858eb5bcca7fa5f5a13ed86930e4 config: i386-tinyconfig (attached as .config) compiler: gcc-7 (Debian 7.4.0-14) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): In file included from include/linux/mmzone.h:811:0, from include/linux/gfp.h:6, from include/linux/mm.h:10, from include/linux/pid_namespace.h:7, from include/linux/ptrace.h:10, from include/linux/audit.h:13, from security/commoncap.c:6: >> include/linux/memory_hotplug.h:342:5: warning: >> "CONFIG_MEMORY_HOTPLUG_SPARSE" is not defined, evaluates to 0 [-Wundef] #if CONFIG_MEMORY_HOTPLUG_SPARSE ^~~~ -- In file included from include/linux/mmzone.h:811:0, from include/linux/gfp.h:6, from include/linux/slab.h:15, from include/linux/crypto.h:19, from arch/x86/kernel/asm-offsets.c:9: >> include/linux/memory_hotplug.h:342:5: warning: >> "CONFIG_MEMORY_HOTPLUG_SPARSE" is not defined, evaluates to 0 [-Wundef] #if CONFIG_MEMORY_HOTPLUG_SPARSE ^~~~ 7 real 4 user 3 sys 112.50% cpu make prepare vim +/CONFIG_MEMORY_HOTPLUG_SPARSE +342 include/linux/memory_hotplug.h 341 > 342 #if CONFIG_MEMORY_HOTPLUG_SPARSE 343 int check_hotplug_memory_addressable(unsigned long pfn, 344 unsigned long nr_pages); 345 #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */ 346 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.
On Sun, Oct 27, 2019 at 10:21:25AM +0100, Christophe Leroy wrote: > Le 27/10/2019 à 01:06, Segher Boessenkool a écrit : > >The hand-optimised asm code will pretty likely win handsomely, whatever > >you do. Especially on cores like the 885 (no branch prediction, single > >issue, small caches, etc.: every instruction counts). > > > >Is there any reason to replace this hand-optimised code? It was written > >for exacty this reason? These functions are critical and should be as > >fast as possible. > > Well, all this started with COARSE clocks not being supported by PPC32 > VDSO. I first submitted a series with a set of optimisations including > the implementation of COARSE clocks > (https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=126779) > > Then after a comment received on patch 4 of the series from Santosh > Sivaraj asking for a common implementation of it for PPC32 and PPC64, I > started looking into making the whole VDSO source code common to PPC32 > and PPC64. Most functions are similar. Time functions are also rather > similar but unfortunately don't use the same registers. They also don't > cover all possible clocks. And getres() is also buggy, see series > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=110321 That is all nice work :-) > So instead of reworking the existing time functions, I started > investigating whether we could plug powerpc to the generic > implementation. One drawback of PPC is that we need to setup an ASM > trampoline to handle the SO bit as it can't be handled from C directly, > can it ? There is no way to say what CR bits to return. The ABI requires some of those bits to be preserved, and some are volatile. System calls use a different ABI, one the compiler knows nothing about, so you cannot even show system calls as calls to the compiler. > How critical are these functions ? Although we have a slight degration > with the C implementation, they are still way faster than the > corresponding syscall. "Slight": With current powerpc/32 ASM VDSO: gettimeofday:vdso: 750 nsec/call clock-getres-realtime:vdso: 382 nsec/call clock-gettime-realtime:vdso: 928 nsec/call clock-getres-monotonic:vdso: 382 nsec/call clock-gettime-monotonic:vdso: 1033 nsec/call Once switched to C implementation: gettimeofday:vdso: 1533 nsec/call clock-getres-realtime:vdso: 853 nsec/call clock-gettime-realtime:vdso: 1570 nsec/call clock-getres-monotonic:vdso: 835 nsec/call clock-gettime-monotonic:vdso: 1605 nsec/call ---> Those that are not more than two times slower are almost that. <--- This also needs measurements on more representative PowerPC cores, say some G3 or G4; and on modern CPUs (Power7/8/9). It also needs context with those measurements: what CPU core is it? Running at what frequency clock? > Another thing I was wondering, is it worth using the 64 bit timebase on > PPC32 ? As far as I understand, the timebase is there to calculate a > linear date update since last VDSO datapage update. How often is the > VDSO datapage updated ? On the 885 clocked at 132Mhz, the timebase is at > 8.25 Mhz, which means it needs more than 8 minutes to loop over 32 bits. On most PowerPC cores the time base is incremented significantly faster. Usual speeds for older cores are 50MHz to 100MHz, and for newer cores ten times that. Recommended frequency is currently 512MHz, so you'll wrap the low 32 bits in 8s or so on those, and in about a minute on many powermac etc. machines already. How can you know this long hasn't passed since the last time you read the high half of the time base? Without reading that high part? The current (assembler) code already optimises converting this to some other scale quite well, better than a compiler can (see __do_get_tspec). Segher
Re: [PATCH v6 25/30] PNP: Don't reserve BARs for PCI when enabled movable BARs
Hi Sergey,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on v5.4-rc4 next-20191025]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sergey-Miroshnichenko/PCI-Allow-BAR-movement-during-hotplug/20191028-002741
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-alldefconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-14) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/pnp/system.c: In function 'reserve_resources_of_dev':
>> drivers/pnp/system.c:62:6: error: 'pci_can_move_bars' undeclared (first use
>> in this function); did you mean 'pci_cap_saved_data'?
if (pci_can_move_bars)
^
pci_cap_saved_data
drivers/pnp/system.c:62:6: note: each undeclared identifier is reported only
once for each function it appears in
vim +62 drivers/pnp/system.c
56
57 static void reserve_resources_of_dev(struct pnp_dev *dev)
58 {
59 struct resource *res;
60 int i;
61
> 62 if (pci_can_move_bars)
63 return;
64
65 for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_IO, i));
i++) {
66 if (res->flags & IORESOURCE_DISABLED)
67 continue;
68 if (res->start == 0)
69 continue; /* disabled */
70 if (res->start < 0x100)
71 /*
72 * Below 0x100 is only standard PC hardware
73 * (pics, kbd, timer, dma, ...)
74 * We should not get resource conflicts there,
75 * and the kernel reserves these anyway
76 * (see arch/i386/kernel/setup.c).
77 * So, do nothing
78 */
79 continue;
80 if (res->end < res->start)
81 continue; /* invalid */
82
83 reserve_range(dev, res, 1);
84 }
85
86 for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i));
i++) {
87 if (res->flags & IORESOURCE_DISABLED)
88 continue;
89
90 reserve_range(dev, res, 0);
91 }
92 }
93
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH RESEND v14 2/6] namei: LOOKUP_IN_ROOT: chroot-like path resolution
On 2019-10-27, Linus Torvalds wrote:
> On Sat, Oct 26, 2019 at 2:58 PM Aleksa Sarai wrote:
> >
> > + /* LOOKUP_IN_ROOT treats absolute paths as being relative-to-dirfd.
> > */
> > + if (flags & LOOKUP_IN_ROOT)
> > + while (*s == '/')
> > + s++;
> > +
> > /* Figure out the starting path and root (if needed). */
> > if (*s == '/') {
> > error = nd_jump_root(nd);
>
> So I'm still hung up on this.
>
> I guess I can't help it, but I look at the above, and it makes me go
> "whoever wrote those tests wasn't thinking".
>
> It just annoys me how it tests for '/' completely unnecessarily.
>
> If LOOKUP_IN_ROOT is true, we know the subsequent test for '/' is not
> going to match, because we just removed it. So I look at that code and
> go "that code is doing stupid things".
Okay, fair enough.
> That's why I suggested moving the LOOKUP_IN_ROOT check inside the '/' test.
>
> Alternatively, just make the logic be
>
> if (flags & LOOKUP_IN_ROOT) {
>.. remove '/'s ...
> } else if (*s == '/') {
> .. handl;e root ..
>
> and remove the next "else" clause
I've gone with the latter since I think it reads better.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
Re: [PATCH RESEND v14 2/6] namei: LOOKUP_IN_ROOT: chroot-like path resolution
On Sat, Oct 26, 2019 at 2:58 PM Aleksa Sarai wrote:
>
> + /* LOOKUP_IN_ROOT treats absolute paths as being relative-to-dirfd. */
> + if (flags & LOOKUP_IN_ROOT)
> + while (*s == '/')
> + s++;
> +
> /* Figure out the starting path and root (if needed). */
> if (*s == '/') {
> error = nd_jump_root(nd);
So I'm still hung up on this.
I guess I can't help it, but I look at the above, and it makes me go
"whoever wrote those tests wasn't thinking".
It just annoys me how it tests for '/' completely unnecessarily.
If LOOKUP_IN_ROOT is true, we know the subsequent test for '/' is not
going to match, because we just removed it. So I look at that code and
go "that code is doing stupid things".
That's why I suggested moving the LOOKUP_IN_ROOT check inside the '/' test.
Alternatively, just make the logic be
if (flags & LOOKUP_IN_ROOT) {
.. remove '/'s ...
} else if (*s == '/') {
.. handl;e root ..
and remove the next "else" clause
Linus
Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.
Le 27/10/2019 à 01:06, Segher Boessenkool a écrit :
On Sat, Oct 26, 2019 at 08:48:27PM +0200, Thomas Gleixner wrote:
On Sat, 26 Oct 2019, Christophe Leroy wrote:
Let's look at the code:
__cvdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
{
const struct vdso_data *vd = __arch_get_vdso_data();
if (likely(tv != NULL)) {
struct __kernel_timespec ts;
if (do_hres([CS_HRES_COARSE], CLOCK_REALTIME, ))
return gettimeofday_fallback(tv, tz);
tv->tv_sec = ts.tv_sec;
tv->tv_usec = (u32)ts.tv_nsec / NSEC_PER_USEC;
IIRC PPC did some magic math tricks to avoid that. Could you just for the
fun of it replace this division with
(u32)ts.tv_nsec >> 10;
On this particular CPU (the 885, right?) a division by 1000 is just 9
cycles. On other CPUs it can be more, say 19 cycles like on the 750; not
cheap at all, but not hugely expensive either, comparatively.
(A 64/32->32 division is expensive on all 32-bit PowerPC: there is no
hardware help for it at all, so it's all done in software.)
Of course the compiler won't do a division by a constant with a division
instruction at all, so it's somewhat cheaper even, 5 or 6 cycles or so.
One thing which might be worth to try as well is to mark all functions in
that file as inline. The speedup by the do_hres() inlining was impressive
on PPC.
The hand-optimised asm code will pretty likely win handsomely, whatever
you do. Especially on cores like the 885 (no branch prediction, single
issue, small caches, etc.: every instruction counts).
Is there any reason to replace this hand-optimised code? It was written
for exacty this reason? These functions are critical and should be as
fast as possible.
Well, all this started with COARSE clocks not being supported by PPC32
VDSO. I first submitted a series with a set of optimisations including
the implementation of COARSE clocks
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=126779)
Then after a comment received on patch 4 of the series from Santosh
Sivaraj asking for a common implementation of it for PPC32 and PPC64, I
started looking into making the whole VDSO source code common to PPC32
and PPC64. Most functions are similar. Time functions are also rather
similar but unfortunately don't use the same registers. They also don't
cover all possible clocks. And getres() is also buggy, see series
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=110321
So instead of reworking the existing time functions, I started
investigating whether we could plug powerpc to the generic
implementation. One drawback of PPC is that we need to setup an ASM
trampoline to handle the SO bit as it can't be handled from C directly,
can it ?
How critical are these functions ? Although we have a slight degration
with the C implementation, they are still way faster than the
corresponding syscall.
Another thing I was wondering, is it worth using the 64 bit timebase on
PPC32 ? As far as I understand, the timebase is there to calculate a
linear date update since last VDSO datapage update. How often is the
VDSO datapage updated ? On the 885 clocked at 132Mhz, the timebase is at
8.25 Mhz, which means it needs more than 8 minutes to loop over 32 bits.
Christophe
