RE: [PATCH v5 03/23] PCI: hotplug: Add a flag for the movable BARs feature

From: Bjorn Helgaas > Sent: 27 September 2019 23:02 > On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote: > > When hot-adding a device, the bridge may have windows not big enough (or > > fragmented too much) for newly requested BARs to fit in. And expanding > > these bridge windo

Re: [PATCH v5 01/23] PCI: Fix race condition in pci_enable/disable_device()

Hello Bjorn, On 9/28/19 12:59 AM, Bjorn Helgaas wrote: On Fri, Aug 16, 2019 at 07:50:39PM +0300, Sergey Miroshnichenko wrote: This is a yet another approach to fix an old [1-2] concurrency issue, when: - two or more devices are being hot-added into a bridge which was initially empty; -

[Bug 195755] rcu_sched detected stalls on CPUs/tasks: (detected by 0, t=6302 jiffies, g=11405, c=11404, q=1880), ppc64, G5

https://bugzilla.kernel.org/show_bug.cgi?id=195755 Martin Zaharinov (micro...@gmail.com) changed: What|Removed |Added CC||micro...@gmail.com

Re: [PATCH 1/2] powerpc: Fix definition of PCR bits to work with old binutils

On 25/09/2019 21:05, Michael Ellerman wrote: > On Tue, 2019-09-17 at 00:46:04 UTC, Alistair Popple wrote: >> Commit 388cc6e133132 ("KVM: PPC: Book3S HV: Support POWER6 >> compatibility mode on POWER7") introduced new macros defining the PCR >> bits. When used from assembly files these definition

Re: [PATCH v2 3/6] KVM: PPC: Book3S HV: XIVE: Show VP id in debugfs

On 27/09/2019 13:53, Greg Kurz wrote: > Print out the VP id of each connected vCPU, this allow to see: > - the VP block base in which OPAL encodes information that may be > useful when debugging > - the packed vCPU id which may differ from the raw vCPU id if the > latter is >= KVM_MAX_VCPUS (20

[Bug 195755] rcu_sched detected stalls on CPUs/tasks: (detected by 0, t=6302 jiffies, g=11405, c=11404, q=1880), ppc64, G5

https://bugzilla.kernel.org/show_bug.cgi?id=195755 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|CLOSED |REOPENED Resol

Re: [PATCH v4 03/11] mm/gup: Applies counting method to monitor gup_pgd_range

On Fri, Sep 27, 2019 at 08:40:00PM -0300, Leonardo Bras wrote: > As decribed, gup_pgd_range is a lockless pagetable walk. So, in order to ^ typo -- Kirill A. Shutemov

Re: [PATCH v1 1/2] PCI/AER: Use for_each_set_bit()

On Fri, Sep 27, 2019 at 07:39:13AM -0500, Bjorn Helgaas wrote: > On Tue, Aug 27, 2019 at 06:18:22PM +0300, Andy Shevchenko wrote: > > This simplifies and standardizes slot manipulation code > > by using for_each_set_bit() library function. > > + unsigned long status = info->status & ~info->mask;

Re: [PATCH v2 5/6] KVM: PPC: Book3S HV: XIVE: Make VP block size configurable

On 27/09/2019 13:54, Greg Kurz wrote: > The XIVE VP is an internal structure which allow the XIVE interrupt > controller to maintain the interrupt context state of vCPUs non > dispatched on HW threads. > > When a guest is started, the XIVE KVM device allocates a block of > XIVE VPs in OPAL, enough

Re: [PATCH v5 03/23] PCI: hotplug: Add a flag for the movable BARs feature

Hello Bjorn, On 9/28/19 1:02 AM, Bjorn Helgaas wrote: On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote: When hot-adding a device, the bridge may have windows not big enough (or fragmented too much) for newly requested BARs to fit in. And expanding these bridge windows may b

Re: [PATCH v2 4/6] KVM: PPC: Book3S HV: XIVE: Compute the VP id in a common helper

On Mon, 30 Sep 2019 14:01:56 +0200 Cédric Le Goater wrote: > On 27/09/2019 13:53, Greg Kurz wrote: > > Reduce code duplication by consolidating the checking of vCPU ids and VP > > ids to a common helper used by both legacy and native XIVE KVM devices. > > And explain the magic with a comment. > >

Re: [PATCH v2 4/6] KVM: PPC: Book3S HV: XIVE: Compute the VP id in a common helper

On 27/09/2019 13:53, Greg Kurz wrote: > Reduce code duplication by consolidating the checking of vCPU ids and VP > ids to a common helper used by both legacy and native XIVE KVM devices. > And explain the magic with a comment. > > Signed-off-by: Greg Kurz Looks fine. One question below, > --- >

Re: [PATCH v4 03/11] mm/gup: Applies counting method to monitor gup_pgd_range

On Mon, 2019-09-30 at 14:09 +0300, Kirill A. Shutemov wrote: > On Fri, Sep 27, 2019 at 08:40:00PM -0300, Leonardo Bras wrote: > > As decribed, gup_pgd_range is a lockless pagetable walk. So, in order to > ^ typo > Fixed, thanks! signature.asc Description: This is a digitally signed message

Re: [PATCH v4 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a

On Tue, Sep 24, 2019 at 10:18:48AM +0800, Xiaowei Bao wrote: > Add PCIe EP node for ls1088a to support EP mode. > > Signed-off-by: Xiaowei Bao Reviewed-by: Andrew Murray > --- > v2: > - Remove the pf-offset proparty. > v3: > - No change. > v4: > - No change. > > arch/arm64/boot/dts/frees

Re: [PATCH v4 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table

On Tue, Sep 24, 2019 at 10:18:49AM +0800, Xiaowei Bao wrote: > Add LS1088a in pci_device_id table so that pci-epf-test can be used > for testing PCIe EP in LS1088a. > > Signed-off-by: Xiaowei Bao > --- > v2: > - No change. > v3: > - No change. > v4: > - Use a maco to define the LS1088a device

Re: [PATCH v4 01/11] powerpc/mm: Adds counting method to monitor lockless pgtable walks

On Sun, 2019-09-29 at 15:40 -0700, John Hubbard wrote: > Hi, Leonardo, Hello John, thanks for the feedback. > Can we please do it as shown below, instead (compile-tested only)? > > This addresses all of the comments that I was going to make about structure > of this patch, which are: > > * The

Re: [PATCH v5 03/23] PCI: hotplug: Add a flag for the movable BARs feature

Hello David, On 9/30/19 11:44 AM, David Laight wrote: From: Bjorn Helgaas Sent: 27 September 2019 23:02 On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote: When hot-adding a device, the bridge may have windows not big enough (or fragmented too much) for newly requested BARs

Re: [PATCH 1/3] powernv/iov: Ensure the pdn for VFs always contains a valid PE number

On Mon, Sep 30, 2019 at 12:08:46PM +1000, Oliver O'Halloran wrote: This is all powerpc, so I assume Michael will handle this. Just random things I noticed; ignore if they don't make sense: > On PowerNV we use the pcibios_sriov_enable() hook to do two things: > > 1. Create a pci_dn structure for

Re: [PATCH v4 01/11] powerpc/mm: Adds counting method to monitor lockless pgtable walks

On 9/30/19 8:14 AM, Leonardo Bras wrote: On Sun, 2019-09-29 at 15:40 -0700, John Hubbard wrote: Hi, Leonardo, Hello John, thanks for the feedback. Can we please do it as shown below, instead (compile-tested only)? This addresses all of the comments that I was going to make about structure o

[PATCH v13 0/9] namei: openat2(2) path resolution restrictions

This patchset is being developed here: It depends on the copy_struct_from_user() helpers being developed here: and posted here:

[PATCH v13 1/9] namei: obey trailing magic-link DAC permissions

The ability for userspace to "re-open" file descriptors through /proc/self/fd has been a very useful tool for all sorts of usecases (container runtimes are one common example). However, the current interface for doing this has resulted in some pretty subtle security holes. Userspace can re-open a f

[PATCH v13 2/9] procfs: switch magic-link modes to be more sane

Now that magic-link modes are obeyed for file re-opening purposes, some of the pre-existing magic-link modes need to be adjusted to be more semantically correct. The most blatant example of this is /proc/self/exe, which had a mode of a+rwx even though tautologically the file could never be opened

[PATCH v13 3/9] open: O_EMPTYPATH: procfs-less file descriptor re-opening

Userspace has made use of /proc/self/fd very liberally to allow for descriptors to be re-opened. There are a wide variety of uses for this feature, but it has always required constructing a pathname and could not be done without procfs mounted. The obvious solution for this is to extend openat(2) t

[PATCH v13 4/9] namei: O_BENEATH-style path resolution flags

Add the following flags to allow various restrictions on path resolution (these affect the *entire* resolution, rather than just the final path component -- as is the case with LOOKUP_FOLLOW). The primary justification for these flags is to allow for programs to be far more strict about how they w

[PATCH v13 5/9] namei: LOOKUP_IN_ROOT: chroot-like path resolution

The primary motivation for the need for this flag is container runtimes which have to interact with malicious root filesystems in the host namespaces. One of the first requirements for a container runtime to be secure against a malicious rootfs is that they correctly scope symlinks (that is, they s

[PATCH v13 6/9] namei: permit ".." resolution with LOOKUP_{IN_ROOT, BENEATH}

This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit ".." resolution (in the case of LOOKUP_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still disal

[PATCH v13 7/9] open: openat2(2) syscall

The most obvious syscall to add support for the new LOOKUP_* scoping flags would be openat(2). However, there are a few reasons why this is not the best course of action: * The new LOOKUP_* flags are intended to be security features, and openat(2) will silently ignore all unknown flags. This m

[PATCH v13 8/9] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags, as well as how file descriptor re-opening works. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. In addition, the memfd selftest is fixed to no longer depend on the now-disal

[PATCH v13 9/9] Documentation: update path-lookup to mention trailing magic-links

We've introduced new (somewhat subtle) behaviour regarding trailing magic-links, so it's best to make sure everyone can follow along with the reasoning behind trailing_magiclink(). Signed-off-by: Aleksa Sarai --- Documentation/filesystems/path-lookup.rst | 80 ++- 1 file chan

Re: [PATCH v4 01/11] powerpc/mm: Adds counting method to monitor lockless pgtable walks

On Mon, 2019-09-30 at 10:57 -0700, John Hubbard wrote: > > As I told before, there are cases where this function is called from > > 'real mode' in powerpc, which doesn't disable irqs and may have a > > tricky behavior if we do. So, encapsulate the irq disable in this > > function can be a bad choic

Re: [PATCH V2 1/2] ASoC: fsl_mqs: add DT binding documentation

On Fri, 13 Sep 2019 17:42:13 +0800, Shengjiu Wang wrote: > Add the DT binding documentation for NXP MQS driver > > Signed-off-by: Shengjiu Wang > --- > Changes in v2 > -refine the comments for properties > > .../devicetree/bindings/sound/fsl,mqs.txt | 36 +++ > 1 file change

Re: [PATCH v13 7/9] open: openat2(2) syscall

Hi Aleksa, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.4-rc1 next-20190930] [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

Re: [PATCH 2/6] powerpc/64s/radix: tidy up TLB flushing code

arch/powerpc/mm/book3s64/pgtable.c: In function ‘flush_partition’: arch/powerpc/mm/book3s64/pgtable.c:216:3: error: implicit declaration of function ‘radix__flush_all_lpid_guest’ [-Werror=implicit-function-declaration] radix__flush_all_lpid_guest(lpid); ^ cc1: all warnings being treated as e

Re: [PATCH v4 01/11] powerpc/mm: Adds counting method to monitor lockless pgtable walks

On 9/30/19 11:42 AM, Leonardo Bras wrote: > On Mon, 2019-09-30 at 10:57 -0700, John Hubbard wrote: >>> As I told before, there are cases where this function is called from >>> 'real mode' in powerpc, which doesn't disable irqs and may have a >>> tricky behavior if we do. So, encapsulate the irq dis

Re: [PATCH v4 03/11] mm/gup: Applies counting method to monitor gup_pgd_range

On 9/27/19 4:40 PM, Leonardo Bras wrote: > As decribed, gup_pgd_range is a lockless pagetable walk. So, in order to > monitor against THP split/collapse with the couting method, it's necessary s/couting/counting/ > to bound it with {start,end}_lockless_pgtbl_walk. > > There are dummy functions,

Re: [PATCH v13 7/9] open: openat2(2) syscall

On 2019-10-01, kbuild test robot wrote: > Hi Aleksa, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.4-rc1 next-20190930] > [if your patch is applied to the wrong git tree, please drop us a note

Re: [PATCH v13 3/9] open: O_EMPTYPATH: procfs-less file descriptor re-opening

Hi Aleksa, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.4-rc1 next-20190930] [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

Re: [PATCH v13 3/9] open: O_EMPTYPATH: procfs-less file descriptor re-opening

On 2019-10-01, kbuild test robot wrote: > Hi Aleksa, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.4-rc1 next-20190930] > [if your patch is applied to the wrong git tree, please drop us a note

Re: [PATCH v13 7/9] open: openat2(2) syscall

Hi Aleksa, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.4-rc1 next-20190930] [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

Re: [PATCH v6 3/9] powerpc: add support to initialize ima policy rules

Hello, Nayna Jain writes: > PowerNV systems uses kernel based bootloader, thus its secure boot > implementation uses kernel IMA security subsystem to verify the kernel > before kexec. Since the verification policy might differ based on the > secure boot mode of the system, the policies are def

Re: [PATCH 1/3] powernv/iov: Ensure the pdn for VFs always contains a valid PE number

On Tue, Oct 1, 2019 at 3:09 AM Bjorn Helgaas wrote: > > On Mon, Sep 30, 2019 at 12:08:46PM +1000, Oliver O'Halloran wrote: > > This is all powerpc, so I assume Michael will handle this. Just > random things I noticed; ignore if they don't make sense: > > > On PowerNV we use the pcibios_sriov_enab

Re: [PATCH v13 7/9] open: openat2(2) syscall

Hi Aleksa, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.4-rc1 next-20191001] [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 sp

Re: [PATCH 1/3] powernv/iov: Ensure the pdn for VFs always contains a valid PE number

On 30/09/2019 12:08, Oliver O'Halloran wrote: > On PowerNV we use the pcibios_sriov_enable() hook to do two things: > > 1. Create a pci_dn structure for each of the VFs, and > 2. Configure the PHB's internal BARs that map MMIO ranges to PEs >so that each VF has it's own PE. Note that the PE

Re: [PATCH 2/3] powerpc/pci: Fix pcibios_setup_device() ordering

On 30/09/2019 12:08, Oliver O'Halloran wrote: > From: Shawn Anastasio > > Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to > pcibios_bus_add_device(). This ensures that platform-specific DMA and IOMMU > setup occurs after the device has been registered in sysfs, which

Re: [PATCH 3/3] powerpc/pci: Remove pcibios_setup_bus_devices()

On 30/09/2019 12:08, Oliver O'Halloran wrote: > With the previous patch applied pcibios_setup_device() will always be run > when pcibios_bus_add_device() is called. There are several code paths where > pcibios_setup_bus_device() is still called (the PowerPC specific PCI > hotplug support is one)

[RFC PATCH 1/9] powerpc/pseries: add cpu DLPAR support for drc-info property

From: Tyrel Datwyler Older firmwares provided information about Dynamic Reconfig Connectors (DRC) through several device tree properties, namely ibm,drc-types, ibm,drc-indexes, ibm,drc-names, and ibm,drc-power-domains. New firmwares have the ability to present this same information in a much cond

[RFC PATCH 3/9] powerpc/pseries: fix drc-info mappings of logical cpus to drc-index

There are a couple subtle errors in the mapping between cpu-ids and a cpus associated drc-index when using the new ibm,drc-info property. The first is we while drc-info may have been a supported firmware feature at boot it is possible we have migrated to a CEC with older firmware that doesn't supp

[RFC PATCH 2/9] powerpc/pseries: fix bad drc_index_start value parsing of drc-info entry

The ibm,drc-info property is an array property that contains drc-info entries such that each entry is made up of 2 string encoded elements followed by 5 int encoded elements. The of_read_drc_info_cell() helper contains comments that correctly name the expected elements and their encoding. However,

[RFC PATCH 5/9] PCI: rpaphp: don't rely on firmware feature to imply drc-info support

In the event that the partition is migrated to a platform with older firmware that doesn't support the ibm,drc-info property the device tree is modified to remove the ibm,drc-info property and replace it with the older style ibm,drc-* properties for types, names, indexes, and power-domains. One of

[RFC PATCH 4/9] PCI: rpaphp: fix up pointer to first drc-info entry

The first entry of the ibm,drc-info property is an int encoded count of the number of drc-info entries that follow. The "value" pointer returned by of_prop_next_u32() is still pointing at the this value when we call of_read_drc_info_cell(). Fix up by incrementing the "value" pointer to point at th

[RFC PATCH 7/9] PCI: rpaphp: annotate and correctly byte swap DRC properties

The device tree is in bid endian format and any properties directly retrieved using OF helpers that don't explicitly byte swap should be annotated. In particular there are several places where we grab the opaque property value for the old ibm,drc-* properties and the ibm,my-drc-index property. Fix

[RFC PATCH 6/9] PCI: rpaphp: add drc-info support for hotplug slot registration

Split physical PCI slot registration scanning into seperate routines that support the old ibm,drc-* properties and one that supports the new compressed ibm,drc-info property. Signed-off-by: Tyrel Datwyler --- drivers/pci/hotplug/rpaphp_core.c | 89 ++- 1 file

[RFC PATCH 0/9] Fixes and Enablement of ibm,drc-info property

There was an initial previous effort yo add support for the PAPR architected ibm,drc-info property. This property provides a more memory compact representation of a paritions Dynamic Reconfig Connectors (DRC). These can otherwise be thought of the currently partitioned, or available, but yet to be

[RFC PATCH 9/9] powerpc: Enable support for ibm,drc-info property

Advertise client support for the PAPR architected ibm,drc-info device tree property during CAS handshake. Signed-off-by: Tyrel Datwyler --- arch/powerpc/kernel/prom_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/pr

[RFC PATCH 8/9] PCI: rpaphp: correctly match ibm, my-drc-index to drc-name when using drc-info

The newer ibm,drc-info property is a condensed description of the old ibm,drc-* properties (ie. names, types, indexes, and power-domains). When matching a drc-index to a drc-name we need to verify that the index is within the start and last drc-index range and map it to a drc-name using the drc-nam

[PATCH v8 0/5] kasan: support backing vmalloc space with real shadow memory

Currently, vmalloc space is backed by the early shadow page. This means that kasan is incompatible with VMAP_STACK. This series provides a mechanism to back vmalloc space with real, dynamically allocated memory. I have only wired up x86, because that's the only currently supported arch I can work