Re: [PATCH v2 1/2] powerpc/sstep: Add emulation support for ‘setb’ instruction

2021-05-26 Thread Sandipan Das



On 11/05/21 5:48 pm, Sathvika Vasireddy wrote:
> This adds emulation support for the following instruction:
>* Set Boolean (setb)
> 
> Signed-off-by: Sathvika Vasireddy 
> ---
>  arch/powerpc/lib/sstep.c | 22 ++
>  1 file changed, 22 insertions(+)
> 

LGTM.

Reviewed-by: Sandipan Das 


Re: [PATCH] powerpc/papr_scm: Add support for reporting dirty-shutdown-count

2021-05-26 Thread Santosh Sivaraj


Hi Vaibhav,

Vaibhav Jain  writes:

> Persistent memory devices like NVDIMMs can loose cached writes in case
> something prevents flush on power-fail. Such situations are termed as
> dirty shutdown and are exposed to applications as
> last-shutdown-state (LSS) flag and a dirty-shutdown-counter(DSC) as
> described at [1]. The latter being useful in conditions where multiple
> applications want to detect a dirty shutdown event without racing with
> one another.
>
> PAPR-NVDIMMs have so far only exposed LSS style flags to indicate a
> dirty-shutdown-state. This patch further adds support for DSC via the
> "ibm,persistence-failed-count" device tree property of an NVDIMM. This
> property is a monotonic increasing 64-bit counter thats an indication
> of number of times an NVDIMM has encountered a dirty-shutdown event
> causing persistence loss.
>
> Since this value is not expected to change after system-boot hence
> papr_scm reads & caches its value during NVDIMM probe and exposes it
> as a PAPR sysfs attributed named 'dirty_shutdown' to match the name of
> similarly named NFIT sysfs attribute. Also this value is available to
> libnvdimm via PAPR_PDSM_HEALTH payload. 'struct nd_papr_pdsm_health'
> has been extended to add a new member called 'dimm_dsc' presence of
> which is indicated by the newly introduced PDSM_DIMM_DSC_VALID flag.
>
> References:
> [1] https://pmem.io/documents/Dirty_Shutdown_Handling-V1.0.pdf
>
> Signed-off-by: Vaibhav Jain 
> ---
>  arch/powerpc/include/uapi/asm/papr_pdsm.h |  6 +
>  arch/powerpc/platforms/pseries/papr_scm.c | 30 +++
>  2 files changed, 36 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/papr_pdsm.h 
> b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> index 50ef95e2f5b1..82488b1e7276 100644
> --- a/arch/powerpc/include/uapi/asm/papr_pdsm.h
> +++ b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> @@ -77,6 +77,9 @@
>  /* Indicate that the 'dimm_fuel_gauge' field is valid */
>  #define PDSM_DIMM_HEALTH_RUN_GAUGE_VALID 1
>  
> +/* Indicate that the 'dimm_dsc' field is valid */
> +#define PDSM_DIMM_DSC_VALID 2
> +
>  /*
>   * Struct exchanged between kernel & ndctl in for PAPR_PDSM_HEALTH
>   * Various flags indicate the health status of the dimm.
> @@ -105,6 +108,9 @@ struct nd_papr_pdsm_health {
>  
>   /* Extension flag PDSM_DIMM_HEALTH_RUN_GAUGE_VALID */
>   __u16 dimm_fuel_gauge;
> +
> + /* Extension flag PDSM_DIMM_DSC_VALID */
> + __u64 dimm_dsc;
>   };
>   __u8 buf[ND_PDSM_PAYLOAD_MAX_SIZE];
>   };
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
> b/arch/powerpc/platforms/pseries/papr_scm.c
> index 11e7b90a3360..68f0d3d5e899 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -114,6 +114,9 @@ struct papr_scm_priv {
>   /* Health information for the dimm */
>   u64 health_bitmap;
>  
> + /* Holds the last known dirty shutdown counter value */
> + u64 dirty_shutdown_counter;
> +
>   /* length of the stat buffer as expected by phyp */
>   size_t stat_buffer_len;
>  };
> @@ -603,6 +606,16 @@ static int papr_pdsm_fuel_gauge(struct papr_scm_priv *p,
>   return rc;
>  }
>  
> +/* Add the dirty-shutdown-counter value to the pdsm */
> +static int papr_psdm_dsc(struct papr_scm_priv *p,
    should be pdsm
> +  union nd_pdsm_payload *payload)
> +{
> + payload->health.extension_flags |= PDSM_DIMM_DSC_VALID;
> + payload->health.dimm_dsc = p->dirty_shutdown_counter;
> +
> + return sizeof(struct nd_papr_pdsm_health);
> +}
> +
>  /* Fetch the DIMM health info and populate it in provided package. */
>  static int papr_pdsm_health(struct papr_scm_priv *p,
>   union nd_pdsm_payload *payload)
> @@ -646,6 +659,8 @@ static int papr_pdsm_health(struct papr_scm_priv *p,
>  
>   /* Populate the fuel gauge meter in the payload */
>   papr_pdsm_fuel_gauge(p, payload);
> + /* Populate the dirty-shutdown-counter field */
> + papr_psdm_dsc(p, payload);
  same typo

Thanks,
Santosh

>  
>   rc = sizeof(struct nd_papr_pdsm_health);
>  
> @@ -907,6 +922,16 @@ static ssize_t flags_show(struct device *dev,
>  }
>  DEVICE_ATTR_RO(flags);
>  
> +static ssize_t dirty_shutdown_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + struct nvdimm *dimm = to_nvdimm(dev);
> + struct papr_scm_priv *p = nvdimm_provider_data(dimm);
> +
> + return sysfs_emit(buf, "%llu\n", p->dirty_shutdown_counter);
> +}
> +DEVICE_ATTR_RO(dirty_shutdown);
> +
>  static umode_t papr_nd_attribute_visible(struct kobject *kobj,
>struct attribute *attr, int n)
>  {
> @@ -925,6 +950,7 @@ static umode_t papr_nd_attribute_visible(struct kobject 
> *kobj,
>  static struct attribute *papr_nd_attributes[] = 

Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks

2021-05-26 Thread James Morris
On Wed, 26 May 2021, Ondrej Mosnacek wrote:

> Thanks, Michael!
> 
> James/Paul, is there anything blocking this patch from being merged?
> Especially the BPF case is causing real trouble for people and the
> only workaround is to broadly allow lockdown::confidentiality in the
> policy.

It would be good to see more signoffs/reviews, especially from Paul, but 
he is busy with the io_uring stuff.

Let's see if anyone else can look at this in the next couple of days.

-- 
James Morris




Re: [PATCH] Revert "powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs"

2021-05-26 Thread Alexey Kardashevskiy




On 27/05/2021 00:45, Frederic Barrat wrote:

This reverts commit 3c0468d4451eb6b4f6604370639f163f9637a479.

That commit was breaking alignment guarantees for the DMA address when
allocating coherent mappings, as described in
Documentation/core-api/dma-api-howto.rst

It was also noticed by Mellanox' driver:
[ 1515.763621] mlx5_core c002:01:00.0: mlx5_frag_buf_alloc_node:146:(pid 
13402): unexpected map alignment: 0x08c61000, page_shift=16
[ 1515.763635] mlx5_core c002:01:00.0: mlx5_cqwq_create:181:(pid
13402): mlx5_frag_buf_alloc_node() failed, -12

Signed-off-by: Frederic Barrat 


Should it be

Fixes: 3c0468d4451e ("powerpc/kernel/iommu: Align size for 
IOMMU_PAGE_SIZE() to save TCEs")


?

Anyway,

Reviewed-by: Alexey Kardashevskiy 

I should have known better in the first place, sorry :-/ Thanks,



---
  arch/powerpc/kernel/iommu.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 57d6b85e9b96..2af89a5e379f 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -898,7 +898,6 @@ void *iommu_alloc_coherent(struct device *dev, struct 
iommu_table *tbl,
unsigned int order;
unsigned int nio_pages, io_order;
struct page *page;
-   size_t size_io = size;
  
  	size = PAGE_ALIGN(size);

order = get_order(size);
@@ -925,9 +924,8 @@ void *iommu_alloc_coherent(struct device *dev, struct 
iommu_table *tbl,
memset(ret, 0, size);
  
  	/* Set up tces to cover the allocated range */

-   size_io = IOMMU_PAGE_ALIGN(size_io, tbl);
-   nio_pages = size_io >> tbl->it_page_shift;
-   io_order = get_iommu_order(size_io, tbl);
+   nio_pages = size >> tbl->it_page_shift;
+   io_order = get_iommu_order(size, tbl);
mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL,
  mask >> tbl->it_page_shift, io_order, 0);
if (mapping == DMA_MAPPING_ERROR) {
@@ -942,9 +940,10 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t 
size,
 void *vaddr, dma_addr_t dma_handle)
  {
if (tbl) {
-   size_t size_io = IOMMU_PAGE_ALIGN(size, tbl);
-   unsigned int nio_pages = size_io >> tbl->it_page_shift;
+   unsigned int nio_pages;
  
+		size = PAGE_ALIGN(size);

+   nio_pages = size >> tbl->it_page_shift;
iommu_free(tbl, dma_handle, nio_pages);
size = PAGE_ALIGN(size);
free_pages((unsigned long)vaddr, get_order(size));



--
Alexey


[PATCH] powerpc/stacktrace: fix raise_backtrace_ipi() logic

2021-05-26 Thread Nathan Lynch
When smp_send_safe_nmi_ipi() indicates that the target CPU has
responded to the IPI, skip the remote paca inspection
fallback. Otherwise both the sending and target CPUs attempt the
backtrace, usually creating a misleading ("didn't respond to backtrace
IPI" is wrong) and interleaved mess:

[ 1658.929157][C7] rcu: Stack dump where RCU GP kthread last ran:
[ 1658.929223][C7] Sending NMI from CPU 7 to CPUs 1:
[ 1658.929303][C1] NMI backtrace for cpu 1
[ 1658.929303][C7] CPU 1 didn't respond to backtrace IPI, inspecting paca.
[ 1658.929362][C1] CPU: 1 PID: 325 Comm: kworker/1:1H Tainted: GW   
E 5.13.0-rc2+ #46
[ 1658.929405][C7] irq_soft_mask: 0x01 in_mce: 0 in_nmi: 0 current: 325 
(kworker/1:1H)
[ 1658.929465][C1] Workqueue: events_highpri test_work_fn [test_lockup]
[ 1658.929549][C7] Back trace of paca->saved_r1 (0xc57fb400) 
(possibly stale):
[ 1658.929592][C1] NIP:  c002cf50 LR: c00800820178 CTR: 
c002cfa0

Verified using the test_lockup module, e.g.

$ echo 5 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
$ insmod test_lockup.ko time_secs=1 iterations=10 state=R lock_rcu \
  touch_softlockup all_cpus

Fixes: 5cc05910f26e ("powerpc/64s: Wire up arch_trigger_cpumask_backtrace()")
Signed-off-by: Nathan Lynch 
---
 arch/powerpc/kernel/stacktrace.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index 1deb1bf331dd..e0ccc5a46d7e 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -174,11 +174,14 @@ static void raise_backtrace_ipi(cpumask_t *mask)
 {
unsigned int cpu;
 
+   if (cpumask_test_cpu(smp_processor_id(), mask)) {
+   handle_backtrace_ipi(NULL);
+   cpumask_clear_cpu(smp_processor_id(), mask);
+   }
+
for_each_cpu(cpu, mask) {
-   if (cpu == smp_processor_id())
-   handle_backtrace_ipi(NULL);
-   else
-   smp_send_safe_nmi_ipi(cpu, handle_backtrace_ipi, 5 * 
USEC_PER_SEC);
+   if (smp_send_safe_nmi_ipi(cpu, handle_backtrace_ipi, 5 * 
USEC_PER_SEC))
+   cpumask_clear_cpu(cpu, mask);
}
 
for_each_cpu(cpu, mask) {
-- 
2.31.1



Re: [PATCH 1/5] kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild

2021-05-26 Thread Masahiro Yamada
On Wed, May 12, 2021 at 5:00 PM Masahiro Yamada  wrote:
>
> arch/$(SRCARCH)/Kbuild is useful for Makefile cleanups because you can
> use the obj-y syntax.
>
> Add an empty file if it is missing in arch/$(SRCARCH)/.
>
> Signed-off-by: Masahiro Yamada 
> ---


Applied to linux-kbuild.

>
>  Makefile   | 2 +-
>  arch/alpha/Kbuild  | 1 +
>  arch/arc/Makefile  | 3 ---
>  arch/arm/Makefile  | 1 -
>  arch/arm64/Makefile| 1 -
>  arch/csky/Kbuild   | 1 +
>  arch/h8300/Kbuild  | 1 +
>  arch/hexagon/Kbuild| 1 +
>  arch/ia64/Kbuild   | 1 +
>  arch/microblaze/Kbuild | 1 +
>  arch/mips/Makefile | 3 ---
>  arch/nds32/Kbuild  | 1 +
>  arch/nios2/Kbuild  | 1 +
>  arch/openrisc/Makefile | 1 -
>  arch/parisc/Kbuild | 1 +
>  arch/powerpc/Makefile  | 3 ---
>  arch/riscv/Makefile| 1 -
>  arch/s390/Makefile | 3 ---
>  arch/sh/Kbuild | 1 +
>  arch/sparc/Makefile| 3 ---
>  arch/um/Kbuild | 1 +
>  arch/x86/Makefile  | 3 ---
>  arch/xtensa/Kbuild | 1 +
>  23 files changed, 13 insertions(+), 23 deletions(-)
>  create mode 100644 arch/alpha/Kbuild
>  create mode 100644 arch/csky/Kbuild
>  create mode 100644 arch/h8300/Kbuild
>  create mode 100644 arch/hexagon/Kbuild
>  create mode 100644 arch/ia64/Kbuild
>  create mode 100644 arch/microblaze/Kbuild
>  create mode 100644 arch/nds32/Kbuild
>  create mode 100644 arch/nios2/Kbuild
>  create mode 100644 arch/parisc/Kbuild
>  create mode 100644 arch/sh/Kbuild
>  create mode 100644 arch/um/Kbuild
>  create mode 100644 arch/xtensa/Kbuild
>
> diff --git a/Makefile b/Makefile
> index 15b6476d0f89..7df040b1b023 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -658,7 +658,7 @@ endif
>
>  ifeq ($(KBUILD_EXTMOD),)
>  # Objects we will link into vmlinux / subdirs we need to visit
> -core-y := init/ usr/
> +core-y := init/ usr/ arch/$(SRCARCH)/
>  drivers-y  := drivers/ sound/
>  drivers-$(CONFIG_SAMPLES) += samples/
>  drivers-$(CONFIG_NET) += net/
> diff --git a/arch/alpha/Kbuild b/arch/alpha/Kbuild
> new file mode 100644
> index ..a4e40e534e6a
> --- /dev/null
> +++ b/arch/alpha/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/arch/arc/Makefile b/arch/arc/Makefile
> index 4392c9c189c4..3e6d4b84797f 100644
> --- a/arch/arc/Makefile
> +++ b/arch/arc/Makefile
> @@ -85,9 +85,6 @@ KBUILD_LDFLAGS+= $(ldflags-y)
>
>  head-y := arch/arc/kernel/head.o
>
> -# See arch/arc/Kbuild for content of core part of the kernel
> -core-y += arch/arc/
> -
>  # w/o this dtb won't embed into kernel binary
>  core-y += arch/arc/boot/dts/
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 415c3514573a..173da685a52e 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -252,7 +252,6 @@ endif
>
>  export TEXT_OFFSET GZFLAGS MMUEXT
>
> -core-y += arch/arm/
>  # If we have a machine-specific directory, then include it in the build.
>  core-y += $(machdirs) $(platdirs)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 7ef44478560d..b73c151f3a53 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -149,7 +149,6 @@ KBUILD_CFLAGS += 
> -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
>  KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
>  KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
>
> -core-y += arch/arm64/
>  libs-y := arch/arm64/lib/ $(libs-y)
>  libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> diff --git a/arch/csky/Kbuild b/arch/csky/Kbuild
> new file mode 100644
> index ..a4e40e534e6a
> --- /dev/null
> +++ b/arch/csky/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/arch/h8300/Kbuild b/arch/h8300/Kbuild
> new file mode 100644
> index ..a4e40e534e6a
> --- /dev/null
> +++ b/arch/h8300/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/arch/hexagon/Kbuild b/arch/hexagon/Kbuild
> new file mode 100644
> index ..a4e40e534e6a
> --- /dev/null
> +++ b/arch/hexagon/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/arch/ia64/Kbuild b/arch/ia64/Kbuild
> new file mode 100644
> index ..a4e40e534e6a
> --- /dev/null
> +++ b/arch/ia64/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/arch/microblaze/Kbuild b/arch/microblaze/Kbuild
> new file mode 100644
> index ..a4e40e534e6a
> --- /dev/null
> +++ b/arch/microblaze/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 258234c35a09..4e942b7ef022 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -332,9 +332,6 @@ head-y := arch/mips/kernel/head.o
>  libs-y += arch/mips/lib/
>  libs-$(CONFIG_MIPS_FP_SUPPORT) += 

Re: [PATCH v7 14/15] dt-bindings: of: Add restricted DMA pool

2021-05-26 Thread Will Deacon
On Wed, May 26, 2021 at 01:13:22PM +0100, Will Deacon wrote:
> On Tue, May 18, 2021 at 02:42:14PM +0800, Claire Chang wrote:
> > @@ -138,4 +160,9 @@ one for multimedia processing (named 
> > multimedia-memory@7700, 64MiB).
> > memory-region = <_reserved>;
> > /* ... */
> > };
> > +
> > +   pcie_device: pcie_device@0,0 {
> > +   memory-region = <_dma_mem_reserved>;
> > +   /* ... */
> > +   };
> 
> I still don't understand how this works for individual PCIe devices -- how
> is dev->of_node set to point at the node you have above?
> 
> I tried adding the memory-region to the host controller instead, and then
> I see it crop up in dmesg:
> 
>   | pci-host-generic 4000.pci: assigned reserved memory node 
> restricted_dma_mem_reserved
> 
> but none of the actual PCI devices end up with 'dma_io_tlb_mem' set, and
> so the restricted DMA area is not used. In fact, swiotlb isn't used at all.
> 
> What am I missing to make this work with PCIe devices?

Aha, looks like we're just missing the logic to inherit the DMA
configuration. The diff below gets things working for me.

Will

--->8

diff --git a/drivers/of/address.c b/drivers/of/address.c
index c562a9ff5f0b..bf499fdd6e93 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -1113,25 +1113,25 @@ bool of_dma_is_coherent(struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
 
-int of_dma_set_restricted_buffer(struct device *dev)
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
 {
-   struct device_node *node;
int count, i;
 
-   if (!dev->of_node)
+   if (!np)
return 0;
 
-   count = of_property_count_elems_of_size(dev->of_node, "memory-region",
+   count = of_property_count_elems_of_size(np, "memory-region",
sizeof(phandle));
for (i = 0; i < count; i++) {
-   node = of_parse_phandle(dev->of_node, "memory-region", i);
+   struct device_node *node;
+
+   node = of_parse_phandle(np, "memory-region", i);
/* There might be multiple memory regions, but only one
-* restriced-dma-pool region is allowed.
+* restricted-dma-pool region is allowed.
 */
if (of_device_is_compatible(node, "restricted-dma-pool") &&
of_device_is_available(node))
-   return of_reserved_mem_device_init_by_idx(
-   dev, dev->of_node, i);
+   return of_reserved_mem_device_init_by_idx(dev, np, i);
}
 
return 0;
diff --git a/drivers/of/device.c b/drivers/of/device.c
index d8d865223e51..2defdca418ec 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -166,7 +166,7 @@ int of_dma_configure_id(struct device *dev, struct 
device_node *np,
arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
 
if (!iommu)
-   return of_dma_set_restricted_buffer(dev);
+   return of_dma_set_restricted_buffer(dev, np);
 
return 0;
 }
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 9fc874548528..8fde97565d11 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -163,14 +163,15 @@ struct bus_dma_region;
 #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
 int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map);
-int of_dma_set_restricted_buffer(struct device *dev);
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np);
 #else
 static inline int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map)
 {
return -ENODEV;
 }
-static inline int of_dma_set_restricted_buffer(struct device *dev)
+static inline int of_dma_set_restricted_buffer(struct device *dev,
+  struct device_node *np)
 {
return -ENODEV;
 }


[PATCH] Revert "powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs"

2021-05-26 Thread Frederic Barrat
This reverts commit 3c0468d4451eb6b4f6604370639f163f9637a479.

That commit was breaking alignment guarantees for the DMA address when
allocating coherent mappings, as described in
Documentation/core-api/dma-api-howto.rst

It was also noticed by Mellanox' driver:
[ 1515.763621] mlx5_core c002:01:00.0: mlx5_frag_buf_alloc_node:146:(pid 
13402): unexpected map alignment: 0x08c61000, page_shift=16
[ 1515.763635] mlx5_core c002:01:00.0: mlx5_cqwq_create:181:(pid
13402): mlx5_frag_buf_alloc_node() failed, -12

Signed-off-by: Frederic Barrat 
---
 arch/powerpc/kernel/iommu.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 57d6b85e9b96..2af89a5e379f 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -898,7 +898,6 @@ void *iommu_alloc_coherent(struct device *dev, struct 
iommu_table *tbl,
unsigned int order;
unsigned int nio_pages, io_order;
struct page *page;
-   size_t size_io = size;
 
size = PAGE_ALIGN(size);
order = get_order(size);
@@ -925,9 +924,8 @@ void *iommu_alloc_coherent(struct device *dev, struct 
iommu_table *tbl,
memset(ret, 0, size);
 
/* Set up tces to cover the allocated range */
-   size_io = IOMMU_PAGE_ALIGN(size_io, tbl);
-   nio_pages = size_io >> tbl->it_page_shift;
-   io_order = get_iommu_order(size_io, tbl);
+   nio_pages = size >> tbl->it_page_shift;
+   io_order = get_iommu_order(size, tbl);
mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL,
  mask >> tbl->it_page_shift, io_order, 0);
if (mapping == DMA_MAPPING_ERROR) {
@@ -942,9 +940,10 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t 
size,
 void *vaddr, dma_addr_t dma_handle)
 {
if (tbl) {
-   size_t size_io = IOMMU_PAGE_ALIGN(size, tbl);
-   unsigned int nio_pages = size_io >> tbl->it_page_shift;
+   unsigned int nio_pages;
 
+   size = PAGE_ALIGN(size);
+   nio_pages = size >> tbl->it_page_shift;
iommu_free(tbl, dma_handle, nio_pages);
size = PAGE_ALIGN(size);
free_pages((unsigned long)vaddr, get_order(size));
-- 
2.31.1



Re: [PATCH v2] KVM: PPC: Book3S HV: Save host FSCR in the P7/8 path

2021-05-26 Thread Fabiano Rosas
Nicholas Piggin  writes:

> Similar to commit 25edcc50d76c ("KVM: PPC: Book3S HV: Save and restore
> FSCR in the P9 path"), ensure the P7/8 path saves and restores the host
> FSCR. The logic explained in that patch actually applies there to the
> old path well: a context switch can be made before kvmppc_vcpu_run_hv
> restores the host FSCR and returns.
>
> Now both the p9 and the p7/8 paths now save and restore their FSCR, it
> no longer needs to be restored at the end of kvmppc_vcpu_run_hv
>
> Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs")
> Signed-off-by: Nicholas Piggin 

Reviewed-by: Fabiano Rosas 

> ---
> Since v1:
> - Remove the now unnecessary FSCR restore at vcpu_run exit [Fabiano]
>  arch/powerpc/kvm/book3s_hv.c| 1 -
>  arch/powerpc/kvm/book3s_hv_rmhandlers.S | 7 +++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 28a80d240b76..13728495ac66 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -4455,7 +4455,6 @@ static int kvmppc_vcpu_run_hv(struct kvm_vcpu *vcpu)
>   mtspr(SPRN_EBBRR, ebb_regs[1]);
>   mtspr(SPRN_BESCR, ebb_regs[2]);
>   mtspr(SPRN_TAR, user_tar);
> - mtspr(SPRN_FSCR, current->thread.fscr);
>   }
>   mtspr(SPRN_VRSAVE, user_vrsave);
>  
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index 5e634db4809b..004f0d4e665f 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -59,6 +59,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
>  #define STACK_SLOT_UAMOR (SFS-88)
>  #define STACK_SLOT_DAWR1 (SFS-96)
>  #define STACK_SLOT_DAWRX1(SFS-104)
> +#define STACK_SLOT_FSCR  (SFS-112)
>  /* the following is used by the P9 short path */
>  #define STACK_SLOT_NVGPRS(SFS-152)   /* 18 gprs */
>  
> @@ -686,6 +687,8 @@ BEGIN_FTR_SECTION
>   std r6, STACK_SLOT_DAWR0(r1)
>   std r7, STACK_SLOT_DAWRX0(r1)
>   std r8, STACK_SLOT_IAMR(r1)
> + mfspr   r5, SPRN_FSCR
> + std r5, STACK_SLOT_FSCR(r1)
>  END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
>  BEGIN_FTR_SECTION
>   mfspr   r6, SPRN_DAWR1
> @@ -1663,6 +1666,10 @@ FTR_SECTION_ELSE
>   ld  r7, STACK_SLOT_HFSCR(r1)
>   mtspr   SPRN_HFSCR, r7
>  ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_300)
> +BEGIN_FTR_SECTION
> + ld  r5, STACK_SLOT_FSCR(r1)
> + mtspr   SPRN_FSCR, r5
> +END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
>   /*
>* Restore various registers to 0, where non-zero values
>* set by the guest could disrupt the host.


[Bug 213221] New: Lockdep self tests failing on e6500 system

2021-05-26 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213221

Bug ID: 213221
   Summary: Lockdep self tests failing on e6500 system
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.12.6
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: m...@jakemoroni.com
Regression: No

Created attachment 296989
  --> https://bugzilla.kernel.org/attachment.cgi?id=296989=edit
lcokdep self test failures

Hello,

I noticed that some of the lockdep self tests are failing on my device. The
system is based on an NXP T2080 SoC, which has four 64-bit Power PC e6500 cores
(2 threads each). 

See attached log.

I'm running kernel 5.12.6 straight from kernel dot org. No modifications.

For what it's worth, I have been experiencing random instability issues, which
is what prompted me to enable lock debugging in the first place.

Thanks,
- Jake

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] KVM: PPC: Book3S HV: Save host FSCR in the P7/8 path

2021-05-26 Thread Nicholas Piggin
Similar to commit 25edcc50d76c ("KVM: PPC: Book3S HV: Save and restore
FSCR in the P9 path"), ensure the P7/8 path saves and restores the host
FSCR. The logic explained in that patch actually applies there to the
old path well: a context switch can be made before kvmppc_vcpu_run_hv
restores the host FSCR and returns.

Now both the p9 and the p7/8 paths now save and restore their FSCR, it
no longer needs to be restored at the end of kvmppc_vcpu_run_hv

Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs")
Signed-off-by: Nicholas Piggin 
---
Since v1:
- Remove the now unnecessary FSCR restore at vcpu_run exit [Fabiano]
 arch/powerpc/kvm/book3s_hv.c| 1 -
 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 7 +++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 28a80d240b76..13728495ac66 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4455,7 +4455,6 @@ static int kvmppc_vcpu_run_hv(struct kvm_vcpu *vcpu)
mtspr(SPRN_EBBRR, ebb_regs[1]);
mtspr(SPRN_BESCR, ebb_regs[2]);
mtspr(SPRN_TAR, user_tar);
-   mtspr(SPRN_FSCR, current->thread.fscr);
}
mtspr(SPRN_VRSAVE, user_vrsave);
 
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 5e634db4809b..004f0d4e665f 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -59,6 +59,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
 #define STACK_SLOT_UAMOR   (SFS-88)
 #define STACK_SLOT_DAWR1   (SFS-96)
 #define STACK_SLOT_DAWRX1  (SFS-104)
+#define STACK_SLOT_FSCR(SFS-112)
 /* the following is used by the P9 short path */
 #define STACK_SLOT_NVGPRS  (SFS-152)   /* 18 gprs */
 
@@ -686,6 +687,8 @@ BEGIN_FTR_SECTION
std r6, STACK_SLOT_DAWR0(r1)
std r7, STACK_SLOT_DAWRX0(r1)
std r8, STACK_SLOT_IAMR(r1)
+   mfspr   r5, SPRN_FSCR
+   std r5, STACK_SLOT_FSCR(r1)
 END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
 BEGIN_FTR_SECTION
mfspr   r6, SPRN_DAWR1
@@ -1663,6 +1666,10 @@ FTR_SECTION_ELSE
ld  r7, STACK_SLOT_HFSCR(r1)
mtspr   SPRN_HFSCR, r7
 ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_300)
+BEGIN_FTR_SECTION
+   ld  r5, STACK_SLOT_FSCR(r1)
+   mtspr   SPRN_FSCR, r5
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
/*
 * Restore various registers to 0, where non-zero values
 * set by the guest could disrupt the host.
-- 
2.23.0



Re: [PATCH v7 14/15] dt-bindings: of: Add restricted DMA pool

2021-05-26 Thread Will Deacon
Hi Claire,

On Tue, May 18, 2021 at 02:42:14PM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the reserved-memory node.
> 
> Signed-off-by: Claire Chang 
> ---
>  .../reserved-memory/reserved-memory.txt   | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index e8d3096d922c..284aea659015 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -51,6 +51,23 @@ compatible (optional) - standard definition
>used as a shared pool of DMA buffers for a set of devices. It can
>be used by an operating system to instantiate the necessary pool
>management subsystem if necessary.
> +- restricted-dma-pool: This indicates a region of memory meant to be
> +  used as a pool of restricted DMA buffers for a set of devices. The
> +  memory region would be the only region accessible to those devices.
> +  When using this, the no-map and reusable properties must not be 
> set,
> +  so the operating system can create a virtual mapping that will be 
> used
> +  for synchronization. The main purpose for restricted DMA is to
> +  mitigate the lack of DMA access control on systems without an 
> IOMMU,
> +  which could result in the DMA accessing the system memory at
> +  unexpected times and/or unexpected addresses, possibly leading to 
> data
> +  leakage or corruption. The feature on its own provides a basic 
> level
> +  of protection against the DMA overwriting buffer contents at
> +  unexpected times. However, to protect against general data leakage 
> and
> +  system memory corruption, the system needs to provide way to lock 
> down
> +  the memory access, e.g., MPU. Note that since coherent allocation
> +  needs remapping, one must set up another device coherent pool by
> +  shared-dma-pool and use dma_alloc_from_dev_coherent instead for 
> atomic
> +  coherent allocation.
>  - vendor specific string in the form ,[-]
>  no-map (optional) - empty property
>  - Indicates the operating system must not create a virtual mapping
> @@ -120,6 +137,11 @@ one for multimedia processing (named 
> multimedia-memory@7700, 64MiB).
>   compatible = "acme,multimedia-memory";
>   reg = <0x7700 0x400>;
>   };
> +
> + restricted_dma_mem_reserved: restricted_dma_mem_reserved {
> + compatible = "restricted-dma-pool";
> + reg = <0x5000 0x40>;
> + };

nit: You need to update the old text that states "This example defines 3
contiguous regions ...".

>   };
>  
>   /* ... */
> @@ -138,4 +160,9 @@ one for multimedia processing (named 
> multimedia-memory@7700, 64MiB).
>   memory-region = <_reserved>;
>   /* ... */
>   };
> +
> + pcie_device: pcie_device@0,0 {
> + memory-region = <_dma_mem_reserved>;
> + /* ... */
> + };

I still don't understand how this works for individual PCIe devices -- how
is dev->of_node set to point at the node you have above?

I tried adding the memory-region to the host controller instead, and then
I see it crop up in dmesg:

  | pci-host-generic 4000.pci: assigned reserved memory node 
restricted_dma_mem_reserved

but none of the actual PCI devices end up with 'dma_io_tlb_mem' set, and
so the restricted DMA area is not used. In fact, swiotlb isn't used at all.

What am I missing to make this work with PCIe devices?

Thanks,

Will


[PATCH v2] KVM: PPC: Book3S HV: Fix reverse map real-mode address lookup with huge vmalloc

2021-05-26 Thread Nicholas Piggin
real_vmalloc_addr() does not currently work for huge vmalloc, which is
what the reverse map can be allocated with for radix host, hash guest.

Extract the hugepage aware equivalent from eeh code into a helper, and
convert existing sites including this one to use it.

Fixes: 8abddd968a30 ("powerpc/64s/radix: Enable huge vmalloc mappings")
Signed-off-by: Nicholas Piggin 
---
Since v1:
- Factor out the same 3 patterns.
- Improve code and use PFN_PHYS [Christophe]

 arch/powerpc/include/asm/pte-walk.h  | 29 
 arch/powerpc/kernel/eeh.c| 23 +-
 arch/powerpc/kernel/io-workarounds.c | 15 +++---
 arch/powerpc/kvm/book3s_hv_rm_mmu.c  | 15 ++
 4 files changed, 35 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/include/asm/pte-walk.h 
b/arch/powerpc/include/asm/pte-walk.h
index 33fa5dd8ee6a..714a35f0d425 100644
--- a/arch/powerpc/include/asm/pte-walk.h
+++ b/arch/powerpc/include/asm/pte-walk.h
@@ -31,6 +31,35 @@ static inline pte_t *find_init_mm_pte(unsigned long ea, 
unsigned *hshift)
pgd_t *pgdir = init_mm.pgd;
return __find_linux_pte(pgdir, ea, NULL, hshift);
 }
+
+/*
+ * Convert a kernel vmap virtual address (vmalloc or ioremap space) to a
+ * physical address, without taking locks. This can be used in real-mode.
+ */
+static inline phys_addr_t ppc_find_vmap_phys(unsigned long addr)
+{
+   pte_t *ptep;
+   phys_addr_t pa;
+   int hugepage_shift;
+
+   /*
+* init_mm does not free page tables, and does not do THP. It may
+* have huge pages from huge vmalloc / ioremap etc.
+*/
+   ptep = find_init_mm_pte(addr, _shift);
+   if (WARN_ON(!ptep))
+   return 0;
+
+   pa = PFN_PHYS(pte_pfn(*ptep));
+
+   if (!hugepage_shift)
+   hugepage_shift = PAGE_SHIFT;
+
+   pa |= addr & ((1ul << hugepage_shift) - 1);
+
+   return pa;
+}
+
 /*
  * This is what we should always use. Any other lockless page table lookup 
needs
  * careful audit against THP split.
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index f24cd53ff26e..3bbdcc86d01b 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -346,28 +346,7 @@ void eeh_slot_error_detail(struct eeh_pe *pe, int severity)
  */
 static inline unsigned long eeh_token_to_phys(unsigned long token)
 {
-   pte_t *ptep;
-   unsigned long pa;
-   int hugepage_shift;
-
-   /*
-* We won't find hugepages here(this is iomem). Hence we are not
-* worried about _PAGE_SPLITTING/collapse. Also we will not hit
-* page table free, because of init_mm.
-*/
-   ptep = find_init_mm_pte(token, _shift);
-   if (!ptep)
-   return token;
-
-   pa = pte_pfn(*ptep);
-
-   /* On radix we can do hugepage mappings for io, so handle that */
-   if (!hugepage_shift)
-   hugepage_shift = PAGE_SHIFT;
-
-   pa <<= PAGE_SHIFT;
-   pa |= token & ((1ul << hugepage_shift) - 1);
-   return pa;
+   return ppc_find_vmap_phys(token);
 }
 
 /*
diff --git a/arch/powerpc/kernel/io-workarounds.c 
b/arch/powerpc/kernel/io-workarounds.c
index 51bbaae94ccc..ddba8761e58c 100644
--- a/arch/powerpc/kernel/io-workarounds.c
+++ b/arch/powerpc/kernel/io-workarounds.c
@@ -65,22 +65,13 @@ struct iowa_bus *iowa_mem_find_bus(const PCI_IO_ADDR addr)
bus = _busses[token - 1];
else {
unsigned long vaddr, paddr;
-   pte_t *ptep;
 
vaddr = (unsigned long)PCI_FIX_ADDR(addr);
if (vaddr < PHB_IO_BASE || vaddr >= PHB_IO_END)
return NULL;
-   /*
-* We won't find huge pages here (iomem). Also can't hit
-* a page table free due to init_mm
-*/
-   ptep = find_init_mm_pte(vaddr, _shift);
-   if (ptep == NULL)
-   paddr = 0;
-   else {
-   WARN_ON(hugepage_shift);
-   paddr = pte_pfn(*ptep) << PAGE_SHIFT;
-   }
+
+   paddr = ppc_find_vmap_phys(vaddr);
+
bus = iowa_pci_find(vaddr, paddr);
 
if (bus == NULL)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c 
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index 7af7c70f1468..7a0f12404e0e 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -23,20 +23,9 @@
 #include 
 
 /* Translate address of a vmalloc'd thing to a linear map address */
-static void *real_vmalloc_addr(void *x)
+static void *real_vmalloc_addr(void *addr)
 {
-   unsigned long addr = (unsigned long) x;
-   pte_t *p;
-   /*
-* assume we don't have huge pages in vmalloc space...
-* So don't worry about THP collapse/split. Called
-* Only in realmode with MSR_EE = 0, hence won't need irq_save/restore.
-*/
-   p = 

Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks

2021-05-26 Thread Ondrej Mosnacek
On Mon, May 17, 2021 at 1:00 PM Michael Ellerman  wrote:
> Ondrej Mosnacek  writes:
> > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > lockdown") added an implementation of the locked_down LSM hook to
> > SELinux, with the aim to restrict which domains are allowed to perform
> > operations that would breach lockdown.
> >
> > However, in several places the security_locked_down() hook is called in
> > situations where the current task isn't doing any action that would
> > directly breach lockdown, leading to SELinux checks that are basically
> > bogus.
> >
> > Since in most of these situations converting the callers such that
> > security_locked_down() is called in a context where the current task
> > would be meaningful for SELinux is impossible or very non-trivial (and
> > could lead to TOCTOU issues for the classic Lockdown LSM
> > implementation), fix this by modifying the hook to accept a struct cred
> > pointer as argument, where NULL will be interpreted as a request for a
> > "global", task-independent lockdown decision only. Then modify SELinux
> > to ignore calls with cred == NULL.
> >
> > Since most callers will just want to pass current_cred() as the cred
> > parameter, rename the hook to security_cred_locked_down() and provide
> > the original security_locked_down() function as a simple wrapper around
> > the new hook.
> >
> > The callers migrated to the new hook, passing NULL as cred:
> > 1. arch/powerpc/xmon/xmon.c
> >  Here the hook seems to be called from non-task context and is only
> >  used for redacting some sensitive values from output sent to
> >  userspace.
>
> It's hard to follow but it actually disables interactive use of xmon
> entirely if lockdown is in confidentiality mode, and disables
> modifications of the kernel in integrity mode.
>
> But that's not really that important, the patch looks fine.
>
> Acked-by: Michael Ellerman  (powerpc)

Thanks, Michael!

James/Paul, is there anything blocking this patch from being merged?
Especially the BPF case is causing real trouble for people and the
only workaround is to broadly allow lockdown::confidentiality in the
policy.

--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.



[PATCH -next 3/3] ocfs2: Replaced simple_strtoull() with kstrtoull()

2021-05-26 Thread Chen Huang
The simple_strtoull() function is deprecated in some situation since
it does not check for the range overflow, use kstrtoull() instead.

Signed-off-by: Chen Huang 
---
 fs/ocfs2/cluster/heartbeat.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index 1169c8dc9106..f89ffcbd585f 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -1596,12 +1596,13 @@ static ssize_t o2hb_region_start_block_store(struct 
config_item *item,
struct o2hb_region *reg = to_o2hb_region(item);
unsigned long long tmp;
char *p = (char *)page;
+   ssize_t ret;
 
if (reg->hr_bdev)
return -EINVAL;
 
-   tmp = simple_strtoull(p, , 0);
-   if (!p || (*p && (*p != '\n')))
+   ret = kstrtoull(p, 0, );
+   if (ret)
return -EINVAL;
 
reg->hr_start_block = tmp;
-- 
2.25.1



[PATCH -next 2/3] xen: balloon: Replaced simple_strtoull() with kstrtoull()

2021-05-26 Thread Chen Huang
The simple_strtoull() function is deprecated in some situation, since
it does not check for the range overflow, use kstrtoull() instead.

Signed-off-by: Chen Huang 
---
 drivers/xen/xen-balloon.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index a8d24433c8e9..1fba838963d2 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -163,13 +163,16 @@ static ssize_t store_target_kb(struct device *dev,
   const char *buf,
   size_t count)
 {
-   char *endchar;
+   ssize_t ret;
unsigned long long target_bytes;
 
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
 
-   target_bytes = simple_strtoull(buf, , 0) * 1024;
+   ret = kstrtoull(buf, 0, _bytes);
+   if (ret)
+   return ret;
+   target_bytes *= 1024;
 
balloon_set_new_target(target_bytes >> PAGE_SHIFT);
 
-- 
2.25.1



[PATCH -next 1/3] powerpc/rtas: Replaced simple_strtoull() with kstrtoull()

2021-05-26 Thread Chen Huang
The simple_strtoull() function is deprecated in some situation, since
it does not check for the range overflow, use kstrtoull() instead.

Signed-off-by: Chen Huang 
---
 arch/powerpc/kernel/rtas-proc.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
index 6857a5b0a1c3..117886782ebd 100644
--- a/arch/powerpc/kernel/rtas-proc.c
+++ b/arch/powerpc/kernel/rtas-proc.c
@@ -259,7 +259,6 @@ __initcall(proc_rtas_init);
 static int parse_number(const char __user *p, size_t count, u64 *val)
 {
char buf[40];
-   char *end;
 
if (count > 39)
return -EINVAL;
@@ -269,11 +268,7 @@ static int parse_number(const char __user *p, size_t 
count, u64 *val)
 
buf[count] = 0;
 
-   *val = simple_strtoull(buf, , 10);
-   if (*end && *end != '\n')
-   return -EINVAL;
-
-   return 0;
+   return kstrtoull(buf, 10, val);
 }
 
 /* ** */
-- 
2.25.1



Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device

2021-05-26 Thread kajoljain



On 5/26/21 2:15 PM, Aneesh Kumar K.V wrote:
> On 5/26/21 12:56 PM, kajoljain wrote:
>>
>>
>> On 5/25/21 7:46 PM, Peter Zijlstra wrote:
>>> On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote:
 Patch here adds cpu hotplug functions to nvdimm pmu.
>>>
>>> I'm thinking "Patch here" qualifies for "This patch", see
>>> Documentation/process/submitting-patches.rst .
>>>
>> Hi Peter,
>>     I will reword this commit message.
>>
 It adds cpumask to designate a cpu to make HCALL to
 collect the counter data for the nvdimm device and
 update ABI documentation accordingly.

 Result in power9 lpar system:
 command:# cat /sys/devices/nmem0/cpumask
 0
>>>
>>> Is this specific to the papr thing, or should this be in generic nvdimm
>>> code?
>>
>> This code is not specific to papr device and we can move it to
>> generic nvdimm interface. But do we need to add some checks on whether
>> any arch/platform specific driver want that support or we can assume
>> that this will be something needed by all platforms?
>>
> 
> It says the cpu that should be used to make the hcall. That makes it PAPR 
> specific.

Hi Aneesh,
  The hcall in the commit message basically pointing to the method we used to 
get
counter data. But adding cpumask to a PMU is not specific to powerpc.
So, Incase other platform/arch want to enable hotplug feature, they can use 
same code for
that and hence we can move it to generic nvdimm interface.

Our concerned it mainly about is it right to assume from the common code point 
of view, if
the cpumask attr is null, common code can add the cpumask support to it, or 
do we need to have explicit flag for the device to request for it.

Thanks,
Kajol Jain
> 
> -aneesh
> 


Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device

2021-05-26 Thread Aneesh Kumar K.V

On 5/26/21 12:56 PM, kajoljain wrote:



On 5/25/21 7:46 PM, Peter Zijlstra wrote:

On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote:

Patch here adds cpu hotplug functions to nvdimm pmu.


I'm thinking "Patch here" qualifies for "This patch", see
Documentation/process/submitting-patches.rst .


Hi Peter,
I will reword this commit message.


It adds cpumask to designate a cpu to make HCALL to
collect the counter data for the nvdimm device and
update ABI documentation accordingly.

Result in power9 lpar system:
command:# cat /sys/devices/nmem0/cpumask
0


Is this specific to the papr thing, or should this be in generic nvdimm
code?


This code is not specific to papr device and we can move it to
generic nvdimm interface. But do we need to add some checks on whether
any arch/platform specific driver want that support or we can assume
that this will be something needed by all platforms?



It says the cpu that should be used to make the hcall. That makes it 
PAPR specific.


-aneesh



Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device

2021-05-26 Thread Peter Zijlstra
On Wed, May 26, 2021 at 12:56:58PM +0530, kajoljain wrote:
> On 5/25/21 7:46 PM, Peter Zijlstra wrote:
> > On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote:

> >> It adds cpumask to designate a cpu to make HCALL to
> >> collect the counter data for the nvdimm device and
> >> update ABI documentation accordingly.
> >>
> >> Result in power9 lpar system:
> >> command:# cat /sys/devices/nmem0/cpumask
> >> 0
> > 
> > Is this specific to the papr thing, or should this be in generic nvdimm
> > code?
> 
> This code is not specific to papr device and we can move it to
> generic nvdimm interface. But do we need to add some checks on whether
> any arch/platform specific driver want that support or we can assume 
> that this will be something needed by all platforms?

I'm a complete NVDIMM n00b, but to me it would appear they would have to
conform to the normal memory hierarchy and would thus always be
per-node.

Also, if/when deviation from this rule is observed, we can always
rework/extend this. For now I think it would make sense to have the
per-node ness of the thing expressed in the generic layer.


Re: simplify gendisk and request_queue allocation for bio based drivers

2021-05-26 Thread Ulf Hansson
On Wed, 26 May 2021 at 06:49, Christoph Hellwig  wrote:
>
> On Wed, May 26, 2021 at 12:41:37AM +0200, Ulf Hansson wrote:
> > On Fri, 21 May 2021 at 07:51, Christoph Hellwig  wrote:
> > >
> > > Hi all,
> > >
> > > this series is the first part of cleaning up lifetimes and allocation of
> > > the gendisk and request_queue structure.  It adds a new interface to
> > > allocate the disk and queue together for bio based drivers, and a helper
> > > for cleanup/free them when a driver is unloaded or a device is removed.
> >
> > May I ask what else you have in the pipe for the next steps?
> >
> > The reason why I ask is that I am looking into some issues related to
> > lifecycle problems of gendisk/mmc, typically triggered at SD/MMC card
> > removal.
>
> In the short run not much more than superficial cleanups.  Eventually
> I want bio based drivers to not require a separate request_queue, leaving
> that purely as a data structure for blk-mq based drivers.  But it will
> take a while until we get there, so it should not block any fixes.

Alright, thanks for clarifying.

>
> For hot unplug handling it might be worth to take a look at nvme, as it
> is tested a lot for that case.

Okay, thanks for the hint.

Kind regards
Uffe


Re: [PATCH V3 0/2] selftests/powerpc: Updates to EBB selftest for ISA v3.1

2021-05-26 Thread Nageswara Sastry


> On 25-May-2021, at 7:21 PM, Athira Rajeev  wrote:
> 
> The "no_handler_test" in ebb selftests attempts to read the PMU
> registers after closing of the event via helper function
> "dump_ebb_state". With the MMCR0 control bit (PMCCEXT) in ISA v3.1,
> read access to group B registers is restricted when MMCR0 PMCC=0b00.
> Hence the call to dump_ebb_state after closing of event will generate
> a SIGILL, which is expected.
> 
> Test has below in logs:
> <<>>
> !! child died by signal 4
> failure: no_handler_test
> <<>>
> 
Tested patches on Power9 and Power10 - PowerVM environment.

Power9 - no_handler_test - with and without patch - success
Power10 - no_handler_test - without patch - failure
Power10 - no_handler_test - with patch - success

Power9 - regs_access_pmccext_test - with patch - success
Power10 - regs_access_pmccext_test - with patch - success

Tested-by: Nageswara R Sastry mailto:rnsas...@linux.ibm.com>>

Thank you.

Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device

2021-05-26 Thread kajoljain



On 5/25/21 7:46 PM, Peter Zijlstra wrote:
> On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote:
>> Patch here adds cpu hotplug functions to nvdimm pmu.
> 
> I'm thinking "Patch here" qualifies for "This patch", see
> Documentation/process/submitting-patches.rst .
> 
Hi Peter,
   I will reword this commit message.

>> It adds cpumask to designate a cpu to make HCALL to
>> collect the counter data for the nvdimm device and
>> update ABI documentation accordingly.
>>
>> Result in power9 lpar system:
>> command:# cat /sys/devices/nmem0/cpumask
>> 0
> 
> Is this specific to the papr thing, or should this be in generic nvdimm
> code?

This code is not specific to papr device and we can move it to
generic nvdimm interface. But do we need to add some checks on whether
any arch/platform specific driver want that support or we can assume 
that this will be something needed by all platforms?

Thanks,
Kajol Jain


Re: [PATCH] perf vendor events: Fix eventcode of power10 json events

2021-05-26 Thread Nageswara Sastry



> On 25-May-2021, at 8:57 PM, Paul A. Clarke  wrote:
>> 
> I lost the original message, but Nageswara Sastry said:
>> 1. Extracted all the 244 events from the patch.
>> 2. Check them in 'perf list' - all 244 events found
>> 3. Ran all the events with 'perf stat -e "event name" sleep 1', all ran fine.
>>No errors were seen in 'dmesg'
> 
> I count 255 events.
> 
> PC

Seems while extracting I filtered out newly added ones, so I got 244(255-11). 
Now checked with all 255 events. Thanks for pointing out.

Thanks!!
R.Nageswara Sastry