[PATCH] mm/balloon_compaction: suppress allocation warnings
There is no reason to print warnings when balloon page allocation fails,
as they are expected and can be handled gracefully. Since VMware
balloon now uses balloon-compaction infrastructure, and suppressed these
warnings before, it is also beneficial to suppress these warnings to
keep the same behavior that the balloon had before.
Cc: Jason Wang
Signed-off-by: Nadav Amit
---
mm/balloon_compaction.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index 798275a51887..26de020aae7b 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -124,7 +124,8 @@ EXPORT_SYMBOL_GPL(balloon_page_list_dequeue);
struct page *balloon_page_alloc(void)
{
struct page *page = alloc_page(balloon_mapping_gfp_mask() |
- __GFP_NOMEMALLOC | __GFP_NORETRY);
+ __GFP_NOMEMALLOC | __GFP_NORETRY |
+ __GFP_NOWARN);
return page;
}
EXPORT_SYMBOL_GPL(balloon_page_alloc);
--
2.19.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V5 4/5] iommu/dma-iommu: Use the dev->coherent_dma_mask
Looks good, and should probably be queued up asap as a bug fix: Reviewed-by: Christoph Hellwig ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V5 3/5] iommu/dma-iommu: Handle deferred devices
> +static int handle_deferred_device(struct device *dev, > + struct iommu_domain *domain) Nitick: we usually use double tab indents (or indents to after the opening brace) for multi-line prototyped. > + if (!is_kdump_kernel()) > + return 0; > + > + if (unlikely(ops->is_attach_deferred && > + ops->is_attach_deferred(domain, dev))) > + return iommu_attach_device(domain, dev); And for multi-line conditionals we also use two-tab indents. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V5 2/5] iommu: Add gfp parameter to iommu_ops::map
Looks good, Reviewed-by: Christoph Hellwig ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V5 1/5] iommu/amd: Remove unnecessary locking from AMD iommu driver
On Thu, Aug 15, 2019 at 12:09:39PM +0100, Tom Murphy wrote: > We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap. > iommu_map doesn’t lock while mapping and so no two calls should touch > the same iova range. The AMD driver already handles the page table page > allocations without locks so we can safely remove the locks. I've been looking over the code and trying to understand how the synchronization works. I gues we the cmpxchg64 in free_clear_pte is the important point here? I have to admit I don't fully understand the concurrency issues here, but neither do I understand what the mutex you removed might have helped to start with. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 10/11] vsock_test: skip read() in test_stream*close tests on a VMCI host
On Thu, Aug 01, 2019 at 05:25:40PM +0200, Stefano Garzarella wrote: > When VMCI transport is used, if the guest closes a connection, > all data is gone and EOF is returned, so we should skip the read > of data written by the peer before closing the connection. All transports should aim for identical semantics. I think virtio-vsock should behave the same as VMCI since userspace applications should be transport-independent. Let's view this as a vsock bug. Is it feasible to change the VMCI behavior so it's more like TCP sockets? If not, let's change the virtio-vsock behavior to be compatible with VMCI. signature.asc Description: PGP signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 11/11] vsock_test: wait for the remote to close the connection
On Thu, Aug 01, 2019 at 05:25:41PM +0200, Stefano Garzarella wrote:
> +/* Wait for the remote to close the connection */
> +void vsock_wait_remote_close(int fd)
> +{
> + struct epoll_event ev;
> + int epollfd, nfds;
> +
> + epollfd = epoll_create1(0);
> + if (epollfd == -1) {
> + perror("epoll_create1");
> + exit(EXIT_FAILURE);
> + }
> +
> + ev.events = EPOLLRDHUP | EPOLLHUP;
> + ev.data.fd = fd;
> + if (epoll_ctl(epollfd, EPOLL_CTL_ADD, fd, ) == -1) {
> + perror("epoll_ctl");
> + exit(EXIT_FAILURE);
> + }
> +
> + nfds = epoll_wait(epollfd, , 1, TIMEOUT * 1000);
> + if (nfds == -1) {
> + perror("epoll_wait");
> + exit(EXIT_FAILURE);
> + }
> +
> + if (nfds == 0) {
> + fprintf(stderr, "epoll_wait timed out\n");
> + exit(EXIT_FAILURE);
> + }
> +
> + assert(nfds == 1);
> + assert(ev.events & (EPOLLRDHUP | EPOLLHUP));
> + assert(ev.data.fd == fd);
> +
> + close(epollfd);
> +}
Please use timeout_begin()/timeout_end() so that the test cannot hang.
> diff --git a/tools/testing/vsock/vsock_test.c
> b/tools/testing/vsock/vsock_test.c
> index 64adf45501ca..a664675bec5a 100644
> --- a/tools/testing/vsock/vsock_test.c
> +++ b/tools/testing/vsock/vsock_test.c
> @@ -84,6 +84,11 @@ static void test_stream_client_close_server(const struct
> test_opts *opts)
>
> control_expectln("CLOSED");
>
> + /* Wait for the remote to close the connection, before check
> + * -EPIPE error on send.
> + */
> + vsock_wait_remote_close(fd);
Is control_expectln("CLOSED") still necessary now that we're waiting for
the poll event? The control message was an attempt to wait until the
other side closed the socket.
signature.asc
Description: PGP signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/qxl: fix a memory leak bug
On Mon, Aug 19, 2019 at 01:08:18PM -0500, Wenwen Wang wrote: > In qxl_bo_create(), the temporary 'bo' is allocated through kzalloc(). > However, it is not deallocated in the following execution if ttm_bo_init() > fails, leading to a memory leak bug. To fix this issue, free 'bo' before > returning the error. No. ttm_bo_init() calls the destroy callback (qxl_ttm_bo_destroy for qxl) on failure, which will properly cleanup 'bo' and also free it. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
