flight 172943 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172943/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172946 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172946/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172940 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172940/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
+Roberto
I think we need Roberto's advice on Rule 20.7. (Full thread below.)
The question is on the interpretation of Rule 20.7. Are parenthesis
required by Rule 20.7 in the following cases:
- macro parameters used as function arguments
- macro parameters used as macro arguments
- macro
On Thu, 1 Sep 2022, Rahul Singh wrote:
> Replace is_memory_hole call to pci_check_bar as function should check
> if device BAR is in defined memory range. Also, add an implementation
> for ARM which is required for PCI passthrough.
>
> On x86, pci_check_bar will call is_memory_hole which will
On Fri, 2 Sep 2022, Michal Orzel wrote:
> Add a new test job qemu-smoke-arm64-gcc-boot-cpupools that will execute
> script qemu-smoke-arm64.sh to test boot time cpupools feature.
> Enable CONFIG_BOOT_TIME_CPUPOOLS for the arm64 build and add a new test
> case in qemu-smoke-arm64.sh that if
flight 172944 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
I checked all the patches against the originals.
I had comments on patches 3,4,5.
You can add:
Acked-by: Stefano Stabellini
to all the others (1,2,6,7,8,9,10).
On Fri, 2 Sep 2022, Rahul Singh wrote:
> This patch series merge the applicable Linux fixes to Xen.
>
> Bixuan Cui (1):
>
On Fri, 2 Sep 2022, Rahul Singh wrote:
> From: Jean-Philippe Brucker
>
> Backport Linux commit e881e7839fba. This is the clean backport without
> any changes.
I don't think we can say that this is a clean backport because there are
differences between the two patches.
That said, it is just
On Fri, 2 Sep 2022, Rahul Singh wrote:
> From: Zhou Wang
>
> Backport Linux commit a76a3f2c. This is the clean backport without
> any changes.
>
> Reading the 'prod' MMIO register in order to determine whether or
> not there is valid data beyond 'cons' for a given queue does not
> provide
On Fri, 2 Sep 2022, Rahul Singh wrote:
> From: Robin Murphy
>
> Backport Linux commit 86d2d9214880. This is the clean backport without
> any changes.
>
> Since we now keep track of page 1 via a separate pointer that
> already encapsulates aliasing to page 0 as necessary, we can remove
> the
flight 172937 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172937/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
On 9/2/22 2:05 PM, Kent Overstreet wrote:
> On Fri, Sep 02, 2022 at 01:53:53PM -0600, Jens Axboe wrote:
>> I've complained about memcg accounting before, the slowness of it is why
>> io_uring works around it by caching. Anything we account we try NOT do
>> in the fast path because of it, the
On Fri, Sep 02, 2022 at 01:53:53PM -0600, Jens Axboe wrote:
> I've complained about memcg accounting before, the slowness of it is why
> io_uring works around it by caching. Anything we account we try NOT do
> in the fast path because of it, the slowdown is considerable.
I'm with you on that, it
flight 172934 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
On 9/2/22 1:48 PM, Kent Overstreet wrote:
> On Fri, Sep 02, 2022 at 06:02:12AM -0600, Jens Axboe wrote:
>> On 9/1/22 7:04 PM, Roman Gushchin wrote:
>>> On Thu, Sep 01, 2022 at 08:17:47PM -0400, Kent Overstreet wrote:
On Thu, Sep 01, 2022 at 03:53:57PM -0700, Roman Gushchin wrote:
> I'd
flight 172942 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Fri, Sep 02, 2022 at 06:02:12AM -0600, Jens Axboe wrote:
> On 9/1/22 7:04 PM, Roman Gushchin wrote:
> > On Thu, Sep 01, 2022 at 08:17:47PM -0400, Kent Overstreet wrote:
> >> On Thu, Sep 01, 2022 at 03:53:57PM -0700, Roman Gushchin wrote:
> >>> I'd suggest to run something like iperf on a fast
On 9/2/22 05:07, Stefano Stabellini wrote:
On Thu, 1 Sep 2022, Bertrand Marquis wrote:
Hi Xenia,
On 1 Sep 2022, at 10:27, Xenia Ragiadakou wrote:
On 9/1/22 01:35, Stefano Stabellini wrote:
Patches 1, 4, and 6 are already committed. I plan to commit patches 2, 3
and 5 in the next couple
flight 172938 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172938/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
The conventional style for subject (from "git log --oneline") is:
xen/pcifront: Handle ...
On Mon, Aug 29, 2022 at 11:15:36AM -0400, Jason Andryuk wrote:
> An HVM guest with linux stubdom and 2 PCI devices failed to start as
"stubdom" might be handy shorthand in the Xen world, but I think
it
flight 172931 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172931/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
On 02/09/2022 16:54, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
On 2 Sep 2022, at 4:05 pm, Julien Grall wrote:
Hi Bertrand,
On 02/09/2022 15:51, Bertrand Marquis wrote:
On 1 Sep 2022, at 19:15, Julien Grall wrote:
AFAIU, it is not possible to have *_xenstore = true and *_enhanced =
Hi Julien,
> On 2 Sep 2022, at 4:05 pm, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 02/09/2022 15:51, Bertrand Marquis wrote:
>>> On 1 Sep 2022, at 19:15, Julien Grall wrote:
>>> AFAIU, it is not possible to have *_xenstore = true and *_enhanced = false.
>>> I think it would be clearer if
flight 172935 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hi Julien,
> On 1 Sep 2022, at 7:07 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 01/09/2022 10:13, Rahul Singh wrote:
>> Introduce a new sub-node under /chosen node to establish static event
>> channel communication between domains on dom0less systems.
>> An event channel will be created
Hi Bertrand,
On 02/09/2022 15:51, Bertrand Marquis wrote:
On 1 Sep 2022, at 19:15, Julien Grall wrote:
AFAIU, it is not possible to have *_xenstore = true and *_enhanced = false. I
think it would be clearer if ``dom0less_enhanced`` is turned to an enum with 3
values:
- None
-
Hi Julien,
> On 1 Sep 2022, at 7:15 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 01/09/2022 10:13, Rahul Singh wrote:
>> Introduce a new "xen,enhanced" dom0less property value "no-xenstore" to
>> disable xenstore interface for dom0less guests.
>> Signed-off-by: Rahul Singh
>> ---
>> Changes
Hi Julien,
> On 1 Sep 2022, at 19:15, Julien Grall wrote:
>
> Hi Rahul,
>
> On 01/09/2022 10:13, Rahul Singh wrote:
>> Introduce a new "xen,enhanced" dom0less property value "no-xenstore" to
>> disable xenstore interface for dom0less guests.
>> Signed-off-by: Rahul Singh
>> ---
>> Changes in
On 02/09/22 01:08PM, Juergen Gross wrote:
> On 02.09.22 11:53, Pratyush Yadav wrote:
> > On 31/08/22 04:58PM, SeongJae Park wrote:
> > > The advertisement of the persistent grants feature (writing
> > > 'feature-persistent' to xenbus) should mean not the decision for using
> > > the feature but
From: Christophe JAILLET
Backport Linux commit 98b64741d611. This is the clean backport without
any changes
kmalloc_array()/kcalloc() should be used to avoid potential overflow
when a multiplication is needed to compute the size of the requested
memory.
So turn a devm_kzalloc()+explicit size
From: Jean-Philippe Brucker
Backport Linux commit e881e7839fba. This is the clean backport without
any changes.
Allow sharing structure definitions with the upcoming SVA support for
Arm SMMUv3, by moving them to a separate header. We could surgically
extract only what is needed but keeping all
From: Bixuan Cui
Backport Linux commit d56d5162e317. This is the clean backport without
any changes.
Fix checkpatch warning in arm-smmu-v3.c:
static const char * array should probably be static const char
* const
Signed-off-by: Bixuan Cui
Signed-off-by: Will Deacon
Origin:
From: "Gustavo A. R. Silva"
Backport Linux commit 5a1ab5c0299a. This is the clean backport without
any changes.
Fix the following fallthrough warning (arm64-randconfig with Clang):
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:382:2: warning: unannotated
fall-through between switch labels
From: Zhen Lei
Backport Linux commit affa909571b0. This is the clean backport without
any changes.
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Remove it can help us save a bit of memory.
Signed-off-by: Zhen Lei
Link:
From: Zenghui Yu
Backport Linux commit e0bb4b735404. This is the clean backport without
any changes.
Per SMMUv3 spec, there is no Size and Addr field in the
PREFETCH_CONFIG command and they're not used by the driver.
Remove them.
We can add them back if we're going to use PREFETCH_ADDR in the
From: Robin Murphy
Backport Linux commit 86d2d9214880. This is the clean backport without
any changes.
Since we now keep track of page 1 via a separate pointer that
already encapsulates aliasing to page 0 as necessary, we can remove
the clunky fixup routine and simply use the relevant bases
From: Zhou Wang
Backport Linux commit a76a3f2c. This is the clean backport without
any changes.
Reading the 'prod' MMIO register in order to determine whether or
not there is valid data beyond 'cons' for a given queue does not
provide sufficient dependency ordering, as the resulting access
From: Jean-Philippe Brucker
Backport Linux commit 376cdf66f624. This is the clean backport without
any changes.
When building with C=1, sparse reports some issues regarding
endianness annotations:
arm-smmu-v3.c:221:26: warning: cast to restricted __le64
arm-smmu-v3.c:221:24: warning: incorrect
From: Zenghui Yu
Backport Linux commit dc898eb84b25. This is the clean backport without
any changes.
The actual size of level-1 stream table is l1size. This looks like an
oversight on commit d2e88e7c081ef ("iommu/arm-smmu: Fix LOG2SIZE setting
for 2-level stream tables") which forgot to update
This patch series merge the applicable Linux fixes to Xen.
Bixuan Cui (1):
xen/arm: smmuv3: Change *array into *const array
Christophe JAILLET (1):
xen/arm: smmuv3: Avoid open coded arithmetic in memory allocation
Gustavo A. R. Silva (1):
xen/arm: smmuv3: Fix fall-through warning for
The important part is to include those buffers in IOMMU page table
relevant for the USB controller. Otherwise, DbC will stop working as
soon as IOMMU is enabled, regardless of to which domain device assigned
(be it xen or dom0).
If the device is passed through to dom0 or other domain (see later
All (interesting) data is in plain WB cached memory, and the few BAR
register that are configured have a UC mapping, which orders properly
WRT other writes on x86.
Suggested-by: Andrew Cooper
Signed-off-by: Marek Marczykowski-Górecki
---
New in v6
---
xen/drivers/char/xhci-dbc.c | 20
When cable is unplugged, dbc_ensure_running() correctly detects this
situation (DBC_CTRL_DCR flag is clear), and prevent sending data
immediately to the device. It gets only queued in work ring buffers.
When cable is plugged in again, subsequent dbc_flush() will send the
buffered data.
But there
That's possible, because the capability was designed specifically to
allow separate driver handle it, in parallel to unmodified xhci driver
(separate set of registers, pretending the port is "disconnected" for
the main xhci driver etc). It works with Linux dom0, although requires
an awful hack -
Add another work ring buffer for received data, and point IN TRB at it.
Ensure there is always at least one pending IN TRB, so the controller
has a way to send incoming data to the driver.
Note that both "success" and "short packet" completion codes are okay -
in fact it will be "short packet"
Re-use rmrr= parameter handling code to handle common device reserved
memory.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- make MAX_USER_RMRR_PAGES applicable only to user-configured RMRR
---
xen/drivers/passthrough/vtd/dmar.c | 201 +-
1 file
Add API similar to rmrr= and ivmd= arguments, but in a common code. This
will allow drivers to register reserved memory regardless of the IOMMU
vendor.
The direct reason for this API is xhci-dbc console driver (aka xue),
that needs to use DMA. But future change may unify command line
arguments for
Register common device reserved memory similar to how ivmd= parameter is
handled.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Jan Beulich
---
Changes in v3:
- use variable initializer
- use pfn_to_paddr()
---
xen/drivers/passthrough/amd/iommu_acpi.c | 21 +
1 file
This is integration of https://github.com/connojd/xue into mainline Xen.
This patch series includes several patches that I made in the process, some are
very loosely related.
The driver developed by Connor supports console via USB3 debug capability. The
capability is designed to operate mostly
Previously only one serial console was supported at the same time. Using
console=com1,dbgp,vga silently ignored all but last serial console (in
this case: only dbgp and vga were active).
Fix this by storing not a single sercon_handle, but an array of them, up
to MAX_SERCONS entries. The value of
This allows configuring EHCI and XHCI consoles separately,
simultaneously.
This changes string_param() to custom_param() in both ehci and xhci
drivers. Both drivers parse only values applicable to them.
While at it, drop unnecessary memset() of a static variable.
Suggested-by: Jan Beulich
flight 172928 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
On 9/1/22 7:04 PM, Roman Gushchin wrote:
> On Thu, Sep 01, 2022 at 08:17:47PM -0400, Kent Overstreet wrote:
>> On Thu, Sep 01, 2022 at 03:53:57PM -0700, Roman Gushchin wrote:
>>> I'd suggest to run something like iperf on a fast hardware. And maybe some
>>> io_uring stuff too. These are two places
> On 2 Sep 2022, at 08:09, Michal Orzel wrote:
>
> Add a new test job qemu-smoke-arm64-gcc-boot-cpupools that will execute
> script qemu-smoke-arm64.sh to test boot time cpupools feature.
> Enable CONFIG_BOOT_TIME_CPUPOOLS for the arm64 build and add a new test
> case in qemu-smoke-arm64.sh
> On 2 Sep 2022, at 08:09, Michal Orzel wrote:
>
> During the ping test, dom1 tries to assign an ip to eth0 in a loop.
> Before setting up the network interface by dom0, this results in
> printing the following error message several times:
> (XEN) DOM1: ifconfig: SIOCSIFADDR: No such device
>
> On 2 Sep 2022, at 08:09, Michal Orzel wrote:
>
> After qemu-smoke-arm64 was changed to use kernel 5.19 we end up having
> two kernel configurations. This is something not needed and maintaining
> a single kernel version is always easier. Modify qemu-alpine-arm64-gcc
> to use kernel 5.19 and
flight 172933 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172933/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Fri, Sep 02, 2022 at 09:53:22AM +, Pratyush Yadav wrote:
> On 31/08/22 04:58PM, SeongJae Park wrote:
> > The advertisement of the persistent grants feature (writing
> > 'feature-persistent' to xenbus) should mean not the decision for using
> > the feature but only the availability of the
On 02.09.22 11:53, Pratyush Yadav wrote:
On 31/08/22 04:58PM, SeongJae Park wrote:
The advertisement of the persistent grants feature (writing
'feature-persistent' to xenbus) should mean not the decision for using
the feature but only the availability of the feature. However, commit
On Wed, Aug 31, 2022 at 04:58:21PM +, SeongJae Park wrote:
> Changes from v1
> (https://lore.kernel.org/xen-devel/20220825161511.94922-1...@kernel.org/)
> - Fix the wrong feature_persistent caching position of blkfront
> - Set blkfront's feature_persistent field setting with simple '&&'
>
flight 172925 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172925/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1
On 31/08/22 04:58PM, SeongJae Park wrote:
> The advertisement of the persistent grants feature (writing
> 'feature-persistent' to xenbus) should mean not the decision for using
> the feature but only the availability of the feature. However, commit
> aac8a70db24b ("xen-blkback: add a parameter
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年9月2日 16:05
> To: Wei Chen ; Stefano Stabellini
>
> Cc: Henry Wang ; xen-devel@lists.xenproject.org;
> Bertrand Marquis ; Volodymyr Babchuk
>
> Subject: Re: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and
>
flight 172930 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Thu, Sep 1, 2022 at 11:58 AM SHARMA, JYOTIRMOY
wrote:
> [AMD Official Use Only - General]
>
> Hi all,
>
Hello Jyotirmoy.
[sorry for the possible format issues]
>
>
> Forgot to mention that I am able to play audio from HVM guest with Pulse
> Audio as back end.
>
good.
> Here is the
Hi Julien,
> -Original Message-
> Subject: Re: [PATCH 1/2] docs, xen/arm: Introduce reserved heap memory
>
> Hi Henry,
>
> On 02/09/2022 02:28, Henry Wang wrote:
> >> This is technically a change in behavior for Xen (we would panic rather
> >> than continue). I am happy with the
flight 172924 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
Hi Julien,
> -Original Message-
> From: Julien Grall
> > Thanks for the clarification. I checked the code and found the xenheap_*
> > variables are:
> > xenheap_virt_start, xenheap_virt_end, xenheap_mfn_start,
> > xenheap_mfn_end, xenheap_base_pdx.
> >
> > For clarification, do we need
Hi Stefano,
On 02/09/2022 03:20, Stefano Stabellini wrote:
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 430a1ef445..5579c875d2 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -82,6 +82,7 @@ struct dt_device_node {
Hi Penny,
On 02/09/2022 04:26, Penny Zheng wrote:
Do you think I shall further point out that right now, this part
feature is not implemented in codes?
I have made a couple of suggestion for the code. But I think the binding
would look a bit odd without the host physical address. We would now
On 02/09/2022 04:30, Henry Wang wrote:
Hi Julien,
Hi Henry,
-Original Message-
From: Julien Grall
This code is now becoming quite confusing to understanding. This loop is
meant to map the xenheap. If I follow your documentation, it would
mean
that only the reserved region
Hi Wei,
On 02/09/2022 04:07, Wei Chen wrote:
-Original Message-
From: Xen-devel On Behalf Of Wei
Chen
Sent: 2022年9月2日 11:03
To: Stefano Stabellini ; Julien Grall
Cc: Henry Wang ; xen-devel@lists.xenproject.org;
Bertrand Marquis ; Volodymyr Babchuk
Subject: RE: [PATCH 2/2] xen/arm:
Hi Henry,
On 02/09/2022 02:28, Henry Wang wrote:
This is technically a change in behavior for Xen (we would panic rather
than continue). I am happy with the proposal. However, this doesn't seem
to be explained in the commit message.
That said, I think this should be split in a separate patch
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Thursday, September 1, 2022 9:53 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Stefano Stabellini ;
> Wei Liu
> Subject: Re: [PATCH v11 6/6] xen:
Add a new test job qemu-smoke-arm64-gcc-boot-cpupools that will execute
script qemu-smoke-arm64.sh to test boot time cpupools feature.
Enable CONFIG_BOOT_TIME_CPUPOOLS for the arm64 build and add a new test
case in qemu-smoke-arm64.sh that if selected will:
- create a device tree cpupool node
During the ping test, dom1 tries to assign an ip to eth0 in a loop.
Before setting up the network interface by dom0, this results in
printing the following error message several times:
(XEN) DOM1: ifconfig: SIOCSIFADDR: No such device
Silence this by redirecting stderr/stdout to /dev/null as we
After qemu-smoke-arm64 was changed to use kernel 5.19 we end up having
two kernel configurations. This is something not needed and maintaining
a single kernel version is always easier. Modify qemu-alpine-arm64-gcc
to use kernel 5.19 and remove kernel 5.9 from tests-artifacts.
Signed-off-by:
This patch series performs a small cleanup before the release and adds
a test for validating boot time cpupools feature introduced in 4.17.
Notes for the release manager:
Benefits:
- improved dom0less test coverage
- tested feature that is introduced in 4.17
Risks:
- CI pipeline failure
On 01.09.22 17:35, Dan Carpenter wrote:
The change from kcalloc() to kvmalloc() means that arg->nr_pages
might now be large enough that the "args->nr_pages << PAGE_SHIFT" can
result in an integer overflow.
Fixes: b3f7931f5c61 ("xen/gntdev: switch from kcalloc() to kvcalloc()")
Signed-off-by:
81 matches
Mail list logo
