Re: [PATCH 07/19] mm/gup: introduce pin_user_pages*() and FOLL_PIN

2019-11-24 Thread kbuild test robot
Hi John, Thank you for the patch! Yet something to improve: [auto build test ERROR on rdma/for-next] [also build test ERROR on v5.4 next-20191122] [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

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

2019-11-24 Thread Christoph Hellwig
On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: > Just as an FYI, this introduces a warning on arm32 allyesconfig for me: I think the dma_limit argument to iommu_dma_alloc_iova should be a u64 and/or we need to use min_t and open code the zero exception. Robin, Nicolas - any

Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M

2019-11-24 Thread Christoph Hellwig
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote: > Hello Christoph, > > Please find attached the dmesg of your Git kernel. Thanks. It looks like on your platform the swiotlb buffer isn't actually addressable based on the bus dma mask limit, which is rather interesting.

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

2019-11-24 Thread Aleksa Sarai
On 2019-11-25, Al Viro wrote: > On Sun, Nov 17, 2019 at 12:17:08PM +1100, Aleksa Sarai wrote: > > > + if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) { > > + /* > > +* Do a final check to ensure that the path didn't escape. Note > > +* that this should already be

Re: lockdep warning while booting POWER9 PowerNV

2019-11-24 Thread Michael Ellerman
On 25 November 2019 12:12:01 pm AEDT, Daniel Axtens wrote: >Hi Michael, > Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) >would generate a warning in lockdep_register_key() at, if (WARN_ON_ONCE(static_obj(key))) because key =

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

2019-11-24 Thread Alexey Kardashevskiy
On 20/11/2019 12:28, Oliver O'Halloran wrote: > 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

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

2019-11-24 Thread Oliver O'Halloran
On Thu, Nov 21, 2019 at 3:34 PM Alexey Kardashevskiy wrote: > > > > On 20/11/2019 12:28, Oliver O'Halloran wrote: > > 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

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

2019-11-24 Thread Oliver O'Halloran
On Thu, Nov 21, 2019 at 6:48 PM Christoph Hellwig wrote: > > On Wed, Nov 20, 2019 at 12:28:19PM +1100, Oliver O'Halloran wrote: > > 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

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

2019-11-24 Thread Anshuman Khandual
On 11/20/2019 11:01 AM, Anshuman Khandual wrote: > 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

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

2019-11-24 Thread Oliver O'Halloran
On Mon, Nov 25, 2019 at 2:27 PM Alexey Kardashevskiy wrote: > > > > On 20/11/2019 12:28, Oliver O'Halloran wrote: > > Have the PowerNV EEH backend allocate the eeh_dev if needed rather than > > using > > the one attached to the pci_dn. > > So that pci_dn attached one is leaked then? Sorta, the

[PATCH 09/19] IB/{core, hw, umem}: set FOLL_PIN via pin_user_pages*(), fix up ODP

2019-11-24 Thread John Hubbard
Convert infiniband to use the new pin_user_pages*() calls. Also, revert earlier changes to Infiniband ODP that had it using put_user_page(). ODP is "Case 3" in Documentation/core-api/pin_user_pages.rst, which is to say, normal get_user_pages() and put_page() is the API to use there. The new

[PATCH 06/19] vfio: fix FOLL_LONGTERM use, simplify get_user_pages_remote() call

2019-11-24 Thread John Hubbard
Update VFIO to take advantage of the recently loosened restriction on FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it wasn't setting FOLL_LONGTERM. Also, remove an unnessary pair of calls that were

[PATCH 14/19] media/v4l2-core: set pages dirty upon releasing DMA buffers

2019-11-24 Thread John Hubbard
After DMA is complete, and the device and CPU caches are synchronized, it's still required to mark the CPU pages as dirty, if the data was coming from the device. However, this driver was just issuing a bare put_page() call, without any set_page_dirty*() call. Fix the problem, by calling

[PATCH 05/19] mm: fix get_user_pages_remote()'s handling of FOLL_LONGTERM

2019-11-24 Thread John Hubbard
As it says in the updated comment in gup.c: current FOLL_LONGTERM behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the FS DAX check requirement on vmas. However, the corresponding restriction in get_user_pages_remote() was slightly stricter than is actually required: it forbade all

[PATCH 16/19] vfio, mm: pin_user_pages (FOLL_PIN) and put_user_page() conversion

2019-11-24 Thread John Hubbard
1. Change vfio from get_user_pages_remote(), to pin_user_pages_remote(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Note that this effectively changes the code's behavior in

[PATCH 02/19] mm/gup: move try_get_compound_head() to top, fix minor issues

2019-11-24 Thread John Hubbard
An upcoming patch uses try_get_compound_head() more widely, so move it to the top of gup.c. Also fix a tiny spelling error and a checkpatch.pl warning. Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Ira Weiny Signed-off-by: John Hubbard --- mm/gup.c | 29

[PATCH 03/19] mm: Cleanup __put_devmap_managed_page() vs ->page_free()

2019-11-24 Thread John Hubbard
From: Dan Williams After the removal of the device-public infrastructure there are only 2 ->page_free() call backs in the kernel. One of those is a device-private callback in the nouveau driver, the other is a generic wakeup needed in the DAX case. In the hopes that all ->page_free() callbacks

[PATCH 08/19] goldish_pipe: convert to pin_user_pages() and put_user_page()

2019-11-24 Thread John Hubbard
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). In this case, do so via put_user_pages_dirty_lock(). That has the side effect of calling set_page_dirty_lock(), instead of set_page_dirty(). This

[PATCH 11/19] drm/via: set FOLL_PIN via pin_user_pages_fast()

2019-11-24 Thread John Hubbard
Convert drm/via to use the new pin_user_pages_fast() 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 this work, the drm/via driver was already calling

[PATCH 00/19] pin_user_pages(): reduced-risk series for Linux 5.5

2019-11-24 Thread John Hubbard
Hi, Here is a set of well-reviewed (expect for one patch), lower-risk items that can go into Linux 5.5. The one patch that wasn't reviewed is the powerpc conversion, and it's still at this point a no-op, because tracking isn't yet activated. This is based on linux-next:

[PATCH 01/19] mm/gup: factor out duplicate code from four routines

2019-11-24 Thread John Hubbard
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 differences. Factor out the common code into static

[PATCH 17/19] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

2019-11-24 Thread John Hubbard
1. Convert from get_user_pages() to pin_user_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). In this case, do so via put_user_pages_dirty_lock(). That has the side effect of calling set_page_dirty_lock(), instead of set_page_dirty(). This is probably more

[PATCH 13/19] net/xdp: set FOLL_PIN via pin_user_pages()

2019-11-24 Thread John Hubbard
Convert net/xdp to use the new pin_longterm_pages() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. In partial anticipation of this work, the net/xdp code was already calling put_user_page() instead of put_page(). Therefore, in order to

[PATCH 04/19] goldish_pipe: rename local pin_user_pages() routine

2019-11-24 Thread John Hubbard
1. Avoid naming conflicts: rename local static function from "pin_user_pages()" to "goldfish_pin_pages()". An upcoming patch will introduce a global pin_user_pages() function. Reviewed-by: Jan Kara Reviewed-by: Jérôme Glisse Reviewed-by: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH 07/19] mm/gup: introduce pin_user_pages*() and FOLL_PIN

2019-11-24 Thread John Hubbard
Introduce pin_user_pages*() variations of get_user_pages*() calls, and also pin_longterm_pages*() variations. For now, these are placeholder calls, until the various call sites are converted to use the correct get_user_pages*() or pin_user_pages*() API. These variants will eventually all set

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

2019-11-24 Thread John Hubbard
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. Reviewed-by: Jan Kara Signed-off-by: John Hubbard ---

[PATCH 10/19] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()

2019-11-24 Thread John Hubbard
Convert process_vm_access to use the new pin_user_pages_remote() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. Also, release the pages via put_user_page*(). Also, rename "pages" to "pinned_pages", as this makes for easier reading of

[PATCH 18/19] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1"

2019-11-24 Thread John Hubbard
Fix the gup benchmark flags to use the symbolic FOLL_WRITE, instead of a hard-coded "1" value. Also, clean up the filtering of gup flags a little, by just doing it once before issuing any of the get_user_pages*() calls. This makes it harder to overlook, instead of having little "gup_flags & 1"

[PATCH 15/19] media/v4l2-core: pin_user_pages (FOLL_PIN) and put_user_page() conversion

2019-11-24 Thread John Hubbard
1. Change v4l2 from get_user_pages() to pin_user_pages(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Acked-by: Hans Verkuil Cc: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH 12/19] fs/io_uring: set FOLL_PIN via pin_user_pages()

2019-11-24 Thread John Hubbard
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 this work, the io_uring code was already calling

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

2019-11-24 Thread Oliver O'Halloran
On Mon, Nov 25, 2019 at 2:20 PM Alexey Kardashevskiy wrote: > > > > On 20/11/2019 12:28, Oliver O'Halloran wrote: > > Use the pnv_eeh_find_edev() helper to look up the eeh_dev for a device > > rather than doing it via the pci_dn. > > This is not what the patch does. I struggle to see what is that

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

2019-11-24 Thread Alexey Kardashevskiy
On 20/11/2019 12:28, Oliver O'Halloran wrote: > Have the PowerNV EEH backend allocate the eeh_dev if needed rather than using > the one attached to the pci_dn. So that pci_dn attached one is leaked then? > This gets us most of the way towards decoupling > pci_dn from the PowerNV EEH code. >

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

2019-11-24 Thread Alexey Kardashevskiy
On 20/11/2019 12:28, Oliver O'Halloran wrote: > Use the pnv_eeh_find_edev() helper to look up the eeh_dev for a device > rather than doing it via the pci_dn. This is not what the patch does. I struggle to see what is that thing really. > > Signed-off-by: Oliver O'Halloran > --- >

Re: [PATCH v11 1/7] mm: ksm: Export ksm_madvise()

2019-11-24 Thread Bharata B Rao
On Mon, Nov 25, 2019 at 08:36:25AM +0530, Bharata B Rao wrote: > On PEF-enabled POWER platforms that support running of secure guests, > secure pages of the guest are represented by device private pages > in the host. Such pages needn't participate in KSM merging. This is > achieved by using

[PATCH v11 7/7] KVM: PPC: Ultravisor: Add PPC_UV config option

2019-11-24 Thread Bharata B Rao
From: Anshuman Khandual CONFIG_PPC_UV adds support for ultravisor. Signed-off-by: Anshuman Khandual Signed-off-by: Bharata B Rao Signed-off-by: Ram Pai [ Update config help and commit message ] Signed-off-by: Claudio Carvalho Reviewed-by: Sukadev Bhattiprolu --- arch/powerpc/Kconfig | 17

[PATCH v11 6/7] KVM: PPC: Support reset of secure guest

2019-11-24 Thread Bharata B Rao
Add support for reset of secure guest via a new ioctl KVM_PPC_SVM_OFF. This ioctl will be issued by QEMU during reset and includes the the following steps: - Release all device pages of the secure guest. - Ask UV to terminate the guest via UV_SVM_TERMINATE ucall - Unpin the VPA pages so that they

[PATCH v11 5/7] KVM: PPC: Handle memory plug/unplug to secure VM

2019-11-24 Thread Bharata B Rao
Register the new memslot with UV during plug and unregister the memslot during unplug. In addition, release all the device pages during unplug. Signed-off-by: Bharata B Rao --- arch/powerpc/include/asm/kvm_book3s_uvmem.h | 6 arch/powerpc/include/asm/ultravisor-api.h | 1 +

[PATCH v11 4/7] KVM: PPC: Radix changes for secure guest

2019-11-24 Thread Bharata B Rao
- After the guest becomes secure, when we handle a page fault of a page belonging to SVM in HV, send that page to UV via UV_PAGE_IN. - Whenever a page is unmapped on the HV side, inform UV via UV_PAGE_INVAL. - Ensure all those routines that walk the secondary page tables of the guest don't do

[PATCH v11 3/7] KVM: PPC: Shared pages support for secure guests

2019-11-24 Thread Bharata B Rao
A secure guest will share some of its pages with hypervisor (Eg. virtio bounce buffers etc). Support sharing of pages between hypervisor and ultravisor. Shared page is reachable via both HV and UV side page tables. Once a secure page is converted to shared page, the device page that represents

[PATCH v11 2/7] KVM: PPC: Support for running secure guests

2019-11-24 Thread Bharata B Rao
A pseries guest can be run as secure guest on Ultravisor-enabled POWER platforms. On such platforms, this driver will be used to manage the movement of guest pages between the normal memory managed by hypervisor (HV) and secure memory managed by Ultravisor (UV). HV is informed about the guest's

[PATCH v11 1/7] mm: ksm: Export ksm_madvise()

2019-11-24 Thread Bharata B Rao
On PEF-enabled POWER platforms that support running of secure guests, secure pages of the guest are represented by device private pages in the host. Such pages needn't participate in KSM merging. This is achieved by using ksm_madvise() call which need to be exported since KVM PPC can be a kernel

[PATCH v11 0/7] KVM: PPC: Driver to manage pages of secure guest

2019-11-24 Thread Bharata B Rao
Hi, This is the next version of the patchset that adds required support in the KVM hypervisor to run secure guests on PEF-enabled POWER platforms. This version includes the following changes: - Ensure that any malicious calls to the 4 hcalls (init_start, init_done, page_in and page_out) are

Re: [PATCH v3] libfdt: define INT32_MAX and UINT32_MAX in libfdt_env.h

2019-11-24 Thread Masahiro Yamada
On Wed, Nov 13, 2019 at 4:13 PM Masahiro Yamada wrote: > > The DTC v1.5.1 added references to (U)INT32_MAX. > > This is no problem for user-space programs since defines > (U)INT32_MAX along with (u)int32_t. > > For the kernel space, libfdt_env.h needs to be adjusted before we > pull in the

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

2019-11-24 Thread Alexey Kardashevskiy
On 20/11/2019 12:28, Oliver O'Halloran wrote: > 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 > --- >

Re: lockdep warning while booting POWER9 PowerNV

2019-11-24 Thread Daniel Axtens
Hi Michael, >>> Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would >>> generate >>> a warning in lockdep_register_key() at, >>> >>> if (WARN_ON_ONCE(static_obj(key))) >>> >>> because >>> >>> key = 0xc19ad118 >>> &_stext = 0xc000 >>> &_end =

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

2019-11-24 Thread Alexey Kardashevskiy
On 20/11/2019 12:28, Oliver O'Halloran wrote: > 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

Re: [PATCH v7 07/24] IB/umem: use get_user_pages_fast() to pin DMA pages

2019-11-24 Thread Jason Gunthorpe
On Sun, Nov 24, 2019 at 04:05:16PM -0800, John Hubbard wrote: > I looked into this, and I believe that the problem is in gup.c. There appears > to > have been an oversight, in commit 817be129e6f2 ("mm: validate > get_user_pages_fast > flags"), in filtering out FOLL_FORCE. There is nothing in

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

2019-11-24 Thread Alexey Kardashevskiy
On 20/11/2019 12:28, Oliver O'Halloran wrote: > 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 =

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

2019-11-24 Thread Al Viro
Generally I can live with that - the only serious issue is with that WARN_ON() and the logics of the check in it.

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

2019-11-24 Thread Al Viro
On Sun, Nov 17, 2019 at 12:17:11PM +1100, Aleksa Sarai wrote: > +/* how->upgrade flags for openat2(2). */ > +/* First bit is reserved for a future UPGRADE_NOEXEC flag. */ > +#define UPGRADE_NOREAD 0x02 /* Block re-opening with MAY_READ. > */ > +#define UPGRADE_NOWRITE

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

2019-11-24 Thread Al Viro
On Sun, Nov 17, 2019 at 12:17:10PM +1100, Aleksa Sarai wrote: > + if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) { > + /* > + * If there was a racing rename or mount along our > + * path, then we can't be sure that ".." hasn't

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

2019-11-24 Thread Alexey Kardashevskiy
On 20/11/2019 12:28, Oliver O'Halloran wrote: > 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

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

2019-11-24 Thread Al Viro
On Sun, Nov 17, 2019 at 12:17:08PM +1100, Aleksa Sarai wrote: > + if (unlikely(nd->flags & LOOKUP_IS_SCOPED)) { > + /* > + * Do a final check to ensure that the path didn't escape. Note > + * that this should already be guaranteed by all of the other > +

Re: [PATCH v7 07/24] IB/umem: use get_user_pages_fast() to pin DMA pages

2019-11-24 Thread John Hubbard
On 11/24/19 2:07 AM, Leon Romanovsky wrote: > On Thu, Nov 21, 2019 at 10:36:43AM -0400, Jason Gunthorpe wrote: >> On Thu, Nov 21, 2019 at 12:07:46AM -0800, Christoph Hellwig wrote: >>> On Wed, Nov 20, 2019 at 11:13:37PM -0800, John Hubbard wrote: And get rid of the mmap_sem calls, as part of

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

2019-11-24 Thread Jakub Kicinski
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 >

linux-next: manual merge of the pci tree with the powerpc tree

2019-11-24 Thread Stephen Rothwell
Hi all, Today's linux-next merge of the pci tree got a conflict in: arch/powerpc/include/asm/Kbuild between commit: 265c3491c4bc ("powerpc: Add support for GENERIC_EARLY_IOREMAP") from the powerpc tree and commit: 356f42aff121 ("asm-generic: Make msi.h a mandatory include/asm header")

Re: [PATCH v3 2/4] powerpc/fadump: reorganize /sys/kernel/fadump_* sysfs files

2019-11-24 Thread Michal Suchánek
On Sat, Nov 16, 2019 at 08:07:29PM +0530, Sourabh Jain wrote: > > > On 11/9/19 6:29 PM, Michal Suchánek wrote: > > On Sat, Nov 09, 2019 at 05:53:37PM +0530, Sourabh Jain wrote: > >> As the number of FADump sysfs files increases it is hard to manage all of > >> them inside /sys/kernel directory.

Re: [PATCH v7 07/24] IB/umem: use get_user_pages_fast() to pin DMA pages

2019-11-24 Thread Leon Romanovsky
On Thu, Nov 21, 2019 at 10:36:43AM -0400, Jason Gunthorpe wrote: > On Thu, Nov 21, 2019 at 12:07:46AM -0800, Christoph Hellwig wrote: > > On Wed, Nov 20, 2019 at 11:13:37PM -0800, John Hubbard wrote: > > > And get rid of the mmap_sem calls, as part of that. Note > > > that get_user_pages_fast()