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() wil
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. I
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")
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
> 'local_rea
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 t
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
> +
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 th
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 j
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 0
Generally I can live with that - the only serious issue is
with that WARN_ON() and the logics of the check in it.
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 = hose->private_
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 th
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 path
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 = 0xc49
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
> ---
>
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 change
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 ha
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 mo
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 tr
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
the
- 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 s
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 +
arch/powerpc
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
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 +
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 ksm_ma
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
> ---
> arch/powe
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.
>
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
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 put_us
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
---
drivers/media/v4l2-
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"
phr
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 p
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
---
Documentation/core-api/p
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 FOLL
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
---
drivers/plat
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
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 acc
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 functi
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: b9d3d01405061bb42358fe53f
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 put_
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 i
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 ca
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 +++---
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
vfio_iommu_type1.c:
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
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 set_page_
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 releasi
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 pin_u
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 e
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 addit
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 valid
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 whole
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 alre
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 = 0xc0
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 g
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. swiotlb
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 op
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 spec
58 matches
Mail list logo
