Re: [PATCH v2 1/2] kasan: support instrumented bitops combined with generic bitops

> But the docs do seem to indicate that it's atomic (for whatever that > means for a single read operation?), so you are right, it should live in > instrumented-atomic.h. Actually, on further inspection, test_bit has lived in bitops/non-atomic.h since it was added in 4117b02132d1 ("[PATCH] bitops:

Re: [PATCH v3 15/15] powerpc/32s: Activate CONFIG_VMAP_STACK

Michael Ellerman a écrit : Christophe Leroy writes: A few changes to retrieve DAR and DSISR from struct regs instead of retrieving them directly, as they may have changed due to a TLB miss. Also modifies hash_page() and friends to work with virtual data addresses instead of physical ones. S

Re: [PATCH v6 17/24] mm/gup: track FOLL_PIN pages

On 11/19/19 3:37 AM, Jan Kara wrote: > On Tue 19-11-19 00:16:36, John Hubbard wrote: >> @@ -2025,6 +2149,20 @@ static int __record_subpages(struct page *page, >> unsigned long addr, >> return nr; >> } >> >> +static bool __pin_compound_head(struct page *head, int refs, unsigned int >> flag

Re: [PATCH v6 15/24] fs/io_uring: set FOLL_PIN via pin_user_pages()

On 11/19/19 8:10 AM, Jens Axboe wrote: > On 11/19/19 1:16 AM, John Hubbard wrote: >> Convert fs/io_uring to use the new pin_user_pages() call, which sets >> FOLL_PIN. Setting FOLL_PIN is now required for code that requires >> tracking of pinned pages, and therefore for any code that calls >> put_us

Re: [PATCH 1/3] dma-direct: unify the dma_capable definitions

Hi On 19.11.2019 17:46, Christoph Hellwig wrote: > On Tue, Nov 19, 2019 at 11:26:39AM +0100, Marek Szyprowski wrote: >> Christoph: Let me know if this is a proper fix for you, then I will send >> it as a full patch. > Besides the point from Robin, which is really older than you patch > I'm not a f

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

This adds tests which will validate architecture page table helpers and other accessors in their compliance with expected generic MM semantics. This will help various architectures in validating changes to existing page table helpers or addition of new ones. This test covers basic page table entry

[PATCH] update to "kasan: support backing vmalloc space with real shadow memory"

Hi Andrew, This is a quick fixup to patch 1 of the "kasan: support backing vmalloc space with real shadow memory" series, v11, which you pulled in to your mmotm tree. There are 2 changes: - A fixup to the per-cpu allocator path to avoid allocating memory under a spinlock, thanks Qian Cai.

[PATCH RESEND v17 13/13] Documentation: path-lookup: include new LOOKUP flags

Now that we have new LOOKUP flags, we should document them in the relevant path-walking documentation. And now that we've settled on a common name for nd_jump_link() style symlinks ("magic links"), use that term where magic-link semantics are described. Signed-off-by: Aleksa Sarai --- Documentat

[PATCH RESEND v17 12/13] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. The main things these self-tests are enforcing are: * The struct+usize ABI for openat2(2) and copy_struct_from_user() to

[PATCH RESEND v17 11/13] open: introduce openat2(2) syscall

/* Background. */ For a very long time, extending openat(2) with new features has been incredibly frustrating. This stems from the fact that openat(2) is possibly the most famous counter-example to the mantra "don't silently accept garbage from userspace" -- it doesn't check whether unknown flags a

[PATCH RESEND v17 10/13] namei: LOOKUP_{IN_ROOT, BENEATH}: permit limited ".." resolution

Allow 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 disallowed entirely[*

[PATCH RESEND v17 09/13] namei: LOOKUP_IN_ROOT: chroot-like scoped resolution

/* Background. */ Container runtimes or other administrative management processes will often interact with root filesystems while in the host mount namespace, because the cost of doing a chroot(2) on every operation is too prohibitive (especially in Go, which cannot safely use vfork). However, a ma

[PATCH RESEND v17 08/13] namei: LOOKUP_BENEATH: O_BENEATH-like scoped resolution

/* Background. */ There are many circumstances when userspace wants to resolve a path and ensure that it doesn't go outside of a particular root directory during resolution. Obvious examples include archive extraction tools, as well as other security-conscious userspace programs. FreeBSD spun out O

[PATCH RESEND v17 07/13] namei: LOOKUP_NO_XDEV: block mountpoint crossing

/* Background. */ The need to contain path operations within a mountpoint has been a long-standing usecase that userspace has historically implemented manually with liberal usage of stat(). find, rsync, tar and many other programs implement these semantics -- but it'd be much simpler to have a fool

[PATCH RESEND v17 06/13] namei: LOOKUP_NO_MAGICLINKS: block magic-link resolution

/* Background. */ There has always been a special class of symlink-like objects in procfs (and a few other pseudo-filesystems) which allow for non-lexical resolution of paths using nd_jump_link(). These "magic-links" do not follow traditional mount namespace boundaries, and have been used consisten

[PATCH RESEND v17 05/13] namei: LOOKUP_NO_SYMLINKS: block symlink resolution

/* Background. */ Userspace cannot easily resolve a path without resolving symlinks, and would have to manually resolve each path component with O_PATH and O_NOFOLLOW. This is clearly inefficient, and can be fairly easy to screw up (resulting in possible security bugs). Linus has mentioned that Git

[PATCH RESEND v17 04/13] namei: allow set_root() to produce errors

For LOOKUP_BENEATH and LOOKUP_IN_ROOT it is necessary to ensure that set_root() is never called, and thus (for hardening purposes) it should return an error rather than permit a breakout from the root. In addition, move all of the repetitive set_root() calls to nd_jump_root(). Signed-off-by: Aleks

[PATCH RESEND v17 03/13] namei: allow nd_jump_link() to produce errors

In preparation for LOOKUP_NO_MAGICLINKS, it's necessary to add the ability for nd_jump_link() to return an error which the corresponding get_link() caller must propogate back up to the VFS. Suggested-by: Al Viro Signed-off-by: Aleksa Sarai --- fs/namei.c | 3 ++- fs/proc/ba

[PATCH RESEND v17 02/13] nsfs: clean-up ns_get_path() signature to return int

ns_get_path() and ns_get_path_cb() only ever return either NULL or an ERR_PTR. It is far more idiomatic to simply return an integer, and it makes all of the callers of ns_get_path() more straightforward to read. Fixes: e149ed2b805f ("take the targets of /proc/*/ns/* symlinks to separate fs") Signe

[PATCH RESEND v17 01/13] namei: only return -ECHILD from follow_dotdot_rcu()

It's over-zealous to return hard errors under RCU-walk here, given that a REF-walk will be triggered for all other cases handling ".." under RCU. The original purpose of this check was to ensure that if a rename occurs such that a directory is moved outside of the bind-mount which the resolution s

[PATCH RESEND v17 00/13] open: introduce openat2(2) syscall

This patchset is being developed here: This is a re-send of but rebased on top of 5.4-rc8 (also my mails got duplicated the first time I sent v17 -- hopefully that doe

Re: [PATCH v5 00/48] QUICC Engine support on ARM, ARM64, PPC64

On 11/18/19 5:22 AM, Rasmus Villemoes wrote: There have been several attempts in the past few years to allow building the QUICC engine drivers for platforms other than PPC32. This is yet another attempt. v4 can be found here: https://lore.kernel.org/lkml/20191108130123.6839-1-li...@rasmusvillem

Re: [RFC PATCH 1/4] libnvdimm/namespace: Make namespace size validation arch dependent

On Tue, Nov 19, 2019 at 7:19 PM Aneesh Kumar K.V wrote: > > On 11/19/19 11:28 PM, Dan Williams wrote: > > On Mon, Nov 18, 2019 at 1:52 AM Aneesh Kumar K.V > > wrote: > >> > >> Dan Williams writes: > >> > >>> On Sat, Nov 16, 2019 at 4:15 AM Aneesh Kumar K.V > >>> wrote: > > >> > >> > >

Re: [RFC PATCH 1/4] libnvdimm/namespace: Make namespace size validation arch dependent

On 11/19/19 11:28 PM, Dan Williams wrote: On Mon, Nov 18, 2019 at 1:52 AM Aneesh Kumar K.V wrote: Dan Williams writes: On Sat, Nov 16, 2019 at 4:15 AM Aneesh Kumar K.V wrote: Considering the direct-map map size is not going to be user selectable, do you agree that we can skip

[PATCH] selftests/powerpc: spectre_v2 test must be built 64-bit

The spectre_v2 test must be built 64-bit, it includes hand-written asm that is 64-bit only, and segfaults if built 32-bit. Fixes: c790c3d2b0ec ("selftests/powerpc: Add a test of spectre_v2 mitigations") Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/security/Makefile | 2 ++

Re: [PATCH v2] powerpc: Add const qual to local_read() parameter

Hi all, On Wed, 20 Nov 2019 12:14:51 +1100 Michael Ellerman wrote: > > From: Eric Dumazet > > A patch in net-next triggered a compile error on powerpc: > > include/linux/u64_stats_sync.h: In function 'u64_stats_read': > include/asm-generic/local64.h:30:37: warning: passing argument 1 of >

[Very RFC 46/46] HACK: prevent pdn's from being created

Not-Signed-off-by: Oliver O'Halloran --- arch/powerpc/kernel/pci_dn.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c index f790a8d06f50..0e05c1d7633a 100644 --- a/arch/powerpc/kernel/pci_dn.c +++ b/arch/powerpc/kernel/pci_dn.c @@

[Very RFC 45/46] powernv/pci: Remove requirement for a pdn in config accessors

:toot: Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c index 0eeea8652426..6383dcfec606 100644 --- a/arch/powerpc/platforms/powern

[Very RFC 44/46] powerpc/pci: Don't set pdn->pe_number when applying the weird P8 NVLink PE hack

P8 needs to shove four GPUs into three PEs for $reasons. Remove the pdn->pe_assignment done there since we just use the pe_rmap[] now. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/pow

[Very RFC 43/46] powernv/pci: Do not set pdn->pe_number for NPU/CAPI devices

The only thing we need the pdn for in this function is setting the pe_number field, which we don't use anymore. Fix the weird refcounting behaviour while we're here. Signed-off-by: Oliver O'Halloran --- Either Fred, or Reza also fixed this in some patch lately and that'll probably get merged bef

[Very RFC 42/46] powernv/pci: Don't clear pdn->pe_number in pnv_pci_release_device

Nothing looks at it anymore. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 12 1 file changed, 12 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index d3e375d71cdc..45d940730c30 100

[Very RFC 41/46] powernv/eeh: Remove pdn setup for SR-IOV VFs

We don't need a pci_dn for the VF any more, so we can skip adding them. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 16 1 file changed, 16 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/

[Very RFC 40/46] powernv/npu: Don't drop refcount when looking up GPU pci_devs

The comment here implies that we don't need to take a ref to the pci_dev because the ioda_pe will always have one. This implies that the current expection is that the pci_dev for an NPU device will *never* be torn down since the ioda_pe having a ref to the device will prevent the release function f

[Very RFC 39/46] powernv/npu: Avoid pci_dn when mapping device_node to a pci_dev

There's no need to use the pci_dn to find a device_node from a pci_dev. Just search for the node pointed to by the pci_dev's of_node pointer. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/npu-dma.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/

[Very RFC 38/46] powerpc/pci-hotplug: Scan the whole bus when using PCI_PROBE_NORMAL

Currently when using the normal (i.e not building pci_dev's from the DT node) probe method we only scan the devfn corresponding to the first child of the bridge's DT node. This doesn't make much sense to me, but it seems to have worked so far. At a guess it seems to work because in a PCIe environme

[Very RFC 37/46] powernv/pci: Use the PHB's rmap for pnv_ioda_to_pe()

Rather than using the pdn->pe_number for a device as an index into the IODA PE array we can use the reverse map. This maps the RID (i.e. bdfn) to the PE number associated with it. Firmware maintains a copy of the rmap which is used by the hardware for determining which PE to use when handling a DMA

[Very RFC 36/46] powernv/npu: Remove open-coded PE lookup for GPU device

Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/npu-dma.c | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c index b95b9e3c4c98..68bfaef44862 100644 --- a/arch/

[Very RFC 35/46] powernv/pci: Remove open-coded PE lookup in pnv_pci_release_device

Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 4f38652c7cd7..8525642b1256 100644 --- a/arch/powerpc

[Very RFC 34/46] powernv/pci: Remove open-coded PE lookup in pnv_pci_enable_device_hook()

Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 7e88de18ead6..4f38652c7cd7 100644 --- a/arch/powerp

[Very RFC 33/46] powernv/pci: Remove open-coded PE lookup in iommu notifier

Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c index 5b1f4677cdce..0eeea8652426 100644 --- a/arch/powerpc/platforms/

[Very RFC 32/46] powernv/pci: Remove open-coded PE lookup in iommu_bypass_supported()

Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 98d858999a2d..7e88de18ead6 100644 --- a/arch/powerp

[Very RFC 31/46] powernv/pci: Remove open-coded PE lookup in pnv_pci_ioda_dma_dev_setup()

Use the helper to look up the pnv_ioda_pe for the device we're configuring DMA for. In the VF case there's no need set pdn->pe_number since nothing looks at it any more. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 3 +-- 1 file changed, 1 insertion(+), 2 dele

[Very RFC 30/46] powernv/pci: Remove open-coded PE lookup in PELT-V teardown

Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 5bd7c1b058da..d4b5ee926222 100644 --- a/arch

[Very RFC 29/46] powernv/pci: Remove open-coded PE lookup in PELT-V setup

Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 32 +-- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 1c90feed233d..5bd7c1b058da 10064

[Very RFC 28/46] powernv/iov: Move SR-IOV PF state out of pci_dn

Move the SR-IOV into a platform specific structure. I'm sure stashing all the SR-IOV state in pci_dn seemed like a good idea at the time, but it results in a lot of powernv specifics being leaked out of the platform directory. Moving all the PHB3/4 specific M64 BAR wrangling into a PowerNV specifi

[Very RFC 27/46] powernv/pci: Clear reserved PE freezes

When we scan an empty slot the PHB gets an Unsupported Request from the downstream bridge when there's no device present at that BDFN. Some older PHBs (p7-IOC) don't allow further config space accesses while the PE is frozen, so clear it here without bothering with the diagnostic log. Signed-off-

[Very RFC 26/46] powernv/pci: Remove pdn from pnv_pci_cfg_{read|write}

Remove the use of pci_dn from the low-level config space access functions. These are used by the eeh's config ops and the bus config ops that we provide to the PCI core. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +++ arch/powerpc/platforms/pow

[Very RFC 25/46] powernv/pci: Remove pdn from pnv_pci_config_check_eeh()

Despite the name this function is generic PowerNV PCI code rather than anything EEH specific. Convert to take a phb and bdfn rather than a pci_dn. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci.c | 32 ++-- 1 file changed, 21 insertions(+), 11 del

[Very RFC 24/46] powernv/pci: Make the pre-cfg EEH freeze check use eeh_dev rather than pci_dn

Squash another usage in preperation for making the config accessors pci_dn. Signed-off-by: Oliver O'Halloran --- We might want to move this into eeh-powernv.c --- arch/powerpc/platforms/powernv/pci.c | 37 +--- 1 file changed, 17 insertions(+), 20 deletions(-) diff --git

[Very RFC 23/46] powerpc/eeh: Moving finding the parent PE into the platform

Currently the generic EEH code uses the pci_dn of a device to look up the PE of the device's parent bridge, or physical function. The generic function to insert the edev (and possibly create the eeh_pe) is called from the probe functions already so this is a relatively minor change. The existing l

[Very RFC 22/46] powernv/eeh: Allocate eeh_dev's when needed

Have the PowerNV EEH backend allocate the eeh_dev if needed rather than using the one attached to the pci_dn. This gets us most of the way towards decoupling pci_dn from the PowerNV EEH code. Signed-off-by: Oliver O'Halloran --- We should probably be free()ing the eeh_dev somewhere. The pci_dev r

[Very RFC 21/46] powernv/eeh: Rework finding an existing edev in probe_pdev()

Use the pnv_eeh_find_edev() helper to look up the eeh_dev for a device rather than doing it via the pci_dn. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/eeh-powernv.c | 44 ++-- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/arch/powerpc/pl

[Very RFC 20/46] powernv/eeh: Look up device info from pci_dev

Most of what we fetch from the pci_dn is also in the pci_dev structure. Convert the pnv_eeh_probe_pdev() to use the pdev fields rather than the pci_dn so we can get rid of pci_dn eventually. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/eeh-powernv.c | 26 ++

[Very RFC 19/46] powernv/eeh: Use standard PCI capability lookup functions

We have a pci_dev so we can use the functions provided by the PCI core for looking up capabilities. This should be safe since these are only called when initialising the eeh_dev when the device is first probed and not in the EEH recovery path where config accesses are blocked. This might cause a p

[Very RFC 18/46] powernv/pci: Add pci_bus_to_pnvhb() helper

Add a helper to go from a pci_bus structure to the pnv_phb that hosts that bus. There's a lot of instances of the following pattern: struct pci_controller *hose = pci_bus_to_host(pdev->bus); struct pnv_phb *phb = hose->private_data; Without any other uses of the pci_controller ins

[Very RFC 17/46] powernv/eeh: add pnv_eeh_find_edev()

To get away from using pci_dn we need a way to find the edev for a given bdfn. The easiest way to do this is to find the ioda_pe for that BDFN in the PHB's reverse mapping table and scan the device list of the corresponding eeh_pe. Is this slow? Yeah probably. Is it slower than the existing "trave

[Very RFC 16/46] powernv/eeh: Use eeh_edev_warn() rather than open-coding a BDFN print

Neaten things up a bit and remove a pci_dn use. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/eeh-powernv.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c

[Very RFC 15/46] powernv/eeh: Use pnv_eeh_*_config() for internal config ops

Use the pnv_eeh_{read|write}_config() functions that take an edev rather than a pci_dn. This allows us to remove most of the explict uses of pci_dn in the PowerNV EEH backend and localises them into a few functions which we can fix later. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platfor

[Very RFC 14/46] powernv/eeh: Remove un-necessary call to eeh_add_device_early()

eeh_add_device_early() is used to initialise the EEH state for a PCI device based on the contents of it's devicetree node. It doesn't do anything unless EEH_FLAG_PROBE_MODE_DEVTREE is set and that only happens on pseries. Remove the call to eeh_add_device_early() in the powernv code to squash anot

[Very RFC 13/46] powerpc/eeh: Rework how pdev_probe() is used

Adjust how the EEH core uses the eeh_ops->probe_pdev() so that it returns the eeh_dev for the passed-in pci_dev. Currently mapping an pci_dev to an eeh_dev is done by finding the pci_dn for the pci_dev, then using the back-pointer to the eeh_dev stashed in the pci_dn. We want to move away from usi

[Very RFC 12/46] powerpc/eeh: Split eeh_probe into probe_pdn and probe_pdev

The EEH core has a concept of "early probe" and "late probe." When the EEH_PROBE_MODE_DEVTREE flag is set (i.e pseries) we call the eeh_ops->probe() function in eeh_add_device_early() so the eeh_dev state is initialised based on the pci_dn. It's important to realise that this happens *long* before

[Very RFC 11/46] powerpc/eeh: Convert various printfs to use edev, not pci_dn

We use the pci_dn to retrieve the domain, bus, device, and function numbers for an EEH device. We now have that in the eeh_dev so covert the various printk()s we have around the place to source that information from the eeh_dev. Signed-off-by: Oliver O'Halloran --- arch/powerpc/kernel/eeh.c|

[Very RFC 10/46] powerpc/eeh: Pass eeh_dev to eeh_ops->restore_config()

Remove another pdn usage. Signed-off-by: Oliver O'Halloran --- arch/powerpc/include/asm/eeh.h | 2 +- arch/powerpc/kernel/eeh.c| 5 ++--- arch/powerpc/kernel/eeh_pe.c | 6 ++ arch/powerpc/platforms/powernv/eeh-powernv.c | 11 +-- 4

[Very RFC 09/46] powerpc/eeh: Pass eeh_dev to eeh_ops->{read|write}_config()

Switch the eeh_ops->{read|write}_config methods to take an eeh_dev structure rather than a pci_dn structure to specify the target device. This removes a lot of the uses of pci_dn in both the EEH core and in the platform EEH support. Signed-off-by: Oliver O'Halloran --- arch/powerpc/include/asm/e

[Very RFC 08/46] powerpc/eeh: Calculate VF index rather than looking it up in pci_dn

Find the VF index based on the BDFN of the device rather than using a cached value in the pci_dn. This is probably slower than looking up the cached value in the pci_dn, but it's done infrequently (only in the EEH recovery path) and it's just arithmatic. We need this here because the functions to

[Very RFC 07/46] powernv/pci: Rework IODA PE device accounting

The current process for configuring the IODA PEs for normal PCI devices is abit stupid. After assigning MMIO resources for the devices on a bus the actual PE asignment occurs when pcibios_setup_bridge() is called for the parent bridge. In pcibios_setup_bridge() we: 1. Assign all 256 devfn's for th

[Very RFC 06/46] powerpc/iov: Move VF pdev fixup into pcibios_fixup_iov()

Move this out of the PHB's dma_dev_setup() callback and into the ppc_md.pcibios_fixup_iov callback. This ensures that the VF PE's pdev pointer is always valid for the whole time the device is added the bus. This isn't strictly required, but it's slightly a slightly more logical place to do the fix

[Very RFC 05/46] powernv/pci: Remove the pnv_phb dma_dev_setup callback

This is only ever set for IODA PHBs. The only call site is in pnv_pci_dma_dev_setup(), which is also only used by normal IODA PHBs, so remove the callback in favour of a direct call. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 4 +--- arch/powerpc/platforms/p

[Very RFC 04/46] powernv/pci: Move dma_{dev|bus}_setup into pci-ioda.c

These functions are only used from pci-ioda.c. Move them in there and remove the prototypes from the header files. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/pci-ioda.c | 43 +++ arch/powerpc/platforms/powernv/pci.c | 43 ---

[Very RFC 03/46] powernv/pci: Remove dma_dev_setup() for NPU PHBs

The pnv_pci_dma_dev_setup() only does something when: 1) There PHB contains VFs, or 2) The PHB defines a dma_dev_setup() callback in the pnv_phb structure. Neither is true for NPU PHBs, so don't set the callback in the pci_controller_ops. Signed-off-by: Oliver O'Halloran --- arch/powerpc/plat

[Very RFC 02/46] powernv/pci: Add helper to find ioda_pe from BDFN

Linux has a look-up table for mapping BDFNs to PEs which is updated when we call into OPAL to update the PHB's internally BDFN<->PE mapping. We can use this table to the PE for a device without needing to use the cached value inside the pci_dn. We'd like to get rid of pci_dn eventually so this pat

[Very RFC 01/46] powerpc/eeh: Don't attempt to restore VF config space after reset

After resetting a VF we call eeh_restore_vf_config() to restore several registers in the VFs config space. For physical functions this is normally handled by the pci_reinit_device() OPAL call which requests firmware to re-program the device with whatever defaults were set at boot time. We can't use

PCIPOCALYPSE

This series does a few things and probably needs to be split into two or three smaller ones. I figured I'd post it as-is since I'm sick of sitting on it and some people wanted people to take a look at it. There's three parts: 1) Reworking EEH to move the "pseudo-generic" into the platform backend.

[PATCH v2] powerpc: Add const qual to local_read() parameter

From: Eric Dumazet A patch in net-next triggered a compile error on powerpc: include/linux/u64_stats_sync.h: In function 'u64_stats_read': include/asm-generic/local64.h:30:37: warning: passing argument 1 of 'local_read' discards 'const' qualifier from pointer target type This seems reasona

Re: [PATCH v6 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()

On Tue, 19 Nov 2019 15:16:22 +0100 David Hildenbrand wrote: > On 14.10.19 21:17, Andrew Morton wrote: > > On Mon, 14 Oct 2019 11:32:13 +0200 David Hildenbrand > > wrote: > > > >>> Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug") > >> > >> @Andrew, can you convert that to > >>

next/master bisection: boot on peach-pi

this helps! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * next/master bisection: boot on peach-pi Summary: Start: 5d1131b4d61e Add linux-next specific files for 20191119 Details:https://kernelci.org/boot/id/5dd3cc9559b514

Re: [RFC PATCH 1/4] libnvdimm/namespace: Make namespace size validation arch dependent

On Mon, Nov 18, 2019 at 1:52 AM Aneesh Kumar K.V wrote: > > Dan Williams writes: > > > On Sat, Nov 16, 2019 at 4:15 AM Aneesh Kumar K.V > > wrote: > >> > > > > > >> > >> Considering the direct-map map size is not going to be user selectable, > >> do you agree that we can skip the above step

Re: [PATCH v4 2/2] powerpc/kexec: move kexec files into a dedicated subdir.

Michael Ellerman a écrit : Christophe Leroy writes: arch/powerpc/kernel/ contains 8 files dedicated to kexec. Move them into a dedicated subdirectory. Signed-off-by: Christophe Leroy --- v2: moved crash.c as well as it's part of kexec suite. v3: renamed files to remove 'kexec' keyword fro

Re: [PATCH] powerpc/8xx: Fix permanently mapped IMMR region.

Michael Ellerman a écrit : Christophe Leroy writes: When not using large TLBs, the IMMR region is still mapped as a whole block in the FIXMAP area. Do not remove pages mapped in the FIXMAP region when initialising paging. Properly report that the IMMR region is block-mapped even when not us

Re: generic DMA bypass flag

On 16/11/2019 6:22 am, Christoph Hellwig wrote: On Fri, Nov 15, 2019 at 06:12:48PM +, Robin Murphy wrote: And is that any different from where you would choose to "just" set a generic bypass flag? Same spots, as intel-iommu moves from the identify to a dma domain when setting a 32-bit mask

Re: [PATCH 04/11] powerpc/powernv/ioda: Release opencapi device

Le 10/09/2019 à 02:56, Alastair D'Silva a écrit : On Mon, 2019-09-09 at 17:45 +0200, Frederic Barrat wrote: With hotplug, an opencapi device can now go away. It needs to be released, mostly to clean up its PE state. We were previously not defining any device callback. We can reuse the standar

Re: [PATCH v3 15/15] powerpc/32s: Activate CONFIG_VMAP_STACK

Michael Ellerman a écrit : Christophe Leroy writes: A few changes to retrieve DAR and DSISR from struct regs instead of retrieving them directly, as they may have changed due to a TLB miss. Also modifies hash_page() and friends to work with virtual data addresses instead of physical ones. S

Re: [PATCH] dma-mapping: treat dev->bus_dma_mask as a DMA limit

On 19/11/2019 5:00 pm, Christoph Hellwig wrote: On Tue, Nov 19, 2019 at 01:57:43PM +0100, Nicolas Saenz Julienne wrote: Hi Rob & Christoph, do you mind if I append v2 of this into my upcoming v3 RPi4 PCIe support series, I didn't do it initially as I thought this was going to be a contentious pa

Re: [PATCH] dma-mapping: treat dev->bus_dma_mask as a DMA limit

On Tue, Nov 19, 2019 at 01:57:43PM +0100, Nicolas Saenz Julienne wrote: > Hi Rob & Christoph, > do you mind if I append v2 of this into my upcoming v3 RPi4 PCIe support > series, I didn't do it initially as I thought this was going to be a > contentious patch. But as it turned out better than expe

Re: [PATCH 1/3] dma-direct: unify the dma_capable definitions

On Tue, Nov 19, 2019 at 11:26:39AM +0100, Marek Szyprowski wrote: > Christoph: Let me know if this is a proper fix for you, then I will send > it as a full patch. Besides the point from Robin, which is really older than you patch I'm not a fan of duplicating dma_capable here. Let me know what yo

Re: [PATCH 1/3] dma-direct: unify the dma_capable definitions

On 19/11/2019 10:26 am, Marek Szyprowski wrote: Hi Krzysztof, On 19.11.2019 10:44, Krzysztof Kozlowski wrote: On Tue, 19 Nov 2019 at 17:27, Marek Szyprowski wrote: Hi Christoph, On 13.11.2019 08:35, Christoph Hellwig wrote: Currently each architectures that wants to override dma_to_phys and

Re: [PATCH v6 15/24] fs/io_uring: set FOLL_PIN via pin_user_pages()

On 11/19/19 1:16 AM, John Hubbard wrote: > Convert fs/io_uring to use the new pin_user_pages() call, which sets > FOLL_PIN. Setting FOLL_PIN is now required for code that requires > tracking of pinned pages, and therefore for any code that calls > put_user_page(). > > In partial anticipation of th

Re: [PATCH 08/11] pci/hotplug/pnv-php: Register opencapi slots

Le 19/11/2019 à 06:18, Andrew Donnellan a écrit : On 10/9/19 1:45 am, Frederic Barrat wrote: Add the opencapi PHBs to the list of PHBs being scanned to look for slots. Signed-off-by: Frederic Barrat ---   drivers/pci/hotplug/pnv_php.c | 5 -   1 file changed, 4 insertions(+), 1 deletion(

Re: [PATCH 02/11] powerpc/powernv/ioda: Protect PE list

Le 19/11/2019 à 14:22, Oliver O'Halloran a écrit : On Tue, Nov 19, 2019 at 11:57 PM Frederic Barrat wrote: Do the other accessors of ioda.pe_list also need mutex protection? pnv_ioda_setup_bus_PE() pnv_pci_dma_bus_setup() pnv_pci_init_ioda_phb() pnv_pci_ioda_setup_PEs() I think we could

Re: [PATCH 05/11] powerpc/powernv/ioda: Find opencapi slot for a device node

Le 19/11/2019 à 02:26, Andrew Donnellan a écrit : On 10/9/19 1:45 am, Frederic Barrat wrote: diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c index 6104418c9ad5..00a79f3c989f 100644 --- a/arch/powerpc/platforms/powernv/pci.c +++ b/arch/powerpc/platform

Re: [PATCH v6 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()

On 14.10.19 21:17, Andrew Morton wrote: > On Mon, 14 Oct 2019 11:32:13 +0200 David Hildenbrand wrote: > >>> Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug") >> >> @Andrew, can you convert that to >> >> Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded >> memory

Re: [PATCH 02/11] powerpc/powernv/ioda: Protect PE list

On Tue, Nov 19, 2019 at 11:57 PM Frederic Barrat wrote: > > > Do the other accessors of ioda.pe_list also need mutex protection? > > pnv_ioda_setup_bus_PE() > > pnv_pci_dma_bus_setup() > > pnv_pci_init_ioda_phb() > > pnv_pci_ioda_setup_PEs() > > > I think we could also use it there, it wouldn't hu

Re: [PATCH] dma-mapping: treat dev->bus_dma_mask as a DMA limit

On Wed, 2019-11-13 at 17:13 +0100, Nicolas Saenz Julienne wrote: > Using a mask to represent bus DMA constraints has a set of limitations. > The biggest one being it can only hold a power of two (minus one). The > DMA mapping code is already aware of this and treats dev->bus_dma_mask > as a limit.

Re: [PATCH 02/11] powerpc/powernv/ioda: Protect PE list

Le 10/09/2019 à 02:34, Alastair D'Silva a écrit : On Mon, 2019-09-09 at 17:45 +0200, Frederic Barrat wrote: Protect the PHB's list of PE. Probably not needed as long as it was populated during PHB creation, but it feels right and will become required once we can add/remove opencapi devices on

Re: [PATCH v6 24/24] mm, tree-wide: rename put_user_page*() to unpin_user_page*()

On Tue 19-11-19 00:16:43, John Hubbard wrote: > In order to provide a clearer, more symmetric API for pinning > and unpinning DMA pages. This way, pin_user_pages*() calls > match up with unpin_user_pages*() calls, and the API is a lot > closer to being self-explanatory. > > Signed-off-by: John Hub

Re: [PATCH v6 17/24] mm/gup: track FOLL_PIN pages

On Tue 19-11-19 00:16:36, John Hubbard wrote: > @@ -2025,6 +2149,20 @@ static int __record_subpages(struct page *page, > unsigned long addr, > return nr; > } > > +static bool __pin_compound_head(struct page *head, int refs, unsigned int > flags) > +{ I don't quite like the proliferation

Re: [PATCH 1/3] dma-direct: unify the dma_capable definitions

Hi Krzysztof, On 19.11.2019 10:44, Krzysztof Kozlowski wrote: > On Tue, 19 Nov 2019 at 17:27, Marek Szyprowski > wrote: >> Hi Christoph, >> >> On 13.11.2019 08:35, Christoph Hellwig wrote: >>> Currently each architectures that wants to override dma_to_phys and >>> phys_to_dma also has to provide

Re: [PATCH 1/3] dma-direct: unify the dma_capable definitions

On Tue, 2019-11-19 at 10:27 +0100, Marek Szyprowski wrote: > Hi Christoph, > > On 13.11.2019 08:35, Christoph Hellwig wrote: > > Currently each architectures that wants to override dma_to_phys and > > phys_to_dma also has to provide dma_capable. But there isn't really > > any good reason for that

Re: [PATCH v6 02/24] mm/gup: factor out duplicate code from four routines

On Tue 19-11-19 00:16:21, John Hubbard wrote: > There are four locations in gup.c that have a fair amount of code > duplication. This means that changing one requires making the same > changes in four places, not to mention reading the same code four > times, and wondering if there are subtle diffe

Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory

On 11/18/19 6:29 AM, Daniel Axtens wrote: > Qian Cai writes: > >> On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote: >>> /* >>> * In this function, newly allocated vm_struct has VM_UNINITIALIZED >>> * flag. It means that vm_struct is not fully initialized. >>> @@ -3377,6 +34

  1   2   >