Re: [PATCH] drm/virtio: fix mmap page attributes

[Gurchetan Singh]

On Tue, Dec 10, 2019 at 12:58 AM Gerd Hoffmann  wrote:
>
> virtio-gpu uses cached mappings.  shmem helpers use writecombine though.
> So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak
> vm_page_prot accordingly.
>
> Reported-by: Gurchetan Singh 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/virtio/virtgpu_object.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index 017a9e0fc3bb..158610902054 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -75,6 +75,22 @@ static void virtio_gpu_free_object(struct drm_gem_object 
> *obj)
> drm_gem_shmem_free_object(obj);
>  }
>
> +static int virtio_gpu_gem_mmap(struct drm_gem_object *obj, struct 
> vm_area_struct *vma)
> +{
> +   pgprot_t prot;
> +   int ret;
> +
> +   ret = drm_gem_shmem_mmap(obj, vma);
> +   if (ret < 0)
> +   return ret;
> +
> +   /* virtio-gpu needs normal caching, so clear writecombine */
> +   prot = vm_get_page_prot(vma->vm_flags);
> +   prot = pgprot_decrypted(prot);
> +   vma->vm_page_prot = prot;
> +   return 0;
> +}
> +
>  static const struct drm_gem_object_funcs virtio_gpu_gem_funcs = {
> .free = virtio_gpu_free_object,
> .open = virtio_gpu_gem_object_open,
> @@ -86,7 +102,7 @@ static const struct drm_gem_object_funcs 
> virtio_gpu_gem_funcs = {
> .get_sg_table = drm_gem_shmem_get_sg_table,
> .vmap = drm_gem_shmem_vmap,

Do we need vmap/vmunap?  It seems optionable and also uses non-cacheable memory?

> .vunmap = drm_gem_shmem_vunmap,
> -   .mmap = _gem_shmem_mmap,
> +   .mmap = _gpu_gem_mmap,

Why the _gpu_gem_mmap?  Shouldn't just virtio_gpu_gem_mmap work?



>  };
>
>  struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev,
> --
> 2.18.1
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH AUTOSEL 4.14 113/130] crypto: virtio - deal with unsupported input sizes

[Sasha Levin]

From: Ard Biesheuvel 

[ Upstream commit 19c5da7d4a2662e85ea67d2d81df57e038fde3ab ]

Return -EINVAL for input sizes that are not a multiple of the AES
block size, since they are not supported by our CBC chaining mode.

While at it, remove the pr_err() that reports unsupported key sizes
being used: we shouldn't spam the kernel log with that.

Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Gonglei 
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/virtio/virtio_crypto_algs.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c 
b/drivers/crypto/virtio/virtio_crypto_algs.c
index 5035b0dc1e40c..e2231a1a05a12 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -110,8 +110,6 @@ virtio_crypto_alg_validate_key(int key_len, uint32_t *alg)
*alg = VIRTIO_CRYPTO_CIPHER_AES_CBC;
break;
default:
-   pr_err("virtio_crypto: Unsupported key length: %d\n",
-   key_len);
return -EINVAL;
}
return 0;
@@ -485,6 +483,11 @@ static int virtio_crypto_ablkcipher_encrypt(struct 
ablkcipher_request *req)
/* Use the first data virtqueue as default */
struct data_queue *data_vq = >data_vq[0];
 
+   if (!req->nbytes)
+   return 0;
+   if (req->nbytes % AES_BLOCK_SIZE)
+   return -EINVAL;
+
vc_req->dataq = data_vq;
vc_req->alg_cb = virtio_crypto_dataq_sym_callback;
vc_sym_req->ablkcipher_ctx = ctx;
@@ -505,6 +508,11 @@ static int virtio_crypto_ablkcipher_decrypt(struct 
ablkcipher_request *req)
/* Use the first data virtqueue as default */
struct data_queue *data_vq = >data_vq[0];
 
+   if (!req->nbytes)
+   return 0;
+   if (req->nbytes % AES_BLOCK_SIZE)
+   return -EINVAL;
+
vc_req->dataq = data_vq;
vc_req->alg_cb = virtio_crypto_dataq_sym_callback;
vc_sym_req->ablkcipher_ctx = ctx;
-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH AUTOSEL 4.19 154/177] crypto: virtio - deal with unsupported input sizes

[Sasha Levin]

From: Ard Biesheuvel 

[ Upstream commit 19c5da7d4a2662e85ea67d2d81df57e038fde3ab ]

Return -EINVAL for input sizes that are not a multiple of the AES
block size, since they are not supported by our CBC chaining mode.

While at it, remove the pr_err() that reports unsupported key sizes
being used: we shouldn't spam the kernel log with that.

Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Gonglei 
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/virtio/virtio_crypto_algs.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c 
b/drivers/crypto/virtio/virtio_crypto_algs.c
index 2c573d1aaa64f..523b712770ac5 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -117,8 +117,6 @@ virtio_crypto_alg_validate_key(int key_len, uint32_t *alg)
*alg = VIRTIO_CRYPTO_CIPHER_AES_CBC;
break;
default:
-   pr_err("virtio_crypto: Unsupported key length: %d\n",
-   key_len);
return -EINVAL;
}
return 0;
@@ -498,6 +496,11 @@ static int virtio_crypto_ablkcipher_encrypt(struct 
ablkcipher_request *req)
/* Use the first data virtqueue as default */
struct data_queue *data_vq = >data_vq[0];
 
+   if (!req->nbytes)
+   return 0;
+   if (req->nbytes % AES_BLOCK_SIZE)
+   return -EINVAL;
+
vc_req->dataq = data_vq;
vc_req->alg_cb = virtio_crypto_dataq_sym_callback;
vc_sym_req->ablkcipher_ctx = ctx;
@@ -518,6 +521,11 @@ static int virtio_crypto_ablkcipher_decrypt(struct 
ablkcipher_request *req)
/* Use the first data virtqueue as default */
struct data_queue *data_vq = >data_vq[0];
 
+   if (!req->nbytes)
+   return 0;
+   if (req->nbytes % AES_BLOCK_SIZE)
+   return -EINVAL;
+
vc_req->dataq = data_vq;
vc_req->alg_cb = virtio_crypto_dataq_sym_callback;
vc_sym_req->ablkcipher_ctx = ctx;
-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH AUTOSEL 5.4 297/350] crypto: virtio - deal with unsupported input sizes

[Sasha Levin]

From: Ard Biesheuvel 

[ Upstream commit 19c5da7d4a2662e85ea67d2d81df57e038fde3ab ]

Return -EINVAL for input sizes that are not a multiple of the AES
block size, since they are not supported by our CBC chaining mode.

While at it, remove the pr_err() that reports unsupported key sizes
being used: we shouldn't spam the kernel log with that.

Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Gonglei 
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/virtio/virtio_crypto_algs.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c 
b/drivers/crypto/virtio/virtio_crypto_algs.c
index 42d19205166b0..673fb29fda53c 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -105,8 +105,6 @@ virtio_crypto_alg_validate_key(int key_len, uint32_t *alg)
*alg = VIRTIO_CRYPTO_CIPHER_AES_CBC;
break;
default:
-   pr_err("virtio_crypto: Unsupported key length: %d\n",
-   key_len);
return -EINVAL;
}
return 0;
@@ -484,6 +482,11 @@ static int virtio_crypto_ablkcipher_encrypt(struct 
ablkcipher_request *req)
/* Use the first data virtqueue as default */
struct data_queue *data_vq = >data_vq[0];
 
+   if (!req->nbytes)
+   return 0;
+   if (req->nbytes % AES_BLOCK_SIZE)
+   return -EINVAL;
+
vc_req->dataq = data_vq;
vc_req->alg_cb = virtio_crypto_dataq_sym_callback;
vc_sym_req->ablkcipher_ctx = ctx;
@@ -504,6 +507,11 @@ static int virtio_crypto_ablkcipher_decrypt(struct 
ablkcipher_request *req)
/* Use the first data virtqueue as default */
struct data_queue *data_vq = >data_vq[0];
 
+   if (!req->nbytes)
+   return 0;
+   if (req->nbytes % AES_BLOCK_SIZE)
+   return -EINVAL;
+
vc_req->dataq = data_vq;
vc_req->alg_cb = virtio_crypto_dataq_sym_callback;
vc_sym_req->ablkcipher_ctx = ctx;
-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH AUTOSEL 5.4 002/350] drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper.

[Sasha Levin]

From: Gerd Hoffmann 

[ Upstream commit 29cf12394c0565d7eb1685bf0c1b4749aa6a8b66 ]

Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.

v9: fix return value.
v5: handle lookup failure.
v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Daniel Vetter 
Reviewed-by: Chia-I Wu 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-3-kra...@redhat.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 28 +++---
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 0a88ef11b9d3f..a662394f68921 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -463,25 +463,29 @@ out:
 }
 
 static int virtio_gpu_wait_ioctl(struct drm_device *dev, void *data,
-   struct drm_file *file)
+struct drm_file *file)
 {
struct drm_virtgpu_3d_wait *args = data;
-   struct drm_gem_object *gobj = NULL;
-   struct virtio_gpu_object *qobj = NULL;
+   struct drm_gem_object *obj;
+   long timeout = 15 * HZ;
int ret;
-   bool nowait = false;
 
-   gobj = drm_gem_object_lookup(file, args->handle);
-   if (gobj == NULL)
+   obj = drm_gem_object_lookup(file, args->handle);
+   if (obj == NULL)
return -ENOENT;
 
-   qobj = gem_to_virtio_gpu_obj(gobj);
-
-   if (args->flags & VIRTGPU_WAIT_NOWAIT)
-   nowait = true;
-   ret = virtio_gpu_object_wait(qobj, nowait);
+   if (args->flags & VIRTGPU_WAIT_NOWAIT) {
+   ret = dma_resv_test_signaled_rcu(obj->resv, true);
+   } else {
+   ret = dma_resv_wait_timeout_rcu(obj->resv, true, true,
+   timeout);
+   }
+   if (ret == 0)
+   ret = -EBUSY;
+   else if (ret > 0)
+   ret = 0;
 
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put_unlocked(obj);
return ret;
 }
 
-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net-next v11 0/3] netdev: ndo_tx_timeout cleanup

[David Miller]

From: "Michael S. Tsirkin" 
Date: Tue, 10 Dec 2019 08:08:58 -0500

> Sorry about the churn, v10 was based on net - not on net-next
> by mistake.

Ugh sorry, I just saw this.  vger is sending postings massively out of
order today.

Ignore my previous reply to #1 :-)
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net-next v10 1/3] netdev: pass the stuck queue to the timeout handler

[David Miller]

Michael, please provide a proper introductory posting for your patch series
just like everyone else does.

Not only does it help people understand at a high level what the patch
series is doing, how it is doing it, and why it is doing it that way.  It
also gives me a single email to reply to when I apply your patch series.

Therefore, please respin this properly.

Thank you.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Call for Papers - MICRADS 2020, Quito, Ecuador | Deadline: December 23

[Maria Lemos]

* Proceedings by Springer, indexed by Scopus, ISI, EI-Compendex, Google 
Scholar, etc.

 

--

MICRADS´20 - The 2020 Multidisciplinary International Conference of Research 
Applied to Defense and Security

Quito, Ecuador, 13 - 15 May 2020

http://www.micrads.org/ 

--

 

Scope

MICRADS´20 - The 2020 Multidisciplinary International Conference of Research 
Applied to Defense and Security, to be held at Quito, Ecuador, 13-15 May 2020, 
is an international forum for researchers and practitioners to present and 
discuss the most recent innovations, trends, results, experiences and concerns 
in the several perspectives of Defense and Security.

We are pleased to invite you to submit your papers to MICRADS´20. They can be 
written in English, Spanish or Portuguese. All submissions will be reviewed on 
the basis of relevance, originality, importance and clarity.

 

Topics

Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

 

Area A: Systems, Communication and Defense

A1) Information and Communication Technology in Education
A2) Simulation and computer vision in military applications
A3) Analysis and Signal Processing
A4) Cybersecurity and Cyberdefense
A5) Computer Networks, Mobility and Pervasive Systems

  

Area B: Strategy and political-administrative vision in Defense

B1) Safety and Maritime Protection
B2) Strategy, Geopolitics and Oceanopolitics
B3) Planning, economy and logistics applied to Defense
B4) Leadership and e-leadership
B5) Military Marketing
B6) Health informatics in military applications

 

Area C: Engineering and technologies applied to Defense

C1) Wearable Technology and Assistance Devices
C2) Military Naval Engineering
C3) Weapons and Combat Systems
C4) Chemical, Biological and Nuclear Defense
C5) Defense Engineering (General)

  

Submission and Decision

Submitted papers written in English (until 10-page limit) must comply with the 
format of Smart Innovation, Systems and Technologies series (see Instructions 
for Authors at Springer Website 
),
 must not have been published before, not be under review for any other 
conference or publication and not include any information leading to the 
authors’ identification. Therefore, the authors’ names, affiliations and 
e-mails should not be included in the version for evaluation by the Scientific 
Committee. This information should only be included in the camera-ready 
version, saved in Word or Latex format and also in PDF format. These files must 
be accompanied by the Consent to Publish form 
 filled out, in a ZIP file, and uploaded at 
the conference management system.

Submitted papers written in Spanish or Portuguese (until 15-page limit) must 
comply with the format of RISTI  - Revista Ibérica de 
Sistemas e Tecnologias de Informação (download instructions/template for 
authors in Spanish  or Portuguese 
), must not have been published before, 
not be under review for any other conference or publication and not include any 
information leading to the authors’ identification. Therefore, the authors’ 
names, affiliations and e-mails should not be included in the version for 
evaluation by the Scientific Committee. This information should only be 
included in the camera-ready version, saved in Word. These file must be 
uploaded at the conference management system in a ZIP file.

All papers will be subjected to a “blind review” by at least two members of the 
Scientific Committee.

Based on Scientific Committee evaluation, a paper can be rejected or accepted 
by the Conference Chairs. In the later case, it can be accepted as paper or 
poster.

The authors of papers accepted as posters must build and print a poster to be 
exhibited during the Conference. This poster must follow an A1 or A2 vertical 
format. The Conference can includes Work Sessions where these posters are 
presented and orally discussed, with a 7 minute limit per poster.

The authors of accepted papers will have 15 minutes to present their work in a 
Conference Work Session; approximately 5 minutes of discussion will follow each 
presentation.

 

Publication and Indexing

To ensure that an accepted paper is published, at least one of the authors must 
be fully registered by the 18 of February 2020, and the paper must comply with 
the suggested layout and page-limit (until 10 pages). Additionally, all 
recommended changes must be addressed by the authors before they submit the 
camera-ready version.

No more than one paper per registration will be published. An extra fee must be 
paid for publication of 

Re: [PATCH v2] virtio-balloon: fix managed page counts when migrating pages between zones

[David Hildenbrand]

On 10.12.19 16:24, Michael S. Tsirkin wrote:
> On Tue, Dec 10, 2019 at 02:44:38PM +0100, David Hildenbrand wrote:
>> On 05.12.19 10:24, David Hildenbrand wrote:
>>> In case we have to migrate a ballon page to a newpage of another zone, the
>>> managed page count of both zones is wrong. Paired with memory offlining
>>> (which will adjust the managed page count), we can trigger kernel crashes
>>> and all kinds of different symptoms.
>>>
>>> One way to reproduce:
>>> 1. Start a QEMU guest with 4GB, no NUMA
>>> 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL
>>
>> s/only/online/
>>
>> as requested by Igor.
>>
>>> 3. Inflate the balloon to 1GB
>>> 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
>>> 5. Observe /proc/zoneinfo
>>>   Node 0, zone   Normal
>>> pages free 16810
>>>   min  24848885473806
>>>   low  18471592959183339
>>>   high 36918337032892872
>>>   spanned  262144
>>>   present  262144
>>>   managed  18446744073709533486
>>> 6. Do anything that requires some memory (e.g., inflate the balloon some
>>> more). The OOM goes crazy and the system crashes
>>>   [  238.324946] Out of memory: Killed process 537 (login) 
>>> total-vm:27584kB, anon-rss:860kB, file-rss:0kB, shmem-rss:00
>>>   [  238.338585] systemd invoked oom-killer: 
>>> gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
>>>   [  238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G  D W 
>>> 5.4.0-next-20191204+ #75
>>>   [  238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
>>> BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
>>>   [  238.341121] Call Trace:
>>>   [  238.341337]  dump_stack+0x8f/0xd0
>>>   [  238.341630]  dump_header+0x61/0x5ea
>>>   [  238.341942]  oom_kill_process.cold+0xb/0x10
>>>   [  238.342299]  out_of_memory+0x24d/0x5a0
>>>   [  238.342625]  __alloc_pages_slowpath+0xd12/0x1020
>>>   [  238.343024]  __alloc_pages_nodemask+0x391/0x410
>>>   [  238.343407]  pagecache_get_page+0xc3/0x3a0
>>>   [  238.343757]  filemap_fault+0x804/0xc30
>>>   [  238.344083]  ? ext4_filemap_fault+0x28/0x42
>>>   [  238.34]  ext4_filemap_fault+0x30/0x42
>>>   [  238.344789]  __do_fault+0x37/0x1a0
>>>   [  238.345087]  __handle_mm_fault+0x104d/0x1ab0
>>>   [  238.345450]  handle_mm_fault+0x169/0x360
>>>   [  238.345790]  do_user_addr_fault+0x20d/0x490
>>>   [  238.346154]  do_page_fault+0x31/0x210
>>>   [  238.346468]  async_page_fault+0x43/0x50
>>>   [  238.346797] RIP: 0033:0x7f47eba4197e
>>>   [  238.347110] Code: Bad RIP value.
>>>   [  238.347387] RSP: 002b:7ffd7c0c1890 EFLAGS: 00010293
>>>   [  238.347834] RAX: 0002 RBX: 55d196a20a20 RCX: 
>>> 7f47eba4197e
>>>   [  238.348437] RDX: 0033 RSI: 7ffd7c0c18c0 RDI: 
>>> 0004
>>>   [  238.349047] RBP: 7ffd7c0c1c20 R08:  R09: 
>>> 0033
>>>   [  238.349660] R10:  R11: 0293 R12: 
>>> 0001
>>>   [  238.350261] R13:  R14:  R15: 
>>> 7ffd7c0c18c0
>>>   [  238.350878] Mem-Info:
>>>   [  238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
>>>   [  238.351085]  active_file:12 inactive_file:7 isolated_file:0
>>>   [  238.351085]  unevictable:0 dirty:0 writeback:0 unstable:0
>>>   [  238.351085]  slab_reclaimable:5565 slab_unreclaimable:10170
>>>   [  238.351085]  mapped:3 shmem:111 pagetables:155 bounce:0
>>>   [  238.351085]  free:720717 free_pcp:2 free_cma:0
>>>   [  238.353757] Node 0 active_anon:12484kB inactive_anon:204kB 
>>> active_file:48kB inactive_file:28kB unevictable:0kB iss
>>>   [  238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB 
>>> reserved_highatomic:0KB active_anon:152kB inactivB
>>>   [  238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
>>>   [  238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB 
>>> high:13052kB reserved_highatomic:0KB active_anon:0B
>>>   [  238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 
>>> 72057594037927865
>>>   [  238.361888] Node 0 Normal free:193448kB min:99395541895224kB 
>>> low:73886371836733356kB high:147673348131571488kB reB
>>>   [  238.364765] lowmem_reserve[]: 0 0 0 0 0
>>>   [  238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 
>>> 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
>>>   [  238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 
>>> 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
>>>   [  238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB 
>>> (UME) 524*32kB (UME) 300*64kB (UME) 138*128kB (B
>>>   [  238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
>>> hugepages_size=2048kB
>>>   [  238.369915] 130 total pagecache pages
>>>   [  238.370241] 0 pages in swap cache
>>>   [  238.370533] Swap cache stats: add 0, delete 0, find 0/0
>>>   [  238.370981] Free swap  = 0kB
>>>   [  238.371239] Total swap = 0kB
>>>   [  

Re: [PATCH v2] virtio-balloon: fix managed page counts when migrating pages between zones

[Michael S. Tsirkin]

On Tue, Dec 10, 2019 at 02:44:38PM +0100, David Hildenbrand wrote:
> On 05.12.19 10:24, David Hildenbrand wrote:
> > In case we have to migrate a ballon page to a newpage of another zone, the
> > managed page count of both zones is wrong. Paired with memory offlining
> > (which will adjust the managed page count), we can trigger kernel crashes
> > and all kinds of different symptoms.
> > 
> > One way to reproduce:
> > 1. Start a QEMU guest with 4GB, no NUMA
> > 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL
> 
> s/only/online/
> 
> as requested by Igor.
> 
> > 3. Inflate the balloon to 1GB
> > 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
> > 5. Observe /proc/zoneinfo
> >   Node 0, zone   Normal
> > pages free 16810
> >   min  24848885473806
> >   low  18471592959183339
> >   high 36918337032892872
> >   spanned  262144
> >   present  262144
> >   managed  18446744073709533486
> > 6. Do anything that requires some memory (e.g., inflate the balloon some
> > more). The OOM goes crazy and the system crashes
> >   [  238.324946] Out of memory: Killed process 537 (login) 
> > total-vm:27584kB, anon-rss:860kB, file-rss:0kB, shmem-rss:00
> >   [  238.338585] systemd invoked oom-killer: 
> > gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
> >   [  238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G  D W 
> > 5.4.0-next-20191204+ #75
> >   [  238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> > BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
> >   [  238.341121] Call Trace:
> >   [  238.341337]  dump_stack+0x8f/0xd0
> >   [  238.341630]  dump_header+0x61/0x5ea
> >   [  238.341942]  oom_kill_process.cold+0xb/0x10
> >   [  238.342299]  out_of_memory+0x24d/0x5a0
> >   [  238.342625]  __alloc_pages_slowpath+0xd12/0x1020
> >   [  238.343024]  __alloc_pages_nodemask+0x391/0x410
> >   [  238.343407]  pagecache_get_page+0xc3/0x3a0
> >   [  238.343757]  filemap_fault+0x804/0xc30
> >   [  238.344083]  ? ext4_filemap_fault+0x28/0x42
> >   [  238.34]  ext4_filemap_fault+0x30/0x42
> >   [  238.344789]  __do_fault+0x37/0x1a0
> >   [  238.345087]  __handle_mm_fault+0x104d/0x1ab0
> >   [  238.345450]  handle_mm_fault+0x169/0x360
> >   [  238.345790]  do_user_addr_fault+0x20d/0x490
> >   [  238.346154]  do_page_fault+0x31/0x210
> >   [  238.346468]  async_page_fault+0x43/0x50
> >   [  238.346797] RIP: 0033:0x7f47eba4197e
> >   [  238.347110] Code: Bad RIP value.
> >   [  238.347387] RSP: 002b:7ffd7c0c1890 EFLAGS: 00010293
> >   [  238.347834] RAX: 0002 RBX: 55d196a20a20 RCX: 
> > 7f47eba4197e
> >   [  238.348437] RDX: 0033 RSI: 7ffd7c0c18c0 RDI: 
> > 0004
> >   [  238.349047] RBP: 7ffd7c0c1c20 R08:  R09: 
> > 0033
> >   [  238.349660] R10:  R11: 0293 R12: 
> > 0001
> >   [  238.350261] R13:  R14:  R15: 
> > 7ffd7c0c18c0
> >   [  238.350878] Mem-Info:
> >   [  238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
> >   [  238.351085]  active_file:12 inactive_file:7 isolated_file:0
> >   [  238.351085]  unevictable:0 dirty:0 writeback:0 unstable:0
> >   [  238.351085]  slab_reclaimable:5565 slab_unreclaimable:10170
> >   [  238.351085]  mapped:3 shmem:111 pagetables:155 bounce:0
> >   [  238.351085]  free:720717 free_pcp:2 free_cma:0
> >   [  238.353757] Node 0 active_anon:12484kB inactive_anon:204kB 
> > active_file:48kB inactive_file:28kB unevictable:0kB iss
> >   [  238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB 
> > reserved_highatomic:0KB active_anon:152kB inactivB
> >   [  238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
> >   [  238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB 
> > high:13052kB reserved_highatomic:0KB active_anon:0B
> >   [  238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 
> > 72057594037927865
> >   [  238.361888] Node 0 Normal free:193448kB min:99395541895224kB 
> > low:73886371836733356kB high:147673348131571488kB reB
> >   [  238.364765] lowmem_reserve[]: 0 0 0 0 0
> >   [  238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 
> > 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
> >   [  238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 
> > 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
> >   [  238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB 
> > (UME) 524*32kB (UME) 300*64kB (UME) 138*128kB (B
> >   [  238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
> > hugepages_size=2048kB
> >   [  238.369915] 130 total pagecache pages
> >   [  238.370241] 0 pages in swap cache
> >   [  238.370533] Swap cache stats: add 0, delete 0, find 0/0
> >   [  238.370981] Free swap  = 0kB
> >   [  238.371239] Total swap = 0kB
> >   [  238.371488] 1048445 pages RAM
> >   [  238.371756] 

Re: [PATCH] vhost/vsock: accept only packets with the right dst_cid

[Stefano Garzarella]

On Tue, Dec 10, 2019 at 09:05:58AM -0500, Michael S. Tsirkin wrote:
> On Fri, Dec 06, 2019 at 03:39:12PM +0100, Stefano Garzarella wrote:
> > When we receive a new packet from the guest, we check if the
> > src_cid is correct, but we forgot to check the dst_cid.
> > 
> > The host should accept only packets where dst_cid is
> > equal to the host CID.
> > 
> > Signed-off-by: Stefano Garzarella 
> 
> what's the implication of processing incorrect dst cid?
> I think mostly it's malformed guests, right?

Exaclty, as for the src_cid.

In both cases the packet may be delivered to the wrong socket in the
host, because in the virtio_transport_recv_pkt() we are using the
src_cid and dst_cid to look for the socket where to queue the packet.

> Everyone else just passes the known host cid ...

Yes, good guests should do it, and we do it :-)

Thanks,
Stefano

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH RFC net-next v8 1/3] netdev: pass the stuck queue to the timeout handler

[Michael S. Tsirkin]

On Mon, Dec 09, 2019 at 08:40:06AM +0100, Geert Uytterhoeven wrote:
> Hi Michael,
> 
> On Tue, Dec 3, 2019 at 9:21 PM Michael S. Tsirkin  wrote:
> > This allows incrementing the correct timeout statistic without any mess.
> > Down the road, devices can learn to reset just the specific queue.
> >
> > The patch was generated with the following script:
> 
> [...]
> 
> > Signed-off-by: Michael S. Tsirkin 
> 
> > --- a/drivers/net/ethernet/8390/8390p.c
> > +++ b/drivers/net/ethernet/8390/8390p.c
> > @@ -41,9 +41,9 @@ void eip_set_multicast_list(struct net_device *dev)
> >  }
> >  EXPORT_SYMBOL(eip_set_multicast_list);
> >
> > -void eip_tx_timeout(struct net_device *dev)
> > +void eip_tx_timeout(struct net_device *dev, unsigned int txqueue)
> >  {
> > -   __ei_tx_timeout(dev);
> > +   __ei_tx_timeout(dev, txqueue);
> >  }
> >  EXPORT_SYMBOL(eip_tx_timeout);
> 
> On Mon, Dec 9, 2019 at 6:37 AM  wrote:
> > FAILED linux-next/m68k-defconfig/m68k Mon Dec 09, 16:34
> >
> > http://kisskb.ellerman.id.au/kisskb/buildresult/14060060/
> >
> > Commit:   Add linux-next specific files for 20191209
> >   6cf8298daad041cd15dc514d8a4f93ca3636c84e
> > Compiler: m68k-linux-gcc (GCC) 4.6.3 / GNU ld (GNU Binutils) 2.22
> >
> > Possible errors
> > ---
> >
> > drivers/net/ethernet/8390/8390p.c:44:6: error: conflicting types for 
> > 'eip_tx_timeout'
> > drivers/net/ethernet/8390/8390p.c:48:1: error: conflicting types for 
> > 'eip_tx_timeout'
> > make[5]: *** [scripts/Makefile.build:266: 
> > drivers/net/ethernet/8390/8390p.o] Error 1
> > make[4]: *** [scripts/Makefile.build:503: drivers/net/ethernet/8390] Error 2
> > make[3]: *** [scripts/Makefile.build:503: drivers/net/ethernet] Error 2
> > make[2]: *** [scripts/Makefile.build:503: drivers/net] Error 2
> > make[1]: *** [Makefile:1693: drivers] Error 2
> > make: *** [Makefile:179: sub-make] Error 2
> 
> Looks like you forgot to update the forward declaration in
> drivers/net/ethernet/8390/8390.h

Fixed now.

> There may be others...

Could not find any but pls do let me know.

> http://kisskb.ellerman.id.au/kisskb/head/6cf8298daad041cd15dc514d8a4f93ca3636c84e/
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v12 3/3] netronome: use the new txqueue timeout argument

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin 
Acked-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c 
b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index bd305fc6ed5a..d4eeb3b3cf35 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -1324,14 +1324,8 @@ nfp_net_tx_ring_reset(struct nfp_net_dp *dp, struct 
nfp_net_tx_ring *tx_ring)
 static void nfp_net_tx_timeout(struct net_device *netdev, unsigned int txqueue)
 {
struct nfp_net *nn = netdev_priv(netdev);
-   int i;
 
-   for (i = 0; i < nn->dp.netdev->real_num_tx_queues; i++) {
-   if (!netif_tx_queue_stopped(netdev_get_tx_queue(netdev, i)))
-   continue;
-   nn_warn(nn, "TX timeout on ring: %d\n", i);
-   }
-   nn_warn(nn, "TX watchdog timeout\n");
+   nn_warn(nn, "TX watchdog timeout on ring: %u\n", txqueue);
 }
 
 /* Receive processing
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v12 0/3] netdev: ndo_tx_timeout cleanup

[Michael S. Tsirkin]

Yet another forward declaration I missed. Hopfully the last one ...

A bunch of drivers want to know which tx queue triggered a timeout,
and virtio wants to do the same.
We actually have the info to hand, let's just pass it on to drivers.
Note: tested with an experimental virtio patch by Julio.
That patch itself isn't ready yet though, so not included.
Other drivers compiled only.


Michael S. Tsirkin (3):
  netdev: pass the stuck queue to the timeout handler
  mlx4: use new txqueue timeout argument
  netronome: use the new txqueue timeout argument

 arch/m68k/emu/nfeth.c|  2 +-
 arch/um/drivers/net_kern.c   |  2 +-
 arch/um/drivers/vector_kern.c|  2 +-
 arch/xtensa/platforms/iss/network.c  |  2 +-
 drivers/char/pcmcia/synclink_cs.c|  2 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c|  2 +-
 drivers/message/fusion/mptlan.c  |  2 +-
 drivers/misc/sgi-xp/xpnet.c  |  2 +-
 drivers/net/appletalk/cops.c |  4 ++--
 drivers/net/arcnet/arcdevice.h   |  2 +-
 drivers/net/arcnet/arcnet.c  |  2 +-
 drivers/net/ethernet/3com/3c509.c|  4 ++--
 drivers/net/ethernet/3com/3c515.c|  4 ++--
 drivers/net/ethernet/3com/3c574_cs.c |  4 ++--
 drivers/net/ethernet/3com/3c589_cs.c |  4 ++--
 drivers/net/ethernet/3com/3c59x.c|  4 ++--
 drivers/net/ethernet/3com/typhoon.c  |  2 +-
 drivers/net/ethernet/8390/8390.c |  4 ++--
 drivers/net/ethernet/8390/8390.h |  4 ++--
 drivers/net/ethernet/8390/8390p.c|  4 ++--
 drivers/net/ethernet/8390/axnet_cs.c |  4 ++--
 drivers/net/ethernet/8390/lib8390.c  |  2 +-
 drivers/net/ethernet/adaptec/starfire.c  |  4 ++--
 drivers/net/ethernet/agere/et131x.c  |  2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c  |  2 +-
 drivers/net/ethernet/alteon/acenic.c |  4 ++--
 drivers/net/ethernet/amazon/ena/ena_netdev.c |  2 +-
 drivers/net/ethernet/amd/7990.c  |  2 +-
 drivers/net/ethernet/amd/7990.h  |  2 +-
 drivers/net/ethernet/amd/a2065.c |  2 +-
 drivers/net/ethernet/amd/am79c961a.c |  2 +-
 drivers/net/ethernet/amd/amd8111e.c  |  2 +-
 drivers/net/ethernet/amd/ariadne.c   |  2 +-
 drivers/net/ethernet/amd/atarilance.c|  4 ++--
 drivers/net/ethernet/amd/au1000_eth.c|  2 +-
 drivers/net/ethernet/amd/declance.c  |  2 +-
 drivers/net/ethernet/amd/lance.c |  4 ++--
 drivers/net/ethernet/amd/ni65.c  |  4 ++--
 drivers/net/ethernet/amd/nmclan_cs.c |  4 ++--
 drivers/net/ethernet/amd/pcnet32.c   |  4 ++--
 drivers/net/ethernet/amd/sunlance.c  |  2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c |  2 +-
 drivers/net/ethernet/apm/xgene-v2/main.c |  2 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |  2 +-
 drivers/net/ethernet/apple/macmace.c |  4 ++--
 drivers/net/ethernet/atheros/ag71xx.c|  2 +-
 drivers/net/ethernet/atheros/alx/main.c  |  2 +-
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c  |  2 +-
 drivers/net/ethernet/atheros/atl1e/atl1e_main.c  |  2 +-
 drivers/net/ethernet/atheros/atlx/atl2.c |  2 +-
 drivers/net/ethernet/atheros/atlx/atlx.c |  2 +-
 drivers/net/ethernet/broadcom/b44.c  |  2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c   |  2 +-
 drivers/net/ethernet/broadcom/bnx2.c |  2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c  |  2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h  |  2 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt.c|  2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c   |  2 +-
 drivers/net/ethernet/broadcom/sb1250-mac.c   |  4 ++--
 drivers/net/ethernet/broadcom/tg3.c  |  2 +-
 drivers/net/ethernet/calxeda/xgmac.c |  2 +-
 drivers/net/ethernet/cavium/liquidio/lio_main.c  |  2 +-
 .../net/ethernet/cavium/liquidio/lio_vf_main.c   |  2 +-
 .../net/ethernet/cavium/liquidio/lio_vf_rep.c|  4 ++--
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |  2 +-
 drivers/net/ethernet/cirrus/cs89x0.c |  2 +-
 drivers/net/ethernet/cisco/enic/enic_main.c  |  2 +-
 drivers/net/ethernet/cortina/gemini.c|  2 +-
 drivers/net/ethernet/davicom/dm9000.c|  2 +-
 drivers/net/ethernet/dec/tulip/de2104x.c |  2 +-
 drivers/net/ethernet/dec/tulip/tulip_core.c  |  4 ++--
 drivers/net/ethernet/dec/tulip/winbond-840.c |  4 ++--
 drivers/net/ethernet/dlink/dl2k.c|  4 ++--
 drivers/net/ethernet/dlink/sundance.c|  4 ++--
 drivers/net/ethernet/emulex/benet/be_main.c  |  2 +-
 drivers/net/ethernet/ethoc.c

[PATCH net-next v12 2/3] mlx4: use new txqueue timeout argument

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin 
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 71c083960a87..43dcbd8214c6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1367,20 +1367,14 @@ static void mlx4_en_tx_timeout(struct net_device *dev, 
unsigned int txqueue)
 {
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
-   int i;
+   struct mlx4_en_tx_ring *tx_ring = priv->tx_ring[TX][txqueue];
 
if (netif_msg_timer(priv))
en_warn(priv, "Tx timeout called on port:%d\n", priv->port);
 
-   for (i = 0; i < priv->tx_ring_num[TX]; i++) {
-   struct mlx4_en_tx_ring *tx_ring = priv->tx_ring[TX][i];
-
-   if (!netif_tx_queue_stopped(netdev_get_tx_queue(dev, i)))
-   continue;
-   en_warn(priv, "TX timeout on queue: %d, QP: 0x%x, CQ: 0x%x, 
Cons: 0x%x, Prod: 0x%x\n",
-   i, tx_ring->qpn, tx_ring->sp_cqn,
-   tx_ring->cons, tx_ring->prod);
-   }
+   en_warn(priv, "TX timeout on queue: %d, QP: 0x%x, CQ: 0x%x, Cons: 0x%x, 
Prod: 0x%x\n",
+   txqueue, tx_ring->qpn, tx_ring->sp_cqn,
+   tx_ring->cons, tx_ring->prod);
 
priv->port_stats.tx_timeout++;
en_dbg(DRV, priv, "Scheduling watchdog\n");
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vhost/vsock: accept only packets with the right dst_cid

[Michael S. Tsirkin]

On Fri, Dec 06, 2019 at 03:39:12PM +0100, Stefano Garzarella wrote:
> When we receive a new packet from the guest, we check if the
> src_cid is correct, but we forgot to check the dst_cid.
> 
> The host should accept only packets where dst_cid is
> equal to the host CID.
> 
> Signed-off-by: Stefano Garzarella 

what's the implication of processing incorrect dst cid?
I think mostly it's malformed guests, right?
Everyone else just passes the known host cid ...

> ---
>  drivers/vhost/vsock.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index 50de0642dea6..c2d7d57e98cf 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -480,7 +480,9 @@ static void vhost_vsock_handle_tx_kick(struct vhost_work 
> *work)
>   virtio_transport_deliver_tap_pkt(pkt);
>  
>   /* Only accept correctly addressed packets */
> - if (le64_to_cpu(pkt->hdr.src_cid) == vsock->guest_cid)
> + if (le64_to_cpu(pkt->hdr.src_cid) == vsock->guest_cid &&
> + le64_to_cpu(pkt->hdr.dst_cid) ==
> + vhost_transport_get_local_cid())
>   virtio_transport_recv_pkt(_transport, pkt);
>   else
>   virtio_transport_free_pkt(pkt);
> -- 
> 2.23.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2] virtio-balloon: fix managed page counts when migrating pages between zones

[David Hildenbrand]

On 05.12.19 10:24, David Hildenbrand wrote:
> In case we have to migrate a ballon page to a newpage of another zone, the
> managed page count of both zones is wrong. Paired with memory offlining
> (which will adjust the managed page count), we can trigger kernel crashes
> and all kinds of different symptoms.
> 
> One way to reproduce:
> 1. Start a QEMU guest with 4GB, no NUMA
> 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL

s/only/online/

as requested by Igor.

> 3. Inflate the balloon to 1GB
> 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
> 5. Observe /proc/zoneinfo
>   Node 0, zone   Normal
> pages free 16810
>   min  24848885473806
>   low  18471592959183339
>   high 36918337032892872
>   spanned  262144
>   present  262144
>   managed  18446744073709533486
> 6. Do anything that requires some memory (e.g., inflate the balloon some
> more). The OOM goes crazy and the system crashes
>   [  238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, 
> anon-rss:860kB, file-rss:0kB, shmem-rss:00
>   [  238.338585] systemd invoked oom-killer: 
> gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
>   [  238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G  D W 
> 5.4.0-next-20191204+ #75
>   [  238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
>   [  238.341121] Call Trace:
>   [  238.341337]  dump_stack+0x8f/0xd0
>   [  238.341630]  dump_header+0x61/0x5ea
>   [  238.341942]  oom_kill_process.cold+0xb/0x10
>   [  238.342299]  out_of_memory+0x24d/0x5a0
>   [  238.342625]  __alloc_pages_slowpath+0xd12/0x1020
>   [  238.343024]  __alloc_pages_nodemask+0x391/0x410
>   [  238.343407]  pagecache_get_page+0xc3/0x3a0
>   [  238.343757]  filemap_fault+0x804/0xc30
>   [  238.344083]  ? ext4_filemap_fault+0x28/0x42
>   [  238.34]  ext4_filemap_fault+0x30/0x42
>   [  238.344789]  __do_fault+0x37/0x1a0
>   [  238.345087]  __handle_mm_fault+0x104d/0x1ab0
>   [  238.345450]  handle_mm_fault+0x169/0x360
>   [  238.345790]  do_user_addr_fault+0x20d/0x490
>   [  238.346154]  do_page_fault+0x31/0x210
>   [  238.346468]  async_page_fault+0x43/0x50
>   [  238.346797] RIP: 0033:0x7f47eba4197e
>   [  238.347110] Code: Bad RIP value.
>   [  238.347387] RSP: 002b:7ffd7c0c1890 EFLAGS: 00010293
>   [  238.347834] RAX: 0002 RBX: 55d196a20a20 RCX: 
> 7f47eba4197e
>   [  238.348437] RDX: 0033 RSI: 7ffd7c0c18c0 RDI: 
> 0004
>   [  238.349047] RBP: 7ffd7c0c1c20 R08:  R09: 
> 0033
>   [  238.349660] R10:  R11: 0293 R12: 
> 0001
>   [  238.350261] R13:  R14:  R15: 
> 7ffd7c0c18c0
>   [  238.350878] Mem-Info:
>   [  238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
>   [  238.351085]  active_file:12 inactive_file:7 isolated_file:0
>   [  238.351085]  unevictable:0 dirty:0 writeback:0 unstable:0
>   [  238.351085]  slab_reclaimable:5565 slab_unreclaimable:10170
>   [  238.351085]  mapped:3 shmem:111 pagetables:155 bounce:0
>   [  238.351085]  free:720717 free_pcp:2 free_cma:0
>   [  238.353757] Node 0 active_anon:12484kB inactive_anon:204kB 
> active_file:48kB inactive_file:28kB unevictable:0kB iss
>   [  238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB 
> reserved_highatomic:0KB active_anon:152kB inactivB
>   [  238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
>   [  238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB 
> high:13052kB reserved_highatomic:0KB active_anon:0B
>   [  238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 
> 72057594037927865
>   [  238.361888] Node 0 Normal free:193448kB min:99395541895224kB 
> low:73886371836733356kB high:147673348131571488kB reB
>   [  238.364765] lowmem_reserve[]: 0 0 0 0 0
>   [  238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 
> 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
>   [  238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 2*64kB 
> (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
>   [  238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 
> 524*32kB (UME) 300*64kB (UME) 138*128kB (B
>   [  238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
> hugepages_size=2048kB
>   [  238.369915] 130 total pagecache pages
>   [  238.370241] 0 pages in swap cache
>   [  238.370533] Swap cache stats: add 0, delete 0, find 0/0
>   [  238.370981] Free swap  = 0kB
>   [  238.371239] Total swap = 0kB
>   [  238.371488] 1048445 pages RAM
>   [  238.371756] 0 pages HighMem/MovableOnly
>   [  238.372090] 306992 pages reserved
>   [  238.372376] 0 pages cma reserved
>   [  238.372661] 0 pages hwpoisoned
> 
> In another instance (older kernel), I was able to observe this
> (negative page count :/):
>   [  180.896971] 

Re: [PATCH] virtio-balloon: fix managed page counts when migrating pages between zones

[David Hildenbrand]

On 10.12.19 14:31, Michael S. Tsirkin wrote:
> On Wed, Dec 04, 2019 at 09:48:07PM +0100, David Hildenbrand wrote:
>> In case we have to migrate a ballon page to a newpage of another zone, the
>> managed page count of both zones is wrong. Paired with memory offlining
>> (which will adjust the managed page count), we can trigger kernel crashes
>> and all kinds of different symptoms.
>>
>> One way to reproduce:
>> 1. Start a QEMU guest with 4GB, no NUMA
>> 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL
>> 3. Inflate the balloon to 1GB
>> 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
>> 5. Observe /proc/zoneinfo
>>   Node 0, zone   Normal
>> pages free 16810
>>   min  24848885473806
>>   low  18471592959183339
>>   high 36918337032892872
>>   spanned  262144
>>   present  262144
>>   managed  18446744073709533486
>> 6. Do anything that requires some memory (e.g., inflate the balloon some
>> more). The OOM goes crazy and the system crashes
>>   [  238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, 
>> anon-rss:860kB, file-rss:0kB, shmem-rss:00
>>   [  238.338585] systemd invoked oom-killer: 
>> gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
>>   [  238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G  D W 
>> 5.4.0-next-20191204+ #75
>>   [  238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
>>   [  238.341121] Call Trace:
>>   [  238.341337]  dump_stack+0x8f/0xd0
>>   [  238.341630]  dump_header+0x61/0x5ea
>>   [  238.341942]  oom_kill_process.cold+0xb/0x10
>>   [  238.342299]  out_of_memory+0x24d/0x5a0
>>   [  238.342625]  __alloc_pages_slowpath+0xd12/0x1020
>>   [  238.343024]  __alloc_pages_nodemask+0x391/0x410
>>   [  238.343407]  pagecache_get_page+0xc3/0x3a0
>>   [  238.343757]  filemap_fault+0x804/0xc30
>>   [  238.344083]  ? ext4_filemap_fault+0x28/0x42
>>   [  238.34]  ext4_filemap_fault+0x30/0x42
>>   [  238.344789]  __do_fault+0x37/0x1a0
>>   [  238.345087]  __handle_mm_fault+0x104d/0x1ab0
>>   [  238.345450]  handle_mm_fault+0x169/0x360
>>   [  238.345790]  do_user_addr_fault+0x20d/0x490
>>   [  238.346154]  do_page_fault+0x31/0x210
>>   [  238.346468]  async_page_fault+0x43/0x50
>>   [  238.346797] RIP: 0033:0x7f47eba4197e
>>   [  238.347110] Code: Bad RIP value.
>>   [  238.347387] RSP: 002b:7ffd7c0c1890 EFLAGS: 00010293
>>   [  238.347834] RAX: 0002 RBX: 55d196a20a20 RCX: 
>> 7f47eba4197e
>>   [  238.348437] RDX: 0033 RSI: 7ffd7c0c18c0 RDI: 
>> 0004
>>   [  238.349047] RBP: 7ffd7c0c1c20 R08:  R09: 
>> 0033
>>   [  238.349660] R10:  R11: 0293 R12: 
>> 0001
>>   [  238.350261] R13:  R14:  R15: 
>> 7ffd7c0c18c0
>>   [  238.350878] Mem-Info:
>>   [  238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
>>   [  238.351085]  active_file:12 inactive_file:7 isolated_file:0
>>   [  238.351085]  unevictable:0 dirty:0 writeback:0 unstable:0
>>   [  238.351085]  slab_reclaimable:5565 slab_unreclaimable:10170
>>   [  238.351085]  mapped:3 shmem:111 pagetables:155 bounce:0
>>   [  238.351085]  free:720717 free_pcp:2 free_cma:0
>>   [  238.353757] Node 0 active_anon:12484kB inactive_anon:204kB 
>> active_file:48kB inactive_file:28kB unevictable:0kB iss
>>   [  238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB 
>> reserved_highatomic:0KB active_anon:152kB inactivB
>>   [  238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
>>   [  238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB 
>> high:13052kB reserved_highatomic:0KB active_anon:0B
>>   [  238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 
>> 72057594037927865
>>   [  238.361888] Node 0 Normal free:193448kB min:99395541895224kB 
>> low:73886371836733356kB high:147673348131571488kB reB
>>   [  238.364765] lowmem_reserve[]: 0 0 0 0 0
>>   [  238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 
>> 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
>>   [  238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 
>> 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
>>   [  238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 
>> 524*32kB (UME) 300*64kB (UME) 138*128kB (B
>>   [  238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
>> hugepages_size=2048kB
>>   [  238.369915] 130 total pagecache pages
>>   [  238.370241] 0 pages in swap cache
>>   [  238.370533] Swap cache stats: add 0, delete 0, find 0/0
>>   [  238.370981] Free swap  = 0kB
>>   [  238.371239] Total swap = 0kB
>>   [  238.371488] 1048445 pages RAM
>>   [  238.371756] 0 pages HighMem/MovableOnly
>>   [  238.372090] 306992 pages reserved
>>   [  238.372376] 0 pages cma reserved
>>   [  238.372661] 0 pages 

Re: [PATCH] virtio-balloon: fix managed page counts when migrating pages between zones

[Michael S. Tsirkin]

On Wed, Dec 04, 2019 at 09:48:07PM +0100, David Hildenbrand wrote:
> In case we have to migrate a ballon page to a newpage of another zone, the
> managed page count of both zones is wrong. Paired with memory offlining
> (which will adjust the managed page count), we can trigger kernel crashes
> and all kinds of different symptoms.
> 
> One way to reproduce:
> 1. Start a QEMU guest with 4GB, no NUMA
> 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL
> 3. Inflate the balloon to 1GB
> 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
> 5. Observe /proc/zoneinfo
>   Node 0, zone   Normal
> pages free 16810
>   min  24848885473806
>   low  18471592959183339
>   high 36918337032892872
>   spanned  262144
>   present  262144
>   managed  18446744073709533486
> 6. Do anything that requires some memory (e.g., inflate the balloon some
> more). The OOM goes crazy and the system crashes
>   [  238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, 
> anon-rss:860kB, file-rss:0kB, shmem-rss:00
>   [  238.338585] systemd invoked oom-killer: 
> gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
>   [  238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G  D W 
> 5.4.0-next-20191204+ #75
>   [  238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
>   [  238.341121] Call Trace:
>   [  238.341337]  dump_stack+0x8f/0xd0
>   [  238.341630]  dump_header+0x61/0x5ea
>   [  238.341942]  oom_kill_process.cold+0xb/0x10
>   [  238.342299]  out_of_memory+0x24d/0x5a0
>   [  238.342625]  __alloc_pages_slowpath+0xd12/0x1020
>   [  238.343024]  __alloc_pages_nodemask+0x391/0x410
>   [  238.343407]  pagecache_get_page+0xc3/0x3a0
>   [  238.343757]  filemap_fault+0x804/0xc30
>   [  238.344083]  ? ext4_filemap_fault+0x28/0x42
>   [  238.34]  ext4_filemap_fault+0x30/0x42
>   [  238.344789]  __do_fault+0x37/0x1a0
>   [  238.345087]  __handle_mm_fault+0x104d/0x1ab0
>   [  238.345450]  handle_mm_fault+0x169/0x360
>   [  238.345790]  do_user_addr_fault+0x20d/0x490
>   [  238.346154]  do_page_fault+0x31/0x210
>   [  238.346468]  async_page_fault+0x43/0x50
>   [  238.346797] RIP: 0033:0x7f47eba4197e
>   [  238.347110] Code: Bad RIP value.
>   [  238.347387] RSP: 002b:7ffd7c0c1890 EFLAGS: 00010293
>   [  238.347834] RAX: 0002 RBX: 55d196a20a20 RCX: 
> 7f47eba4197e
>   [  238.348437] RDX: 0033 RSI: 7ffd7c0c18c0 RDI: 
> 0004
>   [  238.349047] RBP: 7ffd7c0c1c20 R08:  R09: 
> 0033
>   [  238.349660] R10:  R11: 0293 R12: 
> 0001
>   [  238.350261] R13:  R14:  R15: 
> 7ffd7c0c18c0
>   [  238.350878] Mem-Info:
>   [  238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
>   [  238.351085]  active_file:12 inactive_file:7 isolated_file:0
>   [  238.351085]  unevictable:0 dirty:0 writeback:0 unstable:0
>   [  238.351085]  slab_reclaimable:5565 slab_unreclaimable:10170
>   [  238.351085]  mapped:3 shmem:111 pagetables:155 bounce:0
>   [  238.351085]  free:720717 free_pcp:2 free_cma:0
>   [  238.353757] Node 0 active_anon:12484kB inactive_anon:204kB 
> active_file:48kB inactive_file:28kB unevictable:0kB iss
>   [  238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB 
> reserved_highatomic:0KB active_anon:152kB inactivB
>   [  238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
>   [  238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB 
> high:13052kB reserved_highatomic:0KB active_anon:0B
>   [  238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 
> 72057594037927865
>   [  238.361888] Node 0 Normal free:193448kB min:99395541895224kB 
> low:73886371836733356kB high:147673348131571488kB reB
>   [  238.364765] lowmem_reserve[]: 0 0 0 0 0
>   [  238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 
> 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
>   [  238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 2*64kB 
> (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
>   [  238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 
> 524*32kB (UME) 300*64kB (UME) 138*128kB (B
>   [  238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
> hugepages_size=2048kB
>   [  238.369915] 130 total pagecache pages
>   [  238.370241] 0 pages in swap cache
>   [  238.370533] Swap cache stats: add 0, delete 0, find 0/0
>   [  238.370981] Free swap  = 0kB
>   [  238.371239] Total swap = 0kB
>   [  238.371488] 1048445 pages RAM
>   [  238.371756] 0 pages HighMem/MovableOnly
>   [  238.372090] 306992 pages reserved
>   [  238.372376] 0 pages cma reserved
>   [  238.372661] 0 pages hwpoisoned
> 
> In another instance (older kernel), I was able to observe this
> (negative page count :/):
>   [  180.896971] Offlined Pages 

[PATCH net-next v11 2/3] mlx4: use new txqueue timeout argument

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin 
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 71c083960a87..43dcbd8214c6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1367,20 +1367,14 @@ static void mlx4_en_tx_timeout(struct net_device *dev, 
unsigned int txqueue)
 {
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
-   int i;
+   struct mlx4_en_tx_ring *tx_ring = priv->tx_ring[TX][txqueue];
 
if (netif_msg_timer(priv))
en_warn(priv, "Tx timeout called on port:%d\n", priv->port);
 
-   for (i = 0; i < priv->tx_ring_num[TX]; i++) {
-   struct mlx4_en_tx_ring *tx_ring = priv->tx_ring[TX][i];
-
-   if (!netif_tx_queue_stopped(netdev_get_tx_queue(dev, i)))
-   continue;
-   en_warn(priv, "TX timeout on queue: %d, QP: 0x%x, CQ: 0x%x, 
Cons: 0x%x, Prod: 0x%x\n",
-   i, tx_ring->qpn, tx_ring->sp_cqn,
-   tx_ring->cons, tx_ring->prod);
-   }
+   en_warn(priv, "TX timeout on queue: %d, QP: 0x%x, CQ: 0x%x, Cons: 0x%x, 
Prod: 0x%x\n",
+   txqueue, tx_ring->qpn, tx_ring->sp_cqn,
+   tx_ring->cons, tx_ring->prod);
 
priv->port_stats.tx_timeout++;
en_dbg(DRV, priv, "Scheduling watchdog\n");
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v11 0/3] netdev: ndo_tx_timeout cleanup

[Michael S. Tsirkin]

Sorry about the churn, v10 was based on net - not on net-next
by mistake.

A bunch of drivers want to know which tx queue triggered a timeout,
and virtio wants to do the same.
We actually have the info to hand, let's just pass it on to drivers.
Note: tested with an experimental virtio patch by Julio.
That patch itself isn't ready yet though, so not included.
Other drivers compiled only.


Michael S. Tsirkin (3):
  netdev: pass the stuck queue to the timeout handler
  mlx4: use new txqueue timeout argument
  netronome: use the new txqueue timeout argument

 arch/m68k/emu/nfeth.c|  2 +-
 arch/um/drivers/net_kern.c   |  2 +-
 arch/um/drivers/vector_kern.c|  2 +-
 arch/xtensa/platforms/iss/network.c  |  2 +-
 drivers/char/pcmcia/synclink_cs.c|  2 +-
 drivers/infiniband/ulp/ipoib/ipoib_main.c|  2 +-
 drivers/message/fusion/mptlan.c  |  2 +-
 drivers/misc/sgi-xp/xpnet.c  |  2 +-
 drivers/net/appletalk/cops.c |  4 ++--
 drivers/net/arcnet/arcdevice.h   |  2 +-
 drivers/net/arcnet/arcnet.c  |  2 +-
 drivers/net/ethernet/3com/3c509.c|  4 ++--
 drivers/net/ethernet/3com/3c515.c|  4 ++--
 drivers/net/ethernet/3com/3c574_cs.c |  4 ++--
 drivers/net/ethernet/3com/3c589_cs.c |  4 ++--
 drivers/net/ethernet/3com/3c59x.c|  4 ++--
 drivers/net/ethernet/3com/typhoon.c  |  2 +-
 drivers/net/ethernet/8390/8390.c |  4 ++--
 drivers/net/ethernet/8390/8390.h |  2 +-
 drivers/net/ethernet/8390/8390p.c|  4 ++--
 drivers/net/ethernet/8390/axnet_cs.c |  4 ++--
 drivers/net/ethernet/8390/lib8390.c  |  2 +-
 drivers/net/ethernet/adaptec/starfire.c  |  4 ++--
 drivers/net/ethernet/agere/et131x.c  |  2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c  |  2 +-
 drivers/net/ethernet/alteon/acenic.c |  4 ++--
 drivers/net/ethernet/amazon/ena/ena_netdev.c |  2 +-
 drivers/net/ethernet/amd/7990.c  |  2 +-
 drivers/net/ethernet/amd/7990.h  |  2 +-
 drivers/net/ethernet/amd/a2065.c |  2 +-
 drivers/net/ethernet/amd/am79c961a.c |  2 +-
 drivers/net/ethernet/amd/amd8111e.c  |  2 +-
 drivers/net/ethernet/amd/ariadne.c   |  2 +-
 drivers/net/ethernet/amd/atarilance.c|  4 ++--
 drivers/net/ethernet/amd/au1000_eth.c|  2 +-
 drivers/net/ethernet/amd/declance.c  |  2 +-
 drivers/net/ethernet/amd/lance.c |  4 ++--
 drivers/net/ethernet/amd/ni65.c  |  4 ++--
 drivers/net/ethernet/amd/nmclan_cs.c |  4 ++--
 drivers/net/ethernet/amd/pcnet32.c   |  4 ++--
 drivers/net/ethernet/amd/sunlance.c  |  2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c |  2 +-
 drivers/net/ethernet/apm/xgene-v2/main.c |  2 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |  2 +-
 drivers/net/ethernet/apple/macmace.c |  4 ++--
 drivers/net/ethernet/atheros/ag71xx.c|  2 +-
 drivers/net/ethernet/atheros/alx/main.c  |  2 +-
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c  |  2 +-
 drivers/net/ethernet/atheros/atl1e/atl1e_main.c  |  2 +-
 drivers/net/ethernet/atheros/atlx/atl2.c |  2 +-
 drivers/net/ethernet/atheros/atlx/atlx.c |  2 +-
 drivers/net/ethernet/broadcom/b44.c  |  2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c   |  2 +-
 drivers/net/ethernet/broadcom/bnx2.c |  2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c  |  2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h  |  2 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt.c|  2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c   |  2 +-
 drivers/net/ethernet/broadcom/sb1250-mac.c   |  4 ++--
 drivers/net/ethernet/broadcom/tg3.c  |  2 +-
 drivers/net/ethernet/calxeda/xgmac.c |  2 +-
 drivers/net/ethernet/cavium/liquidio/lio_main.c  |  2 +-
 .../net/ethernet/cavium/liquidio/lio_vf_main.c   |  2 +-
 .../net/ethernet/cavium/liquidio/lio_vf_rep.c|  4 ++--
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |  2 +-
 drivers/net/ethernet/cirrus/cs89x0.c |  2 +-
 drivers/net/ethernet/cisco/enic/enic_main.c  |  2 +-
 drivers/net/ethernet/cortina/gemini.c|  2 +-
 drivers/net/ethernet/davicom/dm9000.c|  2 +-
 drivers/net/ethernet/dec/tulip/de2104x.c |  2 +-
 drivers/net/ethernet/dec/tulip/tulip_core.c  |  4 ++--
 drivers/net/ethernet/dec/tulip/winbond-840.c |  4 ++--
 drivers/net/ethernet/dlink/dl2k.c|  4 ++--
 drivers/net/ethernet/dlink/sundance.c|  4 ++--
 drivers/net/ethernet/emulex/benet/be_main.c  |  2 +-
 drivers/net/ethernet/ethoc.c 

[PATCH net-next v11 3/3] netronome: use the new txqueue timeout argument

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin 
Acked-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c 
b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index bd305fc6ed5a..d4eeb3b3cf35 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -1324,14 +1324,8 @@ nfp_net_tx_ring_reset(struct nfp_net_dp *dp, struct 
nfp_net_tx_ring *tx_ring)
 static void nfp_net_tx_timeout(struct net_device *netdev, unsigned int txqueue)
 {
struct nfp_net *nn = netdev_priv(netdev);
-   int i;
 
-   for (i = 0; i < nn->dp.netdev->real_num_tx_queues; i++) {
-   if (!netif_tx_queue_stopped(netdev_get_tx_queue(netdev, i)))
-   continue;
-   nn_warn(nn, "TX timeout on ring: %d\n", i);
-   }
-   nn_warn(nn, "TX watchdog timeout\n");
+   nn_warn(nn, "TX watchdog timeout on ring: %u\n", txqueue);
 }
 
 /* Receive processing
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v10 2/3] mlx4: use new txqueue timeout argument

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin 
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index aa348230bd39..2c2ff1f0ea6d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1367,20 +1367,14 @@ static void mlx4_en_tx_timeout(struct net_device *dev, 
unsigned int txqueue)
 {
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
-   int i;
+   struct mlx4_en_tx_ring *tx_ring = priv->tx_ring[TX][txqueue];
 
if (netif_msg_timer(priv))
en_warn(priv, "Tx timeout called on port:%d\n", priv->port);
 
-   for (i = 0; i < priv->tx_ring_num[TX]; i++) {
-   struct mlx4_en_tx_ring *tx_ring = priv->tx_ring[TX][i];
-
-   if (!netif_tx_queue_stopped(netdev_get_tx_queue(dev, i)))
-   continue;
-   en_warn(priv, "TX timeout on queue: %d, QP: 0x%x, CQ: 0x%x, 
Cons: 0x%x, Prod: 0x%x\n",
-   i, tx_ring->qpn, tx_ring->sp_cqn,
-   tx_ring->cons, tx_ring->prod);
-   }
+   en_warn(priv, "TX timeout on queue: %d, QP: 0x%x, CQ: 0x%x, Cons: 0x%x, 
Prod: 0x%x\n",
+   txqueue, tx_ring->qpn, tx_ring->sp_cqn,
+   tx_ring->cons, tx_ring->prod);
 
priv->port_stats.tx_timeout++;
en_dbg(DRV, priv, "Scheduling watchdog\n");
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v10 3/3] netronome: use the new txqueue timeout argument

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin 
Acked-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c 
b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 41a808b14d76..eb1f9bed4833 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -1323,14 +1323,8 @@ nfp_net_tx_ring_reset(struct nfp_net_dp *dp, struct 
nfp_net_tx_ring *tx_ring)
 static void nfp_net_tx_timeout(struct net_device *netdev, unsigned int txqueue)
 {
struct nfp_net *nn = netdev_priv(netdev);
-   int i;
 
-   for (i = 0; i < nn->dp.netdev->real_num_tx_queues; i++) {
-   if (!netif_tx_queue_stopped(netdev_get_tx_queue(netdev, i)))
-   continue;
-   nn_warn(nn, "TX timeout on ring: %d\n", i);
-   }
-   nn_warn(nn, "TX watchdog timeout\n");
+   nn_warn(nn, "TX watchdog timeout on ring: %u\n", txqueue);
 }
 
 /* Receive processing
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v2 4/6] vsock: add vsock_loopback transport

[Stefano Garzarella]

This patch adds a new vsock_loopback transport to handle local
communication.
This transport is based on the loopback implementation of
virtio_transport, so it uses the virtio_transport_common APIs
to interface with the vsock core.

Signed-off-by: Stefano Garzarella 
---
v1 -> v2:
- fixed reverse christmas tree ordering of local variables [Dave]
- changed 'the_vsock_loopback' in a global static variable [Stefan]
- removed RCU synchronization [Stefan]
  It is not needed because the af_vsock keeps a reference to the module
  as long as there are open sockets assigned to the transport
- removed 'loopback' prefix in 'struct vsock_loopback' fields
---
 MAINTAINERS|   1 +
 net/vmw_vsock/Kconfig  |  12 +++
 net/vmw_vsock/Makefile |   1 +
 net/vmw_vsock/vsock_loopback.c | 180 +
 4 files changed, 194 insertions(+)
 create mode 100644 net/vmw_vsock/vsock_loopback.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ce7fd2e7aa1a..a28c77ee6b0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17480,6 +17480,7 @@ F:  net/vmw_vsock/diag.c
 F: net/vmw_vsock/af_vsock_tap.c
 F: net/vmw_vsock/virtio_transport_common.c
 F: net/vmw_vsock/virtio_transport.c
+F: net/vmw_vsock/vsock_loopback.c
 F: drivers/net/vsockmon.c
 F: drivers/vhost/vsock.c
 F: tools/testing/vsock/
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index 8abcb815af2d..56356d2980c8 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -26,6 +26,18 @@ config VSOCKETS_DIAG
 
  Enable this module so userspace applications can query open sockets.
 
+config VSOCKETS_LOOPBACK
+   tristate "Virtual Sockets loopback transport"
+   depends on VSOCKETS
+   default y
+   select VIRTIO_VSOCKETS_COMMON
+   help
+ This module implements a loopback transport for Virtual Sockets,
+ using vmw_vsock_virtio_transport_common.
+
+ To compile this driver as a module, choose M here: the module
+ will be called vsock_loopback. If unsure, say N.
+
 config VMWARE_VMCI_VSOCKETS
tristate "VMware VMCI transport for Virtual Sockets"
depends on VSOCKETS && VMWARE_VMCI
diff --git a/net/vmw_vsock/Makefile b/net/vmw_vsock/Makefile
index 7c6f9a0b67b0..6a943ec95c4a 100644
--- a/net/vmw_vsock/Makefile
+++ b/net/vmw_vsock/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_VMWARE_VMCI_VSOCKETS) += vmw_vsock_vmci_transport.o
 obj-$(CONFIG_VIRTIO_VSOCKETS) += vmw_vsock_virtio_transport.o
 obj-$(CONFIG_VIRTIO_VSOCKETS_COMMON) += vmw_vsock_virtio_transport_common.o
 obj-$(CONFIG_HYPERV_VSOCKETS) += hv_sock.o
+obj-$(CONFIG_VSOCKETS_LOOPBACK) += vsock_loopback.o
 
 vsock-y += af_vsock.o af_vsock_tap.o vsock_addr.o
 
diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_vsock/vsock_loopback.c
new file mode 100644
index ..a45f7ffca8c5
--- /dev/null
+++ b/net/vmw_vsock/vsock_loopback.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* loopback transport for vsock using virtio_transport_common APIs
+ *
+ * Copyright (C) 2013-2019 Red Hat, Inc.
+ * Authors: Asias He 
+ *  Stefan Hajnoczi 
+ *  Stefano Garzarella 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+struct vsock_loopback {
+   struct workqueue_struct *workqueue;
+
+   spinlock_t pkt_list_lock; /* protects pkt_list */
+   struct list_head pkt_list;
+   struct work_struct pkt_work;
+};
+
+static struct vsock_loopback the_vsock_loopback;
+
+static u32 vsock_loopback_get_local_cid(void)
+{
+   return VMADDR_CID_LOCAL;
+}
+
+static int vsock_loopback_send_pkt(struct virtio_vsock_pkt *pkt)
+{
+   struct vsock_loopback *vsock = _vsock_loopback;
+   int len = pkt->len;
+
+   spin_lock_bh(>pkt_list_lock);
+   list_add_tail(>list, >pkt_list);
+   spin_unlock_bh(>pkt_list_lock);
+
+   queue_work(vsock->workqueue, >pkt_work);
+
+   return len;
+}
+
+static int vsock_loopback_cancel_pkt(struct vsock_sock *vsk)
+{
+   struct vsock_loopback *vsock = _vsock_loopback;
+   struct virtio_vsock_pkt *pkt, *n;
+   LIST_HEAD(freeme);
+
+   spin_lock_bh(>pkt_list_lock);
+   list_for_each_entry_safe(pkt, n, >pkt_list, list) {
+   if (pkt->vsk != vsk)
+   continue;
+   list_move(>list, );
+   }
+   spin_unlock_bh(>pkt_list_lock);
+
+   list_for_each_entry_safe(pkt, n, , list) {
+   list_del(>list);
+   virtio_transport_free_pkt(pkt);
+   }
+
+   return 0;
+}
+
+static struct virtio_transport loopback_transport = {
+   .transport = {
+   .module   = THIS_MODULE,
+
+   .get_local_cid= vsock_loopback_get_local_cid,
+
+   .init = virtio_transport_do_socket_init,
+   .destruct = virtio_transport_destruct,
+   .release  = virtio_transport_release,
+  

[PATCH net-next v2 5/6] vsock: use local transport when it is loaded

[Stefano Garzarella]

Now that we have a transport that can handle the local communication,
we can use it when it is loaded.

A socket will use the local transport (loopback) when the remote
CID is:
- equal to VMADDR_CID_LOCAL
- or equal to transport_g2h->get_local_cid(), if transport_g2h
  is loaded (this allows us to keep the same behavior implemented
  by virtio and vmci transports)
- or equal to VMADDR_CID_HOST, if transport_g2h is not loaded

Signed-off-by: Stefano Garzarella 
---
v1 -> v2:
- use G2H transport when local transport is not loaded and remote cid
  is VMADDR_CID_LOCAL [Stefan]
---
 net/vmw_vsock/af_vsock.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 3da0749a0c97..9c5b2a91baad 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -388,6 +388,21 @@ void vsock_enqueue_accept(struct sock *listener, struct 
sock *connected)
 }
 EXPORT_SYMBOL_GPL(vsock_enqueue_accept);
 
+static bool vsock_use_local_transport(unsigned int remote_cid)
+{
+   if (!transport_local)
+   return false;
+
+   if (remote_cid == VMADDR_CID_LOCAL)
+   return true;
+
+   if (transport_g2h) {
+   return remote_cid == transport_g2h->get_local_cid();
+   } else {
+   return remote_cid == VMADDR_CID_HOST;
+   }
+}
+
 static void vsock_deassign_transport(struct vsock_sock *vsk)
 {
if (!vsk->transport)
@@ -404,9 +419,9 @@ static void vsock_deassign_transport(struct vsock_sock *vsk)
  * (e.g. during the connect() or when a connection request on a listener
  * socket is received).
  * The vsk->remote_addr is used to decide which transport to use:
+ *  - remote CID == VMADDR_CID_LOCAL or g2h->local_cid or VMADDR_CID_HOST if
+ *g2h is not loaded, will use local transport;
  *  - remote CID <= VMADDR_CID_HOST will use guest->host transport;
- *  - remote CID == local_cid (guest->host transport) will use guest->host
- *transport for loopback (host->guest transports don't support loopback);
  *  - remote CID > VMADDR_CID_HOST will use host->guest transport;
  */
 int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)
@@ -421,9 +436,9 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct 
vsock_sock *psk)
new_transport = transport_dgram;
break;
case SOCK_STREAM:
-   if (remote_cid <= VMADDR_CID_HOST ||
-   (transport_g2h &&
-remote_cid == transport_g2h->get_local_cid()))
+   if (vsock_use_local_transport(remote_cid))
+   new_transport = transport_local;
+   else if (remote_cid <= VMADDR_CID_HOST)
new_transport = transport_g2h;
else
new_transport = transport_h2g;
@@ -466,6 +481,9 @@ bool vsock_find_cid(unsigned int cid)
if (transport_h2g && cid == VMADDR_CID_HOST)
return true;
 
+   if (transport_local && cid == VMADDR_CID_LOCAL)
+   return true;
+
return false;
 }
 EXPORT_SYMBOL_GPL(vsock_find_cid);
-- 
2.23.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v2 6/6] vsock/virtio: remove loopback handling

[Stefano Garzarella]

We can remove the loopback handling from virtio_transport,
because now the vsock core is able to handle local communication
using the new vsock_loopback device.

Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Stefano Garzarella 
---
 net/vmw_vsock/virtio_transport.c | 61 ++--
 1 file changed, 2 insertions(+), 59 deletions(-)

diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 1458c5c8b64d..dfbaf6bd8b1c 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -44,10 +44,6 @@ struct virtio_vsock {
spinlock_t send_pkt_list_lock;
struct list_head send_pkt_list;
 
-   struct work_struct loopback_work;
-   spinlock_t loopback_list_lock; /* protects loopback_list */
-   struct list_head loopback_list;
-
atomic_t queued_replies;
 
/* The following fields are protected by rx_lock.  vqs[VSOCK_VQ_RX]
@@ -86,20 +82,6 @@ static u32 virtio_transport_get_local_cid(void)
return ret;
 }
 
-static int virtio_transport_send_pkt_loopback(struct virtio_vsock *vsock,
- struct virtio_vsock_pkt *pkt)
-{
-   int len = pkt->len;
-
-   spin_lock_bh(>loopback_list_lock);
-   list_add_tail(>list, >loopback_list);
-   spin_unlock_bh(>loopback_list_lock);
-
-   queue_work(virtio_vsock_workqueue, >loopback_work);
-
-   return len;
-}
-
 static void
 virtio_transport_send_pkt_work(struct work_struct *work)
 {
@@ -194,7 +176,8 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
}
 
if (le64_to_cpu(pkt->hdr.dst_cid) == vsock->guest_cid) {
-   len = virtio_transport_send_pkt_loopback(vsock, pkt);
+   virtio_transport_free_pkt(pkt);
+   len = -ENODEV;
goto out_rcu;
}
 
@@ -502,33 +485,6 @@ static struct virtio_transport virtio_transport = {
.send_pkt = virtio_transport_send_pkt,
 };
 
-static void virtio_transport_loopback_work(struct work_struct *work)
-{
-   struct virtio_vsock *vsock =
-   container_of(work, struct virtio_vsock, loopback_work);
-   LIST_HEAD(pkts);
-
-   spin_lock_bh(>loopback_list_lock);
-   list_splice_init(>loopback_list, );
-   spin_unlock_bh(>loopback_list_lock);
-
-   mutex_lock(>rx_lock);
-
-   if (!vsock->rx_run)
-   goto out;
-
-   while (!list_empty()) {
-   struct virtio_vsock_pkt *pkt;
-
-   pkt = list_first_entry(, struct virtio_vsock_pkt, list);
-   list_del_init(>list);
-
-   virtio_transport_recv_pkt(_transport, pkt);
-   }
-out:
-   mutex_unlock(>rx_lock);
-}
-
 static void virtio_transport_rx_work(struct work_struct *work)
 {
struct virtio_vsock *vsock =
@@ -633,13 +589,10 @@ static int virtio_vsock_probe(struct virtio_device *vdev)
mutex_init(>event_lock);
spin_lock_init(>send_pkt_list_lock);
INIT_LIST_HEAD(>send_pkt_list);
-   spin_lock_init(>loopback_list_lock);
-   INIT_LIST_HEAD(>loopback_list);
INIT_WORK(>rx_work, virtio_transport_rx_work);
INIT_WORK(>tx_work, virtio_transport_tx_work);
INIT_WORK(>event_work, virtio_transport_event_work);
INIT_WORK(>send_pkt_work, virtio_transport_send_pkt_work);
-   INIT_WORK(>loopback_work, virtio_transport_loopback_work);
 
mutex_lock(>tx_lock);
vsock->tx_run = true;
@@ -720,22 +673,12 @@ static void virtio_vsock_remove(struct virtio_device 
*vdev)
}
spin_unlock_bh(>send_pkt_list_lock);
 
-   spin_lock_bh(>loopback_list_lock);
-   while (!list_empty(>loopback_list)) {
-   pkt = list_first_entry(>loopback_list,
-  struct virtio_vsock_pkt, list);
-   list_del(>list);
-   virtio_transport_free_pkt(pkt);
-   }
-   spin_unlock_bh(>loopback_list_lock);
-
/* Delete virtqueues and flush outstanding callbacks if any */
vdev->config->del_vqs(vdev);
 
/* Other works can be queued before 'config->del_vqs()', so we flush
 * all works before to free the vsock object to avoid use after free.
 */
-   flush_work(>loopback_work);
flush_work(>rx_work);
flush_work(>tx_work);
flush_work(>event_work);
-- 
2.23.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v2 2/6] vsock: add VMADDR_CID_LOCAL definition

[Stefano Garzarella]

The VMADDR_CID_RESERVED (1) was used by VMCI, but now it is not
used anymore, so we can reuse it for local communication
(loopback) adding the new well-know CID: VMADDR_CID_LOCAL.

Cc: Jorgen Hansen 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Jorgen Hansen 
Signed-off-by: Stefano Garzarella 
---
 include/uapi/linux/vm_sockets.h | 8 +---
 net/vmw_vsock/vmci_transport.c  | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index 68d57c5e99bc..fd0ed7221645 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -99,11 +99,13 @@
 
 #define VMADDR_CID_HYPERVISOR 0
 
-/* This CID is specific to VMCI and can be considered reserved (even VMCI
- * doesn't use it anymore, it's a legacy value from an older release).
+/* Use this as the destination CID in an address when referring to the
+ * local communication (loopback).
+ * (This was VMADDR_CID_RESERVED, but even VMCI doesn't use it anymore,
+ * it was a legacy value from an older release).
  */
 
-#define VMADDR_CID_RESERVED 1
+#define VMADDR_CID_LOCAL 1
 
 /* Use this as the destination CID in an address when referring to the host
  * (any process other than the hypervisor).  VMCI relies on it being 2, but
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 644d32e43d23..4b8b1150a738 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -648,7 +648,7 @@ static int vmci_transport_recv_dgram_cb(void *data, struct 
vmci_datagram *dg)
 static bool vmci_transport_stream_allow(u32 cid, u32 port)
 {
static const u32 non_socket_contexts[] = {
-   VMADDR_CID_RESERVED,
+   VMADDR_CID_LOCAL,
};
int i;
 
-- 
2.23.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v2 1/6] vsock/virtio_transport_common: remove unused virtio header includes

[Stefano Garzarella]

We can remove virtio header includes, because virtio_transport_common
doesn't use virtio API, but provides common functions to interface
virtio/vhost transports with the af_vsock core, and to handle
the protocol.

Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Stefano Garzarella 
---
 net/vmw_vsock/virtio_transport_common.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/net/vmw_vsock/virtio_transport_common.c 
b/net/vmw_vsock/virtio_transport_common.c
index e5ea29c6bca7..0e20b0f6eb65 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -11,9 +11,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 
-- 
2.23.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v2 0/6] vsock: add local transport support

[Stefano Garzarella]

v2:
 - style fixes [Dave]
 - removed RCU sync and changed 'the_vsock_loopback' in a global
   static variable [Stefan]
 - use G2H transport when local transport is not loaded and remote cid
   is VMADDR_CID_LOCAL [Stefan]
 - rebased on net-next

v1: https://patchwork.kernel.org/cover/11251735/

This series introduces a new transport (vsock_loopback) to handle
local communication.
This could be useful to test vsock core itself and to allow developers
to test their applications without launching a VM.

Before this series, vmci and virtio transports allowed this behavior,
but only in the guest.
We are moving the loopback handling in a new transport, because it
might be useful to provide this feature also in the host or when
no H2G/G2H transports (hyperv, virtio, vmci) are loaded.

The user can use the loopback with the new VMADDR_CID_LOCAL (that
replaces VMADDR_CID_RESERVED) in any condition.
Otherwise, if the G2H transport is loaded, it can also use the guest
local CID as previously supported by vmci and virtio transports.
If G2H transport is not loaded, the user can also use VMADDR_CID_HOST
for local communication.

Patch 1 is a cleanup to build virtio_transport_common without virtio
Patch 2 adds the new VMADDR_CID_LOCAL, replacing VMADDR_CID_RESERVED
Patch 3 adds a new feature flag to register a loopback transport
Patch 4 adds the new vsock_loopback transport based on the loopback
implementation of virtio_transport
Patch 5 implements the logic to use the local transport for loopback
communication
Patch 6 removes the loopback from virtio_transport

Stefano Garzarella (6):
  vsock/virtio_transport_common: remove unused virtio header includes
  vsock: add VMADDR_CID_LOCAL definition
  vsock: add local transport support in the vsock core
  vsock: add vsock_loopback transport
  vsock: use local transport when it is loaded
  vsock/virtio: remove loopback handling

 MAINTAINERS |   1 +
 include/net/af_vsock.h  |   2 +
 include/uapi/linux/vm_sockets.h |   8 +-
 net/vmw_vsock/Kconfig   |  12 ++
 net/vmw_vsock/Makefile  |   1 +
 net/vmw_vsock/af_vsock.c|  45 +-
 net/vmw_vsock/virtio_transport.c|  61 +---
 net/vmw_vsock/virtio_transport_common.c |   3 -
 net/vmw_vsock/vmci_transport.c  |   2 +-
 net/vmw_vsock/vsock_loopback.c  | 180 
 10 files changed, 243 insertions(+), 72 deletions(-)
 create mode 100644 net/vmw_vsock/vsock_loopback.c

-- 
2.23.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net-next v2 3/6] vsock: add local transport support in the vsock core

[Stefano Garzarella]

This patch allows to register a transport able to handle
local communication (loopback).

Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Stefano Garzarella 
---
 include/net/af_vsock.h   |  2 ++
 net/vmw_vsock/af_vsock.c | 17 -
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index 4206dc6d813f..b1c717286993 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -98,6 +98,8 @@ struct vsock_transport_send_notify_data {
 #define VSOCK_TRANSPORT_F_G2H  0x0002
 /* Transport provides DGRAM communication */
 #define VSOCK_TRANSPORT_F_DGRAM0x0004
+/* Transport provides local (loopback) communication */
+#define VSOCK_TRANSPORT_F_LOCAL0x0008
 
 struct vsock_transport {
struct module *module;
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 74db4cd637a7..3da0749a0c97 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -136,6 +136,8 @@ static const struct vsock_transport *transport_h2g;
 static const struct vsock_transport *transport_g2h;
 /* Transport used for DGRAM communication */
 static const struct vsock_transport *transport_dgram;
+/* Transport used for local communication */
+static const struct vsock_transport *transport_local;
 static DEFINE_MUTEX(vsock_register_mutex);
 
 / UTILS /
@@ -2137,7 +2139,7 @@ EXPORT_SYMBOL_GPL(vsock_core_get_transport);
 
 int vsock_core_register(const struct vsock_transport *t, int features)
 {
-   const struct vsock_transport *t_h2g, *t_g2h, *t_dgram;
+   const struct vsock_transport *t_h2g, *t_g2h, *t_dgram, *t_local;
int err = mutex_lock_interruptible(_register_mutex);
 
if (err)
@@ -2146,6 +2148,7 @@ int vsock_core_register(const struct vsock_transport *t, 
int features)
t_h2g = transport_h2g;
t_g2h = transport_g2h;
t_dgram = transport_dgram;
+   t_local = transport_local;
 
if (features & VSOCK_TRANSPORT_F_H2G) {
if (t_h2g) {
@@ -2171,9 +2174,18 @@ int vsock_core_register(const struct vsock_transport *t, 
int features)
t_dgram = t;
}
 
+   if (features & VSOCK_TRANSPORT_F_LOCAL) {
+   if (t_local) {
+   err = -EBUSY;
+   goto err_busy;
+   }
+   t_local = t;
+   }
+
transport_h2g = t_h2g;
transport_g2h = t_g2h;
transport_dgram = t_dgram;
+   transport_local = t_local;
 
 err_busy:
mutex_unlock(_register_mutex);
@@ -2194,6 +2206,9 @@ void vsock_core_unregister(const struct vsock_transport 
*t)
if (transport_dgram == t)
transport_dgram = NULL;
 
+   if (transport_local == t)
+   transport_local = NULL;
+
mutex_unlock(_register_mutex);
 }
 EXPORT_SYMBOL_GPL(vsock_core_unregister);
-- 
2.23.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] drm/virtio: fix mmap page attributes

[Thomas Zimmermann]

Hi

Am 10.12.19 um 09:57 schrieb Gerd Hoffmann:
> virtio-gpu uses cached mappings.  shmem helpers use writecombine though.
> So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak
> vm_page_prot accordingly.
> 
> Reported-by: Gurchetan Singh 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/virtio/virtgpu_object.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index 017a9e0fc3bb..158610902054 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -75,6 +75,22 @@ static void virtio_gpu_free_object(struct drm_gem_object 
> *obj)
>   drm_gem_shmem_free_object(obj);
>  }
>  
> +static int virtio_gpu_gem_mmap(struct drm_gem_object *obj, struct 
> vm_area_struct *vma)
> +{
> + pgprot_t prot;
> + int ret;
> +
> + ret = drm_gem_shmem_mmap(obj, vma);
> + if (ret < 0)
> + return ret;
> +
> + /* virtio-gpu needs normal caching, so clear writecombine */
> + prot = vm_get_page_prot(vma->vm_flags);
> + prot = pgprot_decrypted(prot);
> + vma->vm_page_prot = prot;
> + return 0;
> +}

There's similar code in udl, [1] which still uses writecombine for
imported buffers. Virtio does not need this?

Aside from this, do you think we could handle all special cases within
shmem?

Best regards
Thomas

[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/udl/udl_gem.c?id=28ecf94a6f1072fc4744c06f5b3d267297125b37#n20

> +
>  static const struct drm_gem_object_funcs virtio_gpu_gem_funcs = {
>   .free = virtio_gpu_free_object,
>   .open = virtio_gpu_gem_object_open,
> @@ -86,7 +102,7 @@ static const struct drm_gem_object_funcs 
> virtio_gpu_gem_funcs = {
>   .get_sg_table = drm_gem_shmem_get_sg_table,
>   .vmap = drm_gem_shmem_vmap,
>   .vunmap = drm_gem_shmem_vunmap,
> - .mmap = _gem_shmem_mmap,
> + .mmap = _gpu_gem_mmap,
>  };
>  
>  struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev,
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH] drm/virtio: fix mmap page attributes

[Gerd Hoffmann]

virtio-gpu uses cached mappings.  shmem helpers use writecombine though.
So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak
vm_page_prot accordingly.

Reported-by: Gurchetan Singh 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_object.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 017a9e0fc3bb..158610902054 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -75,6 +75,22 @@ static void virtio_gpu_free_object(struct drm_gem_object 
*obj)
drm_gem_shmem_free_object(obj);
 }
 
+static int virtio_gpu_gem_mmap(struct drm_gem_object *obj, struct 
vm_area_struct *vma)
+{
+   pgprot_t prot;
+   int ret;
+
+   ret = drm_gem_shmem_mmap(obj, vma);
+   if (ret < 0)
+   return ret;
+
+   /* virtio-gpu needs normal caching, so clear writecombine */
+   prot = vm_get_page_prot(vma->vm_flags);
+   prot = pgprot_decrypted(prot);
+   vma->vm_page_prot = prot;
+   return 0;
+}
+
 static const struct drm_gem_object_funcs virtio_gpu_gem_funcs = {
.free = virtio_gpu_free_object,
.open = virtio_gpu_gem_object_open,
@@ -86,7 +102,7 @@ static const struct drm_gem_object_funcs 
virtio_gpu_gem_funcs = {
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
-   .mmap = _gem_shmem_mmap,
+   .mmap = _gpu_gem_mmap,
 };
 
 struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev,
-- 
2.18.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization