Re: [PATCH v2 0/6] KVM: PPC: Book3S: HV: XIVE: Allocate less VPs in OPAL

2019-10-20 Thread Paul Mackerras
On Wed, Oct 16, 2019 at 11:44:03PM +0200, Greg Kurz wrote:
> On Fri, 27 Sep 2019 13:53:32 +0200
> Greg Kurz  wrote:
> 
> > This brings some fixes and allows to start more VMs with an in-kernel
> > XIVE or XICS-on-XIVE device.
> > 
> > Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
> > - drop a useless patch
> > - add a patch to show VP ids in debugfs
> > - update some changelogs
> > - fix buggy check in patch 5
> > - Cc: stable 
> > 
> > --
> > Greg
> > 
> > ---
> > 
> > Greg Kurz (6):
> >   KVM: PPC: Book3S HV: XIVE: Set kvm->arch.xive when VPs are allocated
> >   KVM: PPC: Book3S HV: XIVE: Ensure VP isn't already in use
> >   KVM: PPC: Book3S HV: XIVE: Show VP id in debugfs
> >   KVM: PPC: Book3S HV: XIVE: Compute the VP id in a common helper
> >   KVM: PPC: Book3S HV: XIVE: Make VP block size configurable
> >   KVM: PPC: Book3S HV: XIVE: Allow userspace to set the # of VPs
> > 
> > 
> >  Documentation/virt/kvm/devices/xics.txt |   14 +++
> >  Documentation/virt/kvm/devices/xive.txt |8 ++
> >  arch/powerpc/include/uapi/asm/kvm.h |3 +
> >  arch/powerpc/kvm/book3s_xive.c  |  142 
> > ---
> >  arch/powerpc/kvm/book3s_xive.h  |   17 
> >  arch/powerpc/kvm/book3s_xive_native.c   |   40 +++--
> >  6 files changed, 167 insertions(+), 57 deletions(-)
> > 
> 
> Ping ?

I'm about to send a pull request to Paolo for 2/6 (to go into 5.4) and
I'm preparing a tree of stuff for 5.5 that will include the rest of
the patches.  However, I have been delayed by the fact that multipath
SCSI is currently broken upstream on the P8 test box that I use, so I
haven't been able to test things.

Paul.


[PATCH v7 1/3] PM: wakeup: Add routine to help fetch wakeup source object.

2019-10-20 Thread Ran Wang
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. So add this API to help walk through all registered
wakeup source objects on that list and return them one by one.

Signed-off-by: Ran Wang 
Tested-by: Leonard Crestez 
---
Change in v7:
- Remove define of member *dev in wake_irq to fix conflict with commit 
c8377adfa781 ("PM / wakeup: Show wakeup sources stats in sysfs"), user 
will use ws->dev->parent instead.
- Remove '#include ' because it is not used.

Change in v6:
- Add wakeup_source_get_star() and wakeup_source_get_stop() to aligned 
with wakeup_sources_stats_seq_start/nex/stop.

Change in v5:
- Update commit message, add decription of walk through all wakeup
source objects.
- Add SCU protection in function wakeup_source_get_next().
- Rename wakeup_source member 'attached_dev' to 'dev' and move it up
(before wakeirq).

Change in v4:
- None.

Change in v3:
- Adjust indentation of *attached_dev;.

Change in v2:
- None.

 drivers/base/power/wakeup.c | 37 +
 include/linux/pm_wakeup.h   |  3 +++
 2 files changed, 40 insertions(+)

diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 5817b51..dee1b09 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -248,6 +248,43 @@ void wakeup_source_unregister(struct wakeup_source *ws)
 EXPORT_SYMBOL_GPL(wakeup_source_unregister);
 
 /**
+ * wakeup_source_get_star - Begin a walk on wakeup source list
+ * @srcuidx: Lock index allocated for this caller.
+ */
+struct wakeup_source *wakeup_source_get_start(int *srcuidx)
+{
+   struct list_head *ws_head = _sources;
+
+   *srcuidx = srcu_read_lock(_srcu);
+
+   return list_entry_rcu(ws_head->next, struct wakeup_source, entry);
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_start);
+
+/**
+ * wakeup_source_get_next - Get next wakeup source from the list
+ * @ws: Previous wakeup source object
+ */
+struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
+{
+   struct list_head *ws_head = _sources;
+
+   return list_next_or_null_rcu(ws_head, >entry,
+   struct wakeup_source, entry);
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_next);
+
+/**
+ * wakeup_source_get_stop - Stop a walk on wakeup source list
+ * @idx: Dedicated lock index of this caller.
+ */
+void wakeup_source_get_stop(int idx)
+{
+   srcu_read_unlock(_srcu, idx);
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_stop);
+
+/**
  * device_wakeup_attach - Attach a wakeup source object to a device object.
  * @dev: Device to handle.
  * @ws: Wakeup source object to attach to @dev.
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 661efa0..172e76c 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -92,6 +92,9 @@ extern void wakeup_source_remove(struct wakeup_source *ws);
 extern struct wakeup_source *wakeup_source_register(struct device *dev,
const char *name);
 extern void wakeup_source_unregister(struct wakeup_source *ws);
+extern struct wakeup_source *wakeup_source_get_start(int *srcuidx);
+extern struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws);
+extern void wakeup_source_get_stop(int idx);
 extern int device_wakeup_enable(struct device *dev);
 extern int device_wakeup_disable(struct device *dev);
 extern void device_set_wakeup_capable(struct device *dev, bool capable);
-- 
2.7.4



[PATCH v7 3/3] soc: fsl: add RCPM driver

2019-10-20 Thread Ran Wang
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs system level
tasks associated with power management such as wakeup source control.

This driver depends on PM wakeup source framework which help to
collect wake information.

Signed-off-by: Ran Wang 
---
Change in v7:
- Replace 'ws->dev' with 'ws->dev->parent' to get aligned with
c8377adfa781 ("PM / wakeup: Show wakeup sources stats in sysfs")
- Remove '+obj-y += ftm_alarm.o' since it is wrong.
- Cosmetic work.

Change in v6:
- Adjust related API usage to meet wakeup.c's update in patch 1/3.

Change in v5:
- Fix v4 regression of the return value of wakeup_source_get_next()
didn't pass to ws in while loop.
- Rename wakeup_source member 'attached_dev' to 'dev'.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/

Change in v4:
- Remove extra ',' in author line of rcpm.c
- Update usage of wakeup_source_get_next() to be less confusing to the
reader, code logic remain the same.

Change in v3:
- Some whitespace ajdustment.

Change in v2:
- Rebase Kconfig and Makefile update to latest mainline.

 drivers/soc/fsl/Kconfig  |   8 +++
 drivers/soc/fsl/Makefile |   1 +
 drivers/soc/fsl/rcpm.c   | 132 +++
 3 files changed, 141 insertions(+)
 create mode 100644 drivers/soc/fsl/rcpm.c

diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index f9ad8ad..4918856 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -40,4 +40,12 @@ config DPAA2_CONSOLE
  /dev/dpaa2_mc_console and /dev/dpaa2_aiop_console,
  which can be used to dump the Management Complex and AIOP
  firmware logs.
+
+config FSL_RCPM
+   bool "Freescale RCPM support"
+   depends on PM_SLEEP
+   help
+ The NXP QorIQ Processors based on ARM Core have RCPM module
+ (Run Control and Power Management), which performs all device-level
+ tasks associated with power management, such as wakeup source control.
 endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 71dee8d..906f1cd 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_FSL_DPAA) += qbman/
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_FSL_RCPM) += rcpm.o
 obj-$(CONFIG_FSL_GUTS) += guts.o
 obj-$(CONFIG_FSL_MC_DPIO)  += dpio/
 obj-$(CONFIG_DPAA2_CONSOLE)+= dpaa2-console.o
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 000..3da9fc3
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// rcpm.c - Freescale QorIQ RCPM driver
+//
+// Copyright 2019 NXP
+//
+// Author: Ran Wang 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RCPM_WAKEUP_CELL_MAX_SIZE  7
+
+struct rcpm {
+   unsigned intwakeup_cells;
+   void __iomem*ippdexpcr_base;
+   boollittle_endian;
+};
+
+static int rcpm_pm_prepare(struct device *dev)
+{
+   int i, ret, idx;
+   void __iomem *base;
+   struct wakeup_source*ws;
+   struct rcpm *rcpm;
+   struct device_node  *np = dev->of_node;
+   u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
+
+   rcpm = dev_get_drvdata(dev);
+   if (!rcpm)
+   return -EINVAL;
+
+   base = rcpm->ippdexpcr_base;
+
+   /* Begin with first registered wakeup source */
+   ws = wakeup_source_get_start();
+   do {
+   /* skip object which is not attached to device */
+   if (!ws->dev->parent)
+   continue;
+
+   ret = device_property_read_u32_array(ws->dev->parent,
+   "fsl,rcpm-wakeup", value,
+   rcpm->wakeup_cells + 1);
+
+   /*  Wakeup source should refer to current rcpm device */
+   if (ret || (np->phandle != value[0])) {
+   dev_info(dev, "%s doesn't refer to this rcpm\n",
+   ws->name);
+   continue;
+   }
+
+   for (i = 0; i < rcpm->wakeup_cells; i++) {
+   /* We can only OR related bits */
+   if (value[i + 1]) {
+   if (rcpm->little_endian) {
+   tmp = ioread32(base + i * 4);
+   tmp |= value[i + 1];
+   iowrite32(tmp, base + i * 4);
+   } else {
+   tmp = ioread32be(base + 

[PATCH v7 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define

2019-10-20 Thread Ran Wang
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are
Little Endian. So add this optional property to help identify
them.

Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.

Signed-off-by: Ran Wang 
Reviewed-by: Rob Herring 
---
Change in v7:
- None.

Change in v6:
- None.

Change in v5:
- Add 'Reviewed-by: Rob Herring ' to commit message.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/

Change in v4:
- Adjust indectation of 'ls1021a, ls1012a, ls1043a, ls1046a'.

Change in v3:
- None.

Change in v2:
- None.

 Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index e284e4e..5a33619 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -5,7 +5,7 @@ and power management.
 
 Required properites:
   - reg : Offset and length of the register set of the RCPM block.
-  - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
+  - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
fsl,rcpm-wakeup property.
   - compatible : Must contain a chip-specific RCPM block compatible string
and (if applicable) may contain a chassis-version RCPM compatible
@@ -20,6 +20,7 @@ Required properites:
* "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
+   * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm
 
 All references to "1.0" and "2.0" refer to the QorIQ chassis version to
 which the chip complies.
@@ -27,14 +28,19 @@ Chassis Version Example Chips
 ------
 1.0p4080, p5020, p5040, p2041, p3041
 2.0t4240, b4860, b4420
-2.1t1040, ls1021
+2.1t1040,
+2.1+   ls1021a, ls1012a, ls1043a, ls1046a
+
+Optional properties:
+ - little-endian : RCPM register block is Little Endian. Without it RCPM
+   will be Big Endian (default case).
 
 Example:
 The RCPM node for T4240:
rcpm: global-utilities@e2000 {
compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
reg = <0xe2000 0x1000>;
-   fsl,#rcpm-wakeup-cells = <2>;
+   #fsl,rcpm-wakeup-cells = <2>;
};
 
 * Freescale RCPM Wakeup Source Device Tree Bindings
@@ -44,7 +50,7 @@ can be used as a wakeup source.
 
   - fsl,rcpm-wakeup: Consists of a phandle to the rcpm node and the IPPDEXPCR
register cells. The number of IPPDEXPCR register cells is defined in
-   "fsl,#rcpm-wakeup-cells" in the rcpm node. The first register cell is
+   "#fsl,rcpm-wakeup-cells" in the rcpm node. The first register cell is
the bit mask that should be set in IPPDEXPCR0, and the second register
cell is for IPPDEXPCR1, and so on.
 
-- 
2.7.4



Re: [PATCH v7 00/12] implement KASLR for powerpc/fsl_booke/32

2019-10-20 Thread Jason Yan




On 2019/10/10 2:46, Scott Wood wrote:

On Wed, 2019-10-09 at 16:41 +0800, Jason Yan wrote:

Hi Scott,

On 2019/10/9 15:13, Scott Wood wrote:

On Wed, 2019-10-09 at 14:10 +0800, Jason Yan wrote:

Hi Scott,

Would you please take sometime to test this?

Thank you so much.

On 2019/9/24 13:52, Jason Yan wrote:

Hi Scott,

Can you test v7 to see if it works to load a kernel at a non-zero
address?

Thanks,


Sorry for the delay.  Here's the output:



Thanks for the test.


## Booting kernel from Legacy Image at 1000 ...
 Image Name:   Linux-5.4.0-rc2-00050-g8ac2cf5b4
 Image Type:   PowerPC Linux Kernel Image (gzip compressed)
 Data Size:7521134 Bytes = 7.2 MiB
 Load Address: 0400
 Entry Point:  0400
 Verifying Checksum ... OK
## Flattened Device Tree blob at 1fc0
 Booting using the fdt blob at 0x1fc0
 Uncompressing Kernel Image ... OK
 Loading Device Tree to 07fe, end 07fff65c ... OK
KASLR: No safe seed for randomizing the kernel base.
OF: reserved mem: initialized node qman-fqd, compatible id fsl,qman-fqd
OF: reserved mem: initialized node qman-pfdr, compatible id fsl,qman-pfdr
OF: reserved mem: initialized node bman-fbpr, compatible id fsl,bman-fbpr
Memory CAM mapping: 64/64/64 Mb, residual: 12032Mb


When boot from 0400, the max CAM value is 64M. And
you have a board with 12G memory, CONFIG_LOWMEM_CAM_NUM=3 means only
192M memory is mapped and when kernel is randomized at the middle of
this 192M memory, we will not have enough continuous memory for node map.

Can you set CONFIG_LOWMEM_CAM_NUM=8 and see if it works?


OK, that worked.



Hi Scott, any more cases should be tested or any more comments?
What else need to be done before this feature can be merged?

Thanks,
Jason


-Scott



.





[PATCH V7] mm/debug: Add tests validating architecture page table helpers

2019-10-20 Thread Anshuman Khandual
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 
---
 .../debug/debug-vm-pgtable/arch-support.txt|  34 ++
 arch/arm64/Kconfig |   1 +
 arch/x86/Kconfig   |   1 +
 arch/x86/include/asm/pgtable_64.h  |   6 +
 include/asm-generic/pgtable.h  |   6 +
 init/main.c|   1 +
 lib/Kconfig.debug  |  21 ++
 mm/Makefile|   1 +
 mm/debug_vm_pgtable.c  | 388 +
 9 files changed, 459 insertions(+)
 create mode 100644 
Documentation/features/debug/debug-vm-pgtable/arch-support.txt
 create mode 100644 mm/debug_vm_pgtable.c

diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt 
b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
new file mode 100644
index 000..d6b8185
--- /dev/null
+++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
@@ -0,0 +1,34 @@
+#
+# Feature name:  debug-vm-pgtable
+# Kconfig:   ARCH_HAS_DEBUG_VM_PGTABLE
+# description:   arch supports pgtable tests for semantics compliance
+#
+---
+| arch |status|
+---
+|   alpha: | TODO |
+| arc: | TODO |
+| arm: | TODO |
+|   arm64: |  ok  |
+| c6x: | TODO |
+|csky: | TODO |
+|   h8300: | TODO |
+| hexagon: | TODO |
+|ia64: | TODO |
+|m68k: | TODO |
+|  microblaze: | TODO |
+|mips: | TODO |
+|   nds32: | TODO |
+|   nios2: | TODO |
+|openrisc: | TODO |
+|  parisc: | TODO |
+| powerpc: | TODO |
+|   riscv: | TODO |
+|s390: | TODO |
+|  sh: | TODO |
+|   sparc: | TODO |
+|  um: | TODO |
+|   unicore32: | TODO |
+| x86: |  ok  |
+|  xtensa: | TODO |
+---
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b6ea5a..ea62c87 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,6 +11,7 @@ config ARM64
select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select 

[PATCH V7] mm/debug: Add tests validating architecture page table helpers

2019-10-20 Thread Anshuman Khandual
This series adds a test validation for architecture exported page table
helpers. Patch in the series 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-20191017) after reverting all commits
from V5 of this series.

Changes in V7:

- 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
- Renamed core test function arch_pgtable_tests() as debug_vm_pgtable()
- Renamed mm/arch_pgtable_test.c as mm/debug_vm_pgtable.c
- debug_vm_pgtable() gets called from kernel_init_freeable() after 
init_mm_internals()
- Added an entry in Documentation/features/debug/ per Ingo
- Enabled the test on arm64 and x86 platforms for now

Changes in V4: 
(https://patchwork.kernel.org/project/linux-mm/list/?series=183465)

- Disable DEBUG_ARCH_PGTABLE_TEST for ARM and IA64 platforms

Changes in V3: 
(https://lore.kernel.org/patchwork/project/lkml/list/?series=411216)

- Changed test trigger from module format into late_initcall()
- Marked all functions with __init to be freed after completion
- Changed all __PGTABLE_PXX_FOLDED checks as mm_pxx_folded()
- Folded in PPC32 fixes from Christophe

Changes in V2:

https://lore.kernel.org/linux-mm/1568268173-31302-1-git-send-email-anshuman.khand...@arm.com/T/#t

- Fixed small typo error in MODULE_DESCRIPTION()
- Fixed m64k build problems for lvalue concerns in pmd_xxx_tests()
- Fixed dynamic page table level folding problems on x86 as per Kirril
- Fixed second pointers during pxx_populate_tests() per Kirill and Gerald
- Allocate and free pte table with pte_alloc_one/pte_free per Kirill
- Modified pxx_clear_tests() to accommodate s390 lower 12 bits situation
- Changed RANDOM_NZVALUE value from 0xbe to 0xff
- Changed allocation, usage, free sequence for saved_ptep
- Renamed VMA_FLAGS as VMFLAGS
- Implemented a new method for random vaddr generation
- Implemented some other cleanups
- Dropped extern reference to mm_alloc()
- Created and exported new alloc_gigantic_page_order()
- Dropped the custom allocator and used new alloc_gigantic_page_order()

Changes in V1:

https://lore.kernel.org/linux-mm/1567497706-8649-1-git-send-email-anshuman.khand...@arm.com/

- Added fallback mechanism for PMD aligned memory allocation failure

Changes in RFC V2:

https://lore.kernel.org/linux-mm/1565335998-22553-1-git-send-email-anshuman.khand...@arm.com/T/#u

- Moved test module and it's config from lib/ to mm/
- Renamed config TEST_ARCH_PGTABLE as DEBUG_ARCH_PGTABLE_TEST
- Renamed file from test_arch_pgtable.c to arch_pgtable_test.c
- Added relevant MODULE_DESCRIPTION() and MODULE_AUTHOR() details
- Dropped loadable module config option
- Basic tests now use memory blocks with required size and alignment
- PUD aligned memory block gets allocated with alloc_contig_range()
- If PUD aligned memory could not be allocated it falls back on PMD aligned
  memory block from page allocator and pud_* tests are skipped
- Clear and populate tests now operate on real in memory page table entries
- Dummy mm_struct gets allocated with mm_alloc()
- Dummy page table entries get allocated with [pud|pmd|pte]_alloc_[map]()
- Simplified [p4d|pgd]_basic_tests(), now has random values in the entries

Original RFC V1:

https://lore.kernel.org/linux-mm/1564037723-26676-1-git-send-email-anshuman.khand...@arm.com/

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 

Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Andreas Schwab
On Okt 20 2019, Thomas Gleixner wrote:

> But for the sake of making a non-sensical specification happy we can add a
> NULL pointer check for this. The interesting question is what should be
> returned in this case.

0 if the clock id is valid, EINVAL otherwise.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Thomas Gleixner
On Sun, 20 Oct 2019, Andreas Schwab wrote:
> On Okt 20 2019, Thomas Gleixner wrote:
> 
> > POSIX does not mention anything about the validity of the pointer handed to
> > clock_getres().
> 
> Sure it does: "If the argument res is not NULL, the resolution of the
> specified clock shall be stored in the location pointed to by res.  If
> res is NULL, the clock resolution is not returned.".

Sigh, that makes a lot of sense - NOT.

But for the sake of making a non-sensical specification happy we can add a
NULL pointer check for this. The interesting question is what should be
returned in this case. The kernel returns EFAULT which is probably not
POSIX compliant either.

Patches are welcome.

Thanks,

tglx


Re: [PATCH v8 7/8] ima: check against blacklisted hashes for files with modsig

2019-10-20 Thread Mimi Zohar
On Sun, 2019-10-20 at 12:06 -0400, Mimi Zohar wrote:
> On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote:
> > Asymmetric private keys are used to sign multiple files. The kernel
> > currently support checking against blacklisted keys. However, if the
> > public key is blacklisted, any file signed by the blacklisted key will
> > automatically fail signature verification. We might not want to blacklist
> > all the files signed by a particular key, but just a single file.
> > Blacklisting the public key is not fine enough granularity.
> > 
> > This patch adds support for checking against the blacklisted hash of the
> > file based on the IMA policy. The blacklisted hash is the file hash
> > without the appended signature. Defined is a new policy option
> > "appraise_flag=check_blacklist".
> 
> Please add an example of how to blacklist a file with an appended
> signature.  The simplest example that works on x86 as well as Power
> would be blacklisting a kernel module.  The example should include
> calculating the kernel module hash without the appended signature,
> enabling the Kconfig option (CONFIG_SYSTEM_BLACKLIST_HASH_LIST), and
> the blacklist hash format (eg. "bin:").

And of course, the IMA appraise kernel module policy rule containing
"appraise_flag=check_blacklist".

thanks,

Mimi


Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Andreas Schwab
On Okt 20 2019, Thomas Gleixner wrote:

> POSIX does not mention anything about the validity of the pointer handed to
> clock_getres().

Sure it does: "If the argument res is not NULL, the resolution of the
specified clock shall be stored in the location pointed to by res.  If
res is NULL, the clock resolution is not returned.".

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


Re: [PATCH v8 7/8] ima: check against blacklisted hashes for files with modsig

2019-10-20 Thread Mimi Zohar
On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote:
> Asymmetric private keys are used to sign multiple files. The kernel
> currently support checking against blacklisted keys. However, if the
> public key is blacklisted, any file signed by the blacklisted key will
> automatically fail signature verification. We might not want to blacklist
> all the files signed by a particular key, but just a single file.
> Blacklisting the public key is not fine enough granularity.
> 
> This patch adds support for checking against the blacklisted hash of the
> file based on the IMA policy. The blacklisted hash is the file hash
> without the appended signature. Defined is a new policy option
> "appraise_flag=check_blacklist".

Please add an example of how to blacklist a file with an appended
signature.  The simplest example that works on x86 as well as Power
would be blacklisting a kernel module.  The example should include
calculating the kernel module hash without the appended signature,
enabling the Kconfig option (CONFIG_SYSTEM_BLACKLIST_HASH_LIST), and
the blacklist hash format (eg. "bin:").

thanks, 

Mimi



Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Thomas Gleixner
On Sun, 20 Oct 2019, Andreas Schwab wrote:

> On Okt 20 2019, Thomas Gleixner  wrote:
> 
> > clock_getres(NULL) is hardly valid.
> 
> Of course not, it lacks a parameter.

You know exactly what I mean.
 
> > So special casing
> >
> > clock_getres(clock, NULL);
> >
> > just to make a test case happy is a pointless exercise which does not make
> > any sense at all.
> 
> POSIX requires it to work.

POSIX does not mention anything about the validity of the pointer handed to
clock_getres().

https://pubs.opengroup.org/onlinepubs/9699919799/

 "The clock_getres(), clock_gettime(), and clock_settime() functions shall fail 
if:

   [EINVAL]
 The clock_id argument does not specify a known clock."

EINVAL is the only documented error code for clock_getres(). 

Again. The VDSO is not a syscall and therefore neither address space
validation of the supplied pointer nor catching an invalid access works
like it does in a syscall.

The only invalid pointer it can catch is NULL, but that's ONE case out of a
gazillion. So what's the value of catching NULL and only NULL?

If you can come up with a solution to handle invalid pointers in the VDSO
gracefully, then I'm surely all ears.

If not then can you please explain why VDSO usage worked without pointer
validation since the time VDSO was invented more than a decade ago and just
now requires full invalid pointer handling?

Thanks,

tglx


Re: [PATCH v8 3/8] powerpc: detect the trusted boot state of the system

2019-10-20 Thread Mimi Zohar
On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote:
> While secure boot permits only properly verified signed kernels to be
> booted, trusted boot takes a measurement of the kernel image prior to
> boot that can be subsequently compared against good known values via
> attestation services.
> 

Instead of "takes a measurement", either "stores a measurement" or
"calculates the file hash of the kernel image and stores the
measurement prior to boot, that".

> This patch reads the trusted boot state of a PowerNV system. The state
> is used to conditionally enable additional measurement rules in the IMA
> arch-specific policies.
> 
> Signed-off-by: Nayna Jain 
> ---
>  arch/powerpc/include/asm/secure_boot.h |  6 ++
>  arch/powerpc/kernel/secure_boot.c  | 24 
>  2 files changed, 30 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/secure_boot.h 
> b/arch/powerpc/include/asm/secure_boot.h
> index 07d0fe0ca81f..a2ff556916c6 100644
> --- a/arch/powerpc/include/asm/secure_boot.h
> +++ b/arch/powerpc/include/asm/secure_boot.h
> 
> diff --git a/arch/powerpc/kernel/secure_boot.c 
> b/arch/powerpc/kernel/secure_boot.c
> index 99bba7915629..9753470ab08a 100644
> --- a/arch/powerpc/kernel/secure_boot.c
> +++ b/arch/powerpc/kernel/secure_boot.c
> @@ -7,6 +7,17 @@
>  #include 
>  #include 
>  
> +static struct device_node *get_ppc_fw_sb_node(void)
> +{
> + static const struct of_device_id ids[] = {
> + { .compatible = "ibm,secureboot-v1", },
> + { .compatible = "ibm,secureboot-v2", },
> + {},
> + };
> +

scripts/checkpatch.pl is complaining that secureboot-v1, secureboot-v2 
are not documented in the device tree bindings.

Mimi



Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Andreas Schwab
On Okt 20 2019, Thomas Gleixner  wrote:

> clock_getres(NULL) is hardly valid.

Of course not, it lacks a parameter.

> So special casing
>
> clock_getres(clock, NULL);
>
> just to make a test case happy is a pointless exercise which does not make
> any sense at all.

POSIX requires it to work.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Thomas Gleixner
On Sun, 20 Oct 2019, Christophe Leroy wrote:
> Adding Thomas to the discussion as the commit is from him.
> 
> Le 20/10/2019 à 11:53, Andreas Schwab a écrit :
> > On Okt 20 2019, Christophe Leroy  wrote:
> > 
> > > Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
> > > > On Okt 19 2019, Christophe Leroy  wrote:
> > > > 
> > > > > Hi Nathan,
> > > > > 
> > > > > While trying to switch powerpc VDSO to C version of gettimeofday(),
> > > > > I'm
> > > > > getting the following kind of error with vdsotest:
> > > > > 
> > > > > passing NULL to clock_getres (VDSO): terminated by unexpected signal
> > > > > 11
> > > > > 
> > > > > Looking at commit a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL
> > > > > pointer checks"), it seems that signal 11 is expected when passing
> > > > > NULL
> > > > > pointer.
> > > > > 
> > > > > Any plan to fix vdsotest ?
> > > > 
> > > > Passing NULL to clock_getres is valid, and required to return
> > > > successfully if the clock id is valid.
> > > > 
> > > 
> > > Do you mean the following commit is wrong ?
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/lib/vdso?id=a9446a906f52292c52ecbd5be78eaa4d8395756c
> > 
> > If it causes a valid call to clock_getres to fail, then yes.

clock_getres(NULL) is hardly valid.

Fact is that 64bit did never check the pointer and unconditionally let the
NULL pointer dereference happen.

Also as documented in the change log, the vdso _cannot_ ever be fully
equivalent to the syscall.

The simple example:

struct timespec *ts = (struct timespec *) 0xFF;

clock_getres(clock, ts);

will fault in the VDSO, but not in the syscall.

VDSO can never ever guarantee that any of the clock_* functions will return
EFAULT if the provided pointer points outside of the accessible address
space, is mapped RO etc.

So special casing

clock_getres(clock, NULL);

just to make a test case happy is a pointless exercise which does not make
any sense at all.

Thanks,

tglx



Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Christophe Leroy

Adding Thomas to the discussion as the commit is from him.

Le 20/10/2019 à 11:53, Andreas Schwab a écrit :

On Okt 20 2019, Christophe Leroy  wrote:


Le 19/10/2019 à 21:18, Andreas Schwab a écrit :

On Okt 19 2019, Christophe Leroy  wrote:


Hi Nathan,

While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
getting the following kind of error with vdsotest:

passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

Looking at commit a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL
pointer checks"), it seems that signal 11 is expected when passing NULL
pointer.

Any plan to fix vdsotest ?


Passing NULL to clock_getres is valid, and required to return
successfully if the clock id is valid.



Do you mean the following commit is wrong ?

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/lib/vdso?id=a9446a906f52292c52ecbd5be78eaa4d8395756c


If it causes a valid call to clock_getres to fail, then yes.

Andreas.



Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Andreas Schwab
On Okt 20 2019, Christophe Leroy  wrote:

> Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
>> On Okt 19 2019, Christophe Leroy  wrote:
>>
>>> Hi Nathan,
>>>
>>> While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
>>> getting the following kind of error with vdsotest:
>>>
>>> passing NULL to clock_getres (VDSO): terminated by unexpected signal 11
>>>
>>> Looking at commit a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL
>>> pointer checks"), it seems that signal 11 is expected when passing NULL
>>> pointer.
>>>
>>> Any plan to fix vdsotest ?
>>
>> Passing NULL to clock_getres is valid, and required to return
>> successfully if the clock id is valid.
>>
>
> Do you mean the following commit is wrong ?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/lib/vdso?id=a9446a906f52292c52ecbd5be78eaa4d8395756c

If it causes a valid call to clock_getres to fail, then yes.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-20 Thread Christophe Leroy




Le 19/10/2019 à 21:18, Andreas Schwab a écrit :

On Okt 19 2019, Christophe Leroy  wrote:


Hi Nathan,

While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
getting the following kind of error with vdsotest:

passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

Looking at commit a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL
pointer checks"), it seems that signal 11 is expected when passing NULL
pointer.

Any plan to fix vdsotest ?


Passing NULL to clock_getres is valid, and required to return
successfully if the clock id is valid.



Do you mean the following commit is wrong ?

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/lib/vdso?id=a9446a906f52292c52ecbd5be78eaa4d8395756c

Christophe


Re: [PATCH] powerpc/32s: fix allow/prevent_user_access() when crossing segment boundaries.

2019-10-20 Thread Michael Ellerman
On Mon, 2019-10-14 at 16:51:28 UTC, Christophe Leroy wrote:
> Make sure starting addr is aligned to segment boundary so that when
> incrementing the segment, the starting address of the new segment is
> below the end address. Otherwise the last segment might get  missed.
> 
> Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access 
> Protection")
> Signed-off-by: Christophe Leroy 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/d10f60ae27d26d811e2a1bb39ded47df96d7499f

cheers