Hi,
OK, here is v7, maybe this is the last one. The corresponding git repo
and branch is:
g...@github.com:johnhubbard/linux.git pin_user_pages_tracking_v7
Ira, you reviewed the gup_benchmark patches a bit earlier, but I
removed one or two of those review-by tags, due to invasive changes
I
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via put_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
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
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"
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new
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
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
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
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Also placate checkpatch.pl by shortening a nearby line.
Reviewed-by: Jan Kara
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Cc: Kirill A. Shutemov
Signed-off-by: John
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
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
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
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
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
---
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
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
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
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: Jan Kara
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
mm/gup.c | 29 +++--
1 file changed, 15
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
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
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_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
---
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
Christophe Leroy writes:
> call_do_irq() and call_do_softirq() are quite similar on PPC32 and
> PPC64 and are simple enough to be worth inlining.
>
> Inlining them avoids an mflr/mtlr pair plus a save/reload on stack.
>
> This is inspired from S390 arch. Several other arches do more or
> less
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> The current process for configuring the IODA PEs for normal PCI devices is
> abit stupid.
This phrase should go.
> After assigning MMIO resources for the devices on a bus the
> actual PE asignment occurs when pcibios_setup_bridge() is called
On Thu, Nov 21, 2019 at 2:38 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > 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
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 time the device is
> added the bus.
Yeah it would be nice if dma
On Thu, Nov 21, 2019 at 3:02 PM Alexey Kardashevskiy wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > These functions are only used from pci-ioda.c. Move them in there and remove
> > the prototypes from the header files.
>
>
> Make them static then, or am I missing the point?
I
Hi Dave,
On Thu, Nov 21, 2019 at 8:51 AM Dave Young wrote:
>
> On 11/11/19 at 01:31pm, Bhupesh Sharma wrote:
> > Changes since v3:
> >
> > - v3 can be seen here:
> > http://lists.infradead.org/pipermail/kexec/2019-March/022590.html
> > - Addressed comments from James and
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> 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
Reviewed-by:
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> These functions are only used from pci-ioda.c. Move them in there and remove
> the prototypes from the header files.
Make them static then, or am I missing the point?
With that fixed,
Reviewed-by: Alexey Kardashevskiy
Also, pci-ioda.c is
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> 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
>
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> 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
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> 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
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Fix also 7-space and tab+1 space indentation issues.
---
arch/powerpc/Kconfig.debug
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Fix also 7-space and tab+1 space indentation issues.
---
drivers/tty/Kconfig
Christophe Leroy writes:
> Michael Ellerman a écrit :
>> Christophe Leroy writes:
>>> This is copied and adapted from commit 5c929885f1bb ("powerpc/vdso64:
>>> Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
>>> from Santosh Sivaraj
>>>
>>> Benchmark from vdsotest-all:
>>>
On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote:
[...]
> --- a/arch/powerpc/kernel/vdso32/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
> @@ -15,10 +15,8 @@
> /* Offset for the low 32-bit part of a field of long type */
> #if defined(CONFIG_PPC64) &&
On Wed, 2019-11-20 at 20:35 +0100, Arnd Bergmann wrote:
> On Wed, Nov 20, 2019 at 8:13 PM Ben Hutchings
> wrote:
> > On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann wrote:
> > > On little-endian 32-bit application running on 64-bit kernels,
> > > the current vdso would read the wrong half of the
On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann wrote:
> On little-endian 32-bit application running on 64-bit kernels,
> the current vdso would read the wrong half of the xtime seconds
> field. Change it to return the lower half like it does on
> big-endian.
ppc64le doesn't have 32-bit compat
On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote:
[...]
> --- a/arch/x86/include/uapi/asm/sembuf.h
> +++ b/arch/x86/include/uapi/asm/sembuf.h
> @@ -21,9 +21,9 @@ struct semid64_ds {
> unsigned long sem_ctime; /* last change time */
> unsigned long sem_ctime_high;
>
On 11/18/19 9:53 PM, Michael Ellerman wrote:
> Chen Wandun writes:
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> arch/powerpc/platforms/pseries/ras.c: In function ras_epow_interrupt:
>> arch/powerpc/platforms/pseries/ras.c:319:6: warning: variable status set but
>> not used
On 11/14/19 10:43 AM, Erhard Furtner wrote:
> In attach_node_and_children memory is allocated for full_name via
> kasprintf. If the condition of the 1st if is not met the function
> returns early without freeing the memory. Add a kfree() to fix that.
>
> Signed-off-by: Erhard Furtner
Michael
From: Juliet Kim
Date: Wed, 20 Nov 2019 10:50:02 -0500
> This series aims to support both XICS and XIVE with avoiding
> a regression in behavior when a system runs in XICS mode.
>
> Patch 1 reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
> (“net/ibmvnic: Fix EOI when running in XIVE
> On Nov 13, 2019, at 10:46 AM, Greg Kurz wrote:
>
> The EQ page is allocated by the guest and then passed to the hypervisor
> with the H_INT_SET_QUEUE_CONFIG hcall. A reference is taken on the page
> before handing it over to the HW. This reference is dropped either when
> the guest issues
Hi Rasmus,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[cannot apply to v5.4-rc8 next-20191120]
[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
On Wed, Nov 20, 2019 at 8:13 PM Ben Hutchings
wrote:
>
> On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann wrote:
> > On little-endian 32-bit application running on 64-bit kernels,
> > the current vdso would read the wrong half of the xtime seconds
> > field. Change it to return the lower half
this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
next/master bisection: boot on peach-pi
Summary:
Start: 1fef9976397f Add linux-next specific files for 20191120
Details:https://kernelci.org/boot/id/5dd5175059b514
On Fri, Nov 15, 2019 at 05:32:03PM +0800, Jason Yan wrote:
> This is a try to implement KASLR for Freescale BookE64 which is based on
> my earlier implementation for Freescale BookE32:
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718
Whee! :) I've updated
On Mon, Nov 18, 2019 at 5:29 AM Rasmus Villemoes
wrote:
Hi Scott,
What do you think of the PowerPC related changes(patch 13,14)? Can we
have you ACK and merge the series from soc tree?
Regards,
Leo
>
> This is now exactly the same as mpc83xx_ipic_init_IRQ, so just use
> that directly.
>
>
On Mon, Nov 18, 2019 at 5:26 AM Rasmus Villemoes
wrote:
>
Hi David,
What do you think about the patch 45-47 from the series for net
related changes? If it is ok with you, I can merge them with the
whole series through the soc tree with your ACK.
Regards,
Leo
> When releasing the allocated
> On Nov 13, 2019, at 10:46 AM, Greg Kurz wrote:
>
> The EQ page is allocated by the guest and then passed to the hypervisor
> with the H_INT_SET_QUEUE_CONFIG hcall. A reference is taken on the page
> before handing it over to the HW. This reference is dropped either when
> the guest issues
This reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(???net/ibmvnic: Fix EOI when running in XIVE mode.???) since that
has the unintended effect of changing the interrupt priority
and emits warning when running in legacy XICS mode.
Signed-off-by: Juliet Kim
---
Reversion of commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(???net/ibmvnic: Fix EOI when running in XIVE mode.???) leaves us
calling H_EOI even in XIVE mode. That will fail with H_FUNCTION
because H_EOI is not supported in that mode. That failure is
harmless. Ignore it so we can use common code
This series aims to support both XICS and XIVE with avoiding
a regression in behavior when a system runs in XICS mode.
Patch 1 Reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(???net/ibmvnic: Fix EOI when running in XIVE mode.???)
Patch 2 Ignore H_FUNCTION return from H_EOI to tolerate
This reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(???net/ibmvnic: Fix EOI when running in XIVE mode.???) since that
has the unintended effect of changing the interrupt priority
and emits warning when running in legacy XICS mode.
Signed-off-by: Juliet Kim
---
Reversion of commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(???net/ibmvnic: Fix EOI when running in XIVE mode.???) leaves us
calling H_EOI even in XIVE mode. That will fail with H_FUNCTION
because H_EOI is not supported in that mode. That failure is
harmless. Ignore it so we can use common code
This series aims to support both XICS and XIVE with avoiding
a regression in behavior when a system runs in XICS mode.
Patch 1 reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab
(???net/ibmvnic: Fix EOI when running in XIVE mode.???)
Patch 2 Ignore H_FUNCTION return from H_EOI to tolerate
Michael Ellerman a écrit :
Christophe Leroy writes:
This is copied and adapted from commit 5c929885f1bb ("powerpc/vdso64:
Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
from Santosh Sivaraj
Benchmark from vdsotest-all:
clock-gettime-realtime: syscall: 3601 nsec/call
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/macintosh/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/soc/fsl/Kconfig | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/tty/Kconfig | 26 -
drivers/tty/hvc/Kconfig | 4 +-
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
arch/powerpc/Kconfig.debug | 18 +-
arch/powerpc/platforms/Kconfig.cputype | 2
Christophe Leroy writes:
> This is copied and adapted from commit 5c929885f1bb ("powerpc/vdso64:
> Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
> from Santosh Sivaraj
>
> Benchmark from vdsotest-all:
> clock-gettime-realtime: syscall: 3601 nsec/call
> clock-gettime-realtime:libc: 1072
In the vmx crypto Makefile we assign to a variable called TARGET and
pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts.
The variable is meant to describe what flavour of powerpc we're
building for, eg. either 32 or 64-bit, and big or little endian.
Unfortunately TARGET is a fairly common
On Tue, Nov 19, 2019 at 05:41:58PM +, Robin Murphy wrote:
> Is that a problem though? It's not safe in general to rewrite the default
> domain willy-nilly,
Well. Can you look at what intel-iommu does right now so that we can
sort that out first?
> so if it's a concern that drivers get
Thanks.
Marek Szyprowski already reported the issue and a fix is in the works.
On 14.11.19 10:08, Michael Ellerman wrote:
On Thu, 2019-10-31 at 14:29:22 UTC, David Hildenbrand wrote:
When unloading the module, one gets
[ 548.188594] [ cut here ]
[ 548.188596] Device 'cmm0' does not have a release() function, it is brok=
en and must be fixed. See
67 matches
Mail list logo
