flight 139762 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139762/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
The blank line between it and the prior if() clearly indicates that this
was meant to be a standalone if().
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -166,8 +166,8 @@ static int __init
On Tue, Aug 06, 2019 at 03:17:26PM +0200, Dario Faggioli wrote:
> On Tue, 2019-08-06 at 11:12 +0100, Anthony PERARD wrote:
> > with those two I could build a qemu in the tumbleweed container, but
> > there are maybe other commit missing.
> >
> You mean the build is still failing for you, but not
On Mon, Aug 05, 2019 at 01:42:58PM +0100, Andrew Cooper wrote:
> There is nothing interesting for assembly code in msr.h
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
If those are the only assembly files including msr.h, could you also
get rid of the assembly guard in msr.h?
On 06/08/2019 15:39, Roger Pau Monné wrote:
> On Mon, Aug 05, 2019 at 01:42:58PM +0100, Andrew Cooper wrote:
>> There is nothing interesting for assembly code in msr.h
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
>
> If those are the only assembly files including msr.h,
On 06.08.2019 17:16, Roger Pau Monné wrote:
On Tue, Aug 06, 2019 at 04:47:28PM +0200, Jan Beulich wrote:
On 06.08.2019 16:25, Roger Pau Monné wrote:
On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
@@ -350,6 +353,10 @@ static struct pci_dev *ºalloc_pdev(struct
On 06.08.2019 16:51, Roger Pau Monné wrote:
On Mon, Aug 05, 2019 at 01:43:00PM +0100, Andrew Cooper wrote:
The current names, boot_cpu_{,compat_}gdt_table, have a table suffix which is
redundant with the T of GDT, and the cpu infix doesn't provide any meaningful
context. Drop them both.
Only the first patch here is left from v4, everything else is new,
yet still related. The main goal is to reduce the huge memory
overhead that we've noticed. On the way there a number of other
things were once again noticed. Unfortunately before I was able to
also test the last two patches there,
Current code calls apic_x2apic_probe which does some initialization
and setup before having enabled x2APIC mode (if it's not already
enabled by the firmware).
This can lead to issues if the APIC ID doesn't match the x2APIC ID, as
apic_x2apic_probe calls init_apic_ldr_x2apic_cluster which
On Tue, 2019-08-06 at 11:12 +0100, Anthony PERARD wrote:
> On Mon, Aug 05, 2019 at 11:44:11AM +0200, Dario Faggioli wrote:
> > Anyway, it seems that, in addition to the one I mentioned to
> > Anthony a
> > few days ago, we also miss this from upstream?
> >
> > commit
On Tue, Aug 06, 2019 at 02:43:49PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 06, 2019 at 02:05:48PM +0200, Jan Beulich wrote:
> > On 06.08.2019 12:53, Marek Marczykowski-Górecki wrote:
> > > On Tue, Aug 06, 2019 at 12:33:39PM +0200, Jan Beulich wrote:
> > > > On 06.08.2019 11:46,
On 06.08.2019 15:13, Roger Pau Monne wrote:
Current code calls apic_x2apic_probe which does some initialization
and setup before having enabled x2APIC mode (if it's not already
enabled by the firmware).
This can lead to issues if the APIC ID doesn't match the x2APIC ID, as
apic_x2apic_probe
On 06.08.2019 16:25, Roger Pau Monné wrote:
On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
@@ -1093,22 +1094,17 @@ static void __pci_disable_msi(struct msi
**/
static int __pci_enable_msix(struct msi_info *msi, struct msi_desc **desc)
{
-int pos, nr_entries;
On Mon, Aug 05, 2019 at 01:43:00PM +0100, Andrew Cooper wrote:
> The current names, boot_cpu_{,compat_}gdt_table, have a table suffix which is
> redundant with the T of GDT, and the cpu infix doesn't provide any meaningful
> context. Drop them both.
>
> Likewise, shorten the {,compat_}gdt{,_l1e}
Rather than doing this every time we set up interrupts for a device
anew (and then in two distinct places) fill this invariant field
right after allocating struct arch_msix.
While at it also obtain the MSI-X capability structure position just
once, in msix_capability_init(), rather than in each
Prepare for the number of entries to not be the maximum possible, by
separating checks against maximum size from ones against actual size.
For caller side simplicity have alloc_intremap_entry() return the
maximum possible value upon allocation failure, rather than the first
just out-of-bounds
On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
> Rather than doing this every time we set up interrupts for a device
> anew (and then in two distinct places) fill this invariant field
> right after allocating struct arch_msix.
>
> While at it also obtain the MSI-X capability
On 06.08.2019 16:39, Roger Pau Monné wrote:
On Mon, Aug 05, 2019 at 01:42:58PM +0100, Andrew Cooper wrote:
There is nothing interesting for assembly code in msr.h
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
On Tue, Aug 06, 2019 at 04:47:28PM +0200, Jan Beulich wrote:
> On 06.08.2019 16:25, Roger Pau Monné wrote:
> > On Tue, Aug 06, 2019 at 03:10:40PM +0200, Jan Beulich wrote:
> > > --- a/xen/drivers/passthrough/pci.c
> > > +++ b/xen/drivers/passthrough/pci.c
> > > @@ -324,6 +324,7 @@ static void
Calling amd_iommu_free_intremap_table() for every IVRS entry is correct
only in per-device-IRT mode. Use a NULL 2nd argument to indicate that
the shared table should be freed, and call the function exactly once in
shared mode.
Signed-off-by: Jan Beulich
---
v5: New.
---
First and foremost switch boolean fields to bool. Adjust a few related
function parameters as well. Then
- in amd_iommu_set_intremap_table() don't use literal numbers,
- in iommu_dte_add_device_entry() use a compound literal instead of many
assignments,
- in amd_iommu_setup_domain_device()
-
Hi Viktor,
Viktor Mitin writes:
> Extend fdt_property_interrupts to deal with other domain than the hwdom.
>
> The prototype of fdt_property_interrupts() has been modified
> to support both hwdom and domU in one function.
>
> This is a preparatory for the next patch which consolidates
>
On Mon, Aug 05, 2019 at 01:43:01PM +0100, Andrew Cooper wrote:
> ... where we can at least get the compiler to fill in the surrounding space
> without having to do it manually. This also reults in the symbols having
> proper type/size information in the debug symbols.
>
> Reorder 'raw' in the
There's no point setting up tables with more space than a PCI device can
use. For both MSI and MSI-X we can determine how many interrupts could
be set up at most. Tables allocated during ACPI table parsing, however,
will (for now at least) continue to be set up to have maximum size.
Note that
On 06.08.2019 14:43, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2019 at 02:05:48PM +0200, Jan Beulich wrote:
On 06.08.2019 12:53, Marek Marczykowski-Górecki wrote:
On Tue, Aug 06, 2019 at 12:33:39PM +0200, Jan Beulich wrote:
On 06.08.2019 11:46, Marek Marczykowski-Górecki wrote:
On
flight 139765 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139765/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
Hi Viktor,
Viktor Mitin writes:
> Functions make_timer_node and make_timer_domU_node are quite similar.
> So it is better to consolidate them to avoid discrepancy.
> The main difference between the functions is the timer interrupts used.
>
> Keep the domU version for the compatible as it is
Rather than duplicating entries in amd_iommu_msi_msg_update_ire(), share
the tables. This mainly requires some care while freeing them, to avoid
freeing memory blocks twice.
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++
ACPI tables are free to list far more device coordinates than there are
actual devices. By delaying the table allocations for most cases, and
doing them only when an actual device is known to be present at a given
position, overall memory used for the tables goes down from over 500k
pages to just
Hello Dario,
Please see my comments below:
On 03.08.19 03:55, Dario Faggioli wrote:
On Fri, 2019-08-02 at 16:07 +0300, Andrii Anisov wrote:
On 02.08.19 12:15, Julien Grall wrote:
From the list below it is not clear what is the split between
hypervisor time and guest time. See some of the
For us to no longer blindly allocate interrupt remapping tables for
everything the ACPI tables name, we can't use struct ivrs_mappings'
intremap_table field anymore to also have the meaning of "this entry
is valid". Add a separate boolean field instead.
Signed-off-by: Jan Beulich
---
v5: New.
Additional users of the function will want to handle errors more
gracefully. Remove the BUG_ON()s and make the current caller panic()
instead.
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -86,6 +86,10
On 8/5/19 11:57 AM, Ian Jackson wrote:
> Hi. Thanks for looking into this. Sorry about the delay to the
> review. I found it, unsent, while recovering a crashed mailreader
> session...
Thanks for the review -- I was going to come back and ping this at some
point; it would be nice to have it in
On 05.08.2019 14:42, Andrew Cooper wrote:
Split up the long asm block by commenting the logical subsections.
The movabs for obtaining __start_xen can be a rip-relative lea instead. This
has the added advantage that objdump can now cross reference it during
disassembly.
I'm surprised this
On 8/5/19 4:38 AM, Julien Grall wrote:
> CAUTION: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
> Hi,
>
> I have CCed one person from Donerworks. IIRC they have been using the
flight 139770 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139770/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hello,
With the embargo up, you'll surely all be pleased to see that this is
not a zeroday XSA.
https://www.bitdefender.com/SWAPGSAttack
There are two issues here.
1) Spectre attacks against SWAPGS in interrupt/exception handlers
This has been assigned CVE-2019-1125 and affects all 64bit
flight 139740 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139740/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 139714
On 05.08.2019 14:43, Andrew Cooper wrote:
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -43,44 +43,11 @@ ENTRY(__high_start)
multiboot_ptr:
.long 0
-.word 0
-GLOBAL(boot_gdtr)
-.word LAST_RESERVED_GDT_BYTE
-.quad boot_gdt -
On Sun, Aug 04, 2019 at 03:48:42PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Provide a more capable variation of put_user_pages_dirty_lock(),
> and delete put_user_pages_dirty(). This is based on the
> following:
>
> 1. Lots of call sites become simpler if a bool is passed
>
On 30.07.2019 15:44, Paul Durrant wrote:
This function is only ever called from within the same source module and
really has no business being declared xen/iommu.h. This patch relocates
the function ahead of the first called and makes it static.
Signed-off-by: Paul Durrant
Acked-by: Jan
Add 9pfs to the kind of PV drivers that has a QEMU backend, specifically
to the macro QEMU_BACKEND.
This is needed otherwise upon domain destroy we get a timeout error:
libxl: error: libxl_device.c:1132:device_backend_callback: Domain 1:unable to
remove device with path
On Thu, Jul 25, 2019 at 01:33:50PM +, Jan Beulich wrote:
> First and foremost switch boolean fields to bool. Adjust a few related
> function parameters as well. Then
> - in amd_iommu_set_intremap_table() don't use literal numbers,
> - in iommu_dte_add_device_entry() use a compound literal
flight 139751 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139751/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 76e40d7be239893dbf9844515392779c3ab2fba0
baseline version:
ovmf
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
>
> On 7/8/19 8:02 PM, Oleksandr wrote:
> > On 22.06.19 02:56, Stefano Stabellini wrote:
> > I have tested this series and got the same behavior as with V2 [1].
> >
> > The "non-reserved-memory" node in my device-tree
> >
On 05.08.19 13:02, Jan Beulich wrote:
Hi, Jan
While I can see why having a re-allocation function may be handy,
explicit / direct use of _xmalloc() and _xzalloc() are discouraged,
in favor of the more type-safe underscore-less variants.
took into account
I can't
see though how a
On Tue, 9 Jul 2019, Oleksandr wrote:
>
> On 22.06.19 02:56, Stefano Stabellini wrote:
>
> Hi, Stefano
>
> > Don't allow reserved-memory regions to be remapped into any guests,
> > until reserved-memory regions are properly supported in Xen. For now,
> > do not call iomem_permit_access for them.
Hi Jan,
Jan Beulich writes:
> On 02.08.2019 18:39, Oleksandr Tyshchenko wrote:
>> --- a/xen/common/xmalloc_tlsf.c
>> +++ b/xen/common/xmalloc_tlsf.c
>> @@ -610,6 +610,27 @@ void *_xzalloc(unsigned long size, unsigned long align)
>> return p ? memset(p, 0, size) : p;
>> }
>>
>> +void
On Tue, Aug 06, 2019 at 03:07:48PM +0200, Jan Beulich wrote:
> First and foremost switch boolean fields to bool. Adjust a few related
> function parameters as well. Then
> - in amd_iommu_set_intremap_table() don't use literal numbers,
> - in iommu_dte_add_device_entry() use a compound literal
On Mon, Aug 05, 2019 at 05:44:30PM +0100, Andy Cooper wrote:
> Since c/s 9fa94e10585 "x86/ACPI: also parse AMD IOMMU tables early", this
> function is unconditionally called in all cases where a DMAR ACPI table
> doesn't exist.
>
> As a consequnce, "AMD-Vi: IOMMU not found!" is printed in all
flight 139743 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139743/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13
On 8/6/19 10:39 AM, Ira Weiny wrote:
> On Sun, Aug 04, 2019 at 03:48:42PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
...
>> -
>> /**
>> - * put_user_pages_dirty() - release and dirty an array of gup-pinned pages
>> - * @pages: array of pages to be marked dirty and released.
>> +
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
>
> On 6/22/19 12:56 AM, Stefano Stabellini wrote:
> > As we parse the device tree in Xen, keep track of the reserved-memory
> > regions as they need special treatment (follow-up patches will make use
> > of the stored information.)
> >
> > Reuse
Hi Nate , Hi Julien,
>
> Amit,
>
> Have you checked out the NXP Xen fork?
>
> https://source.codeaurora.org/external/imx/imx-xen/
>
> While the work there hasn't been upstreamed yet, the support for the
> iMX8QM
> (QuadMax) is fairly complete. There are some important
flight 139756 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139756/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139688
Tests which did
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win10-i386
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
Hi
>
> What are the consequences to change the interrupt parent?
I am not entirely sure about it at the moment but looks like it
controllers power domain
for various devices like GPU, VPU and OTG etc.
So, we may not be able to support these devices for XEN domains ?
Also, this IP is not
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/22/19 12:56 AM, Stefano Stabellini wrote:
> > Reserved memory regions are automatically remapped to dom0. Their device
> > tree nodes are also added to dom0 device tree. However, the dom0 memory
> > node is not currently extended to
Add new parameters to device_tree_for_each_node: node, depth,
address_cells, size_cells.
Node is the parent node to start the search from;
depth is the min depth of the search (the depth of the parent node);
address_cells and size_cells are the respective parameters at the parent
node. Passing 0,
Hi all,
This patch series introduces partial reserved-memory support for dom0
only (no domU support for reserved-memory yet.)
The following changes since commit 45ce5b8749a220ad7c4ce5d5eba7c201a9418078:
mm: Safe to clear PGC_allocated on xenheap pages without an extra reference
(2019-08-06
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
bootinfo.reserved_mem array.
Refuse to continue once we reach
Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- new patch
---
xen/arch/arm/bootfdt.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Return error if there is no reg property, remove printk.
Return error
On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné wrote:
>
> On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
> > On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
> > > This patch completely fixes the problem for me!
> > >
> > > Thanks Roger! I'd love to see this in
reserved-memory regions overlap with memory nodes. The overlapping
memory is reserved-memory and should be handled accordingly:
consider_modules and dt_unreserved_regions should skip these regions the
same way they are already skipping mem-reserve regions.
Signed-off-by: Stefano Stabellini
Don't allow reserved-memory regions to be remapped into any guests,
until reserved-memory regions are properly supported in Xen. For now,
do not call iomem_permit_access for them.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- compare the parent name with reserved-memory
- use
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by the spec. This commit fixes it.
Change make_memory_node to
On Wed, 19 Jun 2019, Jan Beulich wrote:
> >>> On 19.06.19 at 01:20, wrote:
> > Add a p2mt parameter to map_mmio_regions, pass p2m_mmio_direct_dev on
> > ARM and p2m_mmio_direct on x86 -- no changes in behavior. On x86,
> > introduce a macro to strip away the last parameter and rename the
> >
Commit 4941bfbf11eae05c92aa3242e353d173974ce7bf "xen/arm64: macros:
Introduce an assembly macro to alias x30" moved
lr .reqx30
to macros.h, and started to use "lr" in head.S. However, it didn't add
an #include macros.h to head.S. This commit fixes it.
Signed-off-by: Stefano
flight 139753 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Introduce a new libxc function that makes use of the new memory_policy
parameter added to the XEN_DOMCTL_memory_mapping hypercall.
The parameter values are the same for the XEN_DOMCTL_memory_mapping
hypercall (0 is MEMORY_POLICY_DEFAULT). Pass MEMORY_POLICY_DEFAULT by
default -- no changes in
Add a p2mt parameter to map_mmio_regions, pass p2m_mmio_direct_dev on
ARM and p2m_mmio_direct on x86 -- no changes in behavior.
On x86, introduce a macro to strip away the last parameter and rename
the existing implementation of map_mmio_regions to map_mmio_region.
Use map_mmio_region in vpci as
Hi all,
This series introduces a memory policy parameter for the iomem option,
so that we can map an iomem region into a guest as cacheable memory.
(Other things related to reserved-memory on Arm have been sent
separately.)
Cheers,
Stefano
The following changes since commit
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi Stefano,
>
> The Arm code looks good to me. One comment below.
Should I take it as a acked-by?
> On 6/19/19 12:20 AM, Stefano Stabellini wrote:
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index e28ea1c85a..d88df11e09 100644
> > ---
On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
>
> On 6/19/19 12:20 AM, Stefano Stabellini wrote:
> > Reuse the existing padding field to pass memory policy information. On
> > Arm, the caller can specify whether the memory should be mapped as
> > Device-nGnRE (Device Memory on Armv7) at stage-2,
On Wed, 19 Jun 2019, Jan Beulich wrote:
> >>> On 19.06.19 at 01:20, wrote:
> > --- a/tools/libxc/xc_domain.c
> > +++ b/tools/libxc/xc_domain.c
> > @@ -2070,6 +2070,7 @@ int xc_domain_memory_mapping(
> > domctl.cmd = XEN_DOMCTL_memory_mapping;
> > domctl.domain = domid;
> >
Add a new memory policy option for the iomem parameter.
Possible values are:
- arm_dev_nGnRE, Device-nGnRE, the default on Arm
- arm_mem_WB, WB cachable memory
- default
Store the parameter in a new field in libxl_iomem_range.
Pass the memory policy option to xc_domain_mem_map_policy.
Do the
Reuse the existing padding field to pass memory policy information. On
Arm, the caller can specify whether the memory should be mapped as
Device-nGnRE (Device Memory on Armv7) at stage-2, which is the default
and the only possibility today, or cacheable memory write-back. The
resulting memory
iomem settings fall under the broader category of "Non-PCI device
passthrough": they are not security supported. Make it clearer.
Signed-off-by: Stefano Stabellini
CC: t...@xen.org
CC: konrad.w...@oracle.com
CC: Julien Grall
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC:
Add a p2m_is_mmio macro for easy checkings.
Signed-off-by: Stefano Stabellini
---
xen/include/asm-arm/p2m.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 03f2ee75c1..31902317da 100644
--- a/xen/include/asm-arm/p2m.h
+++
From: John Hubbard
Provide a more capable variation of put_user_pages_dirty_lock(),
and delete put_user_pages_dirty(). This is based on the
following:
1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page*()
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Cc:
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
Hi,
This consolidates everything into a "here's what's remaining for Andrew
to add to his tree (for now)" series:
* The first patch is an updated version of one that is already in the akpm tree.
* The next two patches are already in the akpm tree, included here for
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
1 - 100 of 143 matches
Mail list logo
