[PATCH AUTOSEL 4.4 27/33] Fix use after free in get_capset_info callback.

2020-10-18 Thread Sasha Levin 
From: Doug Horn 

[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]

If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.

Signed-off-by: Doug Horn 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c |  2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 10 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 06496a1281622..476b9993b0682 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct 
virtio_gpu_device *vgdev,
 vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+   spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+   spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 772a5a3b0ce1a..18e8fcad6690b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -596,9 +596,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct 
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
 
spin_lock(>display_info_lock);
-   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
-   vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
-   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   if (vgdev->capsets) {
+   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+   vgdev->capsets[i].max_version = 
le32_to_cpu(resp->capset_max_version);
+   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   } else {
+   DRM_ERROR("invalid capset memory.");
+   }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
 }
-- 
2.25.1

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

[PATCH AUTOSEL 4.9 35/41] Fix use after free in get_capset_info callback.

2020-10-18 Thread Sasha Levin 
From: Doug Horn 

[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]

If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.

Signed-off-by: Doug Horn 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c |  2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 10 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 036b0fbae0fb7..ba7855da7c7f6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct 
virtio_gpu_device *vgdev,
 vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+   spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+   spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 772a5a3b0ce1a..18e8fcad6690b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -596,9 +596,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct 
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
 
spin_lock(>display_info_lock);
-   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
-   vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
-   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   if (vgdev->capsets) {
+   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+   vgdev->capsets[i].max_version = 
le32_to_cpu(resp->capset_max_version);
+   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   } else {
+   DRM_ERROR("invalid capset memory.");
+   }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
 }
-- 
2.25.1

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

Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-18 Thread Joe Perches 
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > clang has a number of useful, new warnings see
> > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
> >  
> 
> Please get your IT department to remove that stupidity.  If you can't,
> please send email from a non-Red Hat email address.

I didn't get it this way, neither did lore.
It's on your end.

https://lore.kernel.org/lkml/20201017160928.12698-1-t...@redhat.com/

> I don't understand why this is a useful warning to fix.

Precision in coding style intent and code minimization
would be the biggest factors IMO.

> What actual problem is caused by the code below?

Obviously none.


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

[PATCH AUTOSEL 4.14 42/52] Fix use after free in get_capset_info callback.

2020-10-18 Thread Sasha Levin 
From: Doug Horn 

[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]

If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.

Signed-off-by: Doug Horn 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c |  2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 10 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 6400506a06b07..bed450fbb2168 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct 
virtio_gpu_device *vgdev,
 vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+   spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+   spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index a3be65e689fd2..a956c73ea85e5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -563,9 +563,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct 
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
 
spin_lock(>display_info_lock);
-   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
-   vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
-   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   if (vgdev->capsets) {
+   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+   vgdev->capsets[i].max_version = 
le32_to_cpu(resp->capset_max_version);
+   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   } else {
+   DRM_ERROR("invalid capset memory.");
+   }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
 }
-- 
2.25.1

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

[PATCH AUTOSEL 4.19 45/56] Fix use after free in get_capset_info callback.

2020-10-18 Thread Sasha Levin 
From: Doug Horn 

[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]

If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.

Signed-off-by: Doug Horn 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c |  2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 10 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 65060c08522d7..22397a23780c0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct 
virtio_gpu_device *vgdev,
 vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+   spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+   spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 608906f06cedd..3e72c6dac0ffe 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -566,9 +566,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct 
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
 
spin_lock(>display_info_lock);
-   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
-   vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
-   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   if (vgdev->capsets) {
+   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+   vgdev->capsets[i].max_version = 
le32_to_cpu(resp->capset_max_version);
+   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   } else {
+   DRM_ERROR("invalid capset memory.");
+   }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
 }
-- 
2.25.1

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

[PATCH AUTOSEL 5.4 60/80] Fix use after free in get_capset_info callback.

2020-10-18 Thread Sasha Levin 
From: Doug Horn 

[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]

If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.

Signed-off-by: Doug Horn 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c |  2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 10 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index c190702fab726..6dcc05ab31eba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -96,8 +96,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device 
*vgdev,
 vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+   spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+   spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 7ac20490e1b4c..92022a83bbd5e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -572,9 +572,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct 
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
 
spin_lock(>display_info_lock);
-   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
-   vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
-   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   if (vgdev->capsets) {
+   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+   vgdev->capsets[i].max_version = 
le32_to_cpu(resp->capset_max_version);
+   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   } else {
+   DRM_ERROR("invalid capset memory.");
+   }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
 }
-- 
2.25.1

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

[PATCH AUTOSEL 5.8 076/101] Fix use after free in get_capset_info callback.

2020-10-18 Thread Sasha Levin 
From: Doug Horn 

[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]

If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.

Signed-off-by: Doug Horn 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c |  2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 10 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 0a5c8cf409fb8..dc8cb8dfce58e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -80,8 +80,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device 
*vgdev,
 vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+   spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+   spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9e663a5d99526..2517450bf46ba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,9 +684,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct 
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
 
spin_lock(>display_info_lock);
-   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
-   vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
-   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   if (vgdev->capsets) {
+   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+   vgdev->capsets[i].max_version = 
le32_to_cpu(resp->capset_max_version);
+   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   } else {
+   DRM_ERROR("invalid capset memory.");
+   }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
 }
-- 
2.25.1

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

[PATCH AUTOSEL 5.9 082/111] Fix use after free in get_capset_info callback.

2020-10-18 Thread Sasha Levin 
From: Doug Horn 

[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]

If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.

Signed-off-by: Doug Horn 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c |  2 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 10 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 4d944a0dff3e9..fdd7671a7b126 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -80,8 +80,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device 
*vgdev,
 vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+   spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+   spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 53af60d484a44..9d2abdbd865a7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,9 +684,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct 
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
 
spin_lock(>display_info_lock);
-   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
-   vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
-   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   if (vgdev->capsets) {
+   vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+   vgdev->capsets[i].max_version = 
le32_to_cpu(resp->capset_max_version);
+   vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+   } else {
+   DRM_ERROR("invalid capset memory.");
+   }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
 }
-- 
2.25.1

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

Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-18 Thread Matthew Wilcox 
On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote:
> On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > clang has a number of useful, new warnings see
> > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
> > >  
> > 
> > Please get your IT department to remove that stupidity.  If you
> > can't, please send email from a non-Red Hat email address.
> 
> Actually, the problem is at Oracle's end somewhere in the ocfs2 list
> ... if you could fix it, that would be great.  The usual real mailing
> lists didn't get this transformation
> 
> https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/
> 
> but the ocfs2 list archive did:
> 
> https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html
> 
> I bet Oracle IT has put some spam filter on the list that mangles URLs
> this way.

*sigh*.  I'm sure there's a way.  I've raised it with someone who should
be able to fix it.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-18 Thread Matthew Wilcox 
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> clang has a number of useful, new warnings see
> https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
>  

Please get your IT department to remove that stupidity.  If you can't,
please send email from a non-Red Hat email address.

I don't understand why this is a useful warning to fix.  What actual
problem is caused by the code below?

> return and break
> 
>   switch (c->x86_vendor) {
>   case X86_VENDOR_INTEL:
>   intel_p5_mcheck_init(c);
>   return 1;
> - break;

Sure, it's unnecessary, but it's not masking a bug.  It's not unclear.
Why do we want to enable this warning?

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

Re: [PATCH v1 00/29] virtio-mem: Big Block Mode (BBM)

2020-10-18 Thread David Hildenbrand 

> Am 18.10.2020 um 14:50 schrieb Wei Yang :
> 
> On Mon, Oct 12, 2020 at 02:52:54PM +0200, David Hildenbrand wrote:
>> virtio-mem currently only supports device block sizes that span at most
>> a single Linux memory block. For example, gigantic pages in the hypervisor
>> result on x86-64 in a device block size of 1 GiB - when the Linux memory
>> block size is 128 MiB, we cannot support such devices (we fail loading the
>> driver). Of course, we want to support any device block size in any Linux
>> VM.
>> 
>> Bigger device block sizes will become especially important once supporting
>> VFIO in QEMU - each device block has to be mapped separately, and the
>> maximum number of mappings for VFIO is 64k. So we usually want blocks in
>> the gigabyte range when wanting to grow the VM big.
>> 
>> This series:
>> - Performs some cleanups
>> - Factors out existing Sub Block Mode (SBM)
>> - Implements memory hot(un)plug in Big Block Mode (BBM)
>> 
>> I need one core-mm change, to make offline_and_remove_memory() eat bigger
>> chunks.
>> 
>> This series is based on "next-20201009" and can be found at:
>>g...@gitlab.com:virtio-mem/linux.git virtio-mem-dbm-v1
>> 
> 
> I am trying to apply this patch set, while found I can't 'git fetch' this
> repo. Is there any other repo I would apply this patch set?
> 

Sorry I tool the wrong repo. It‘s on my github:

https://github.com/davidhildenbrand/linux/tree/virtio-mem-dbm-v1

> -- 
> Wei Yang
> Help you, Help me
> 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v1 00/29] virtio-mem: Big Block Mode (BBM)

2020-10-18 Thread David Hildenbrand 

> Am 18.10.2020 um 17:29 schrieb Michael S. Tsirkin :
> 
> On Mon, Oct 12, 2020 at 02:52:54PM +0200, David Hildenbrand wrote:
>> virtio-mem currently only supports device block sizes that span at most
>> a single Linux memory block. For example, gigantic pages in the hypervisor
>> result on x86-64 in a device block size of 1 GiB - when the Linux memory
>> block size is 128 MiB, we cannot support such devices (we fail loading the
>> driver). Of course, we want to support any device block size in any Linux
>> VM.
>> 
>> Bigger device block sizes will become especially important once supporting
>> VFIO in QEMU - each device block has to be mapped separately, and the
>> maximum number of mappings for VFIO is 64k. So we usually want blocks in
>> the gigabyte range when wanting to grow the VM big.
> 
> I guess it missed this Linux right? There's an mm change which did not
> get an ack from mm mainatiners, so I can't merge it ...

No issue, I was targeting 5.11 either way! I‘ll resend based on linus‘ tree now 
that all prereqs are upstream.

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

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

2020-10-18 Thread Andy Lutomirski 
On Sun, Oct 18, 2020 at 8:59 AM Michael S. Tsirkin  wrote:
>
> On Sun, Oct 18, 2020 at 08:54:36AM -0700, Andy Lutomirski wrote:
> > On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin  wrote:
> > >
> > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote:
> > > > 4c. The guest kernel maintains an array of physical addresses that are
> > > > MADV_WIPEONFORK. The hypervisor knows about this array and its
> > > > location through whatever protocol, and before resuming a
> > > > moved/snapshotted/duplicated VM, it takes the responsibility for
> > > > memzeroing this memory. The huge pro here would be that this
> > > > eliminates all races, and reduces complexity quite a bit, because the
> > > > hypervisor can perfectly synchronize its bringup (and SMP bringup)
> > > > with this, and it can even optimize things like on-disk memory
> > > > snapshots to simply not write out those pages to disk.
> > > >
> > > > A 4c-like approach seems like it'd be a lot of bang for the buck -- we
> > > > reuse the existing mechanism (MADV_WIPEONFORK), so there's no new
> > > > userspace API to deal with, and it'd be race free, and eliminate a lot
> > > > of kernel complexity.
> > >
> > > Clearly this has a chance to break applications, right?
> > > If there's an app that uses this as a non-system-calls way
> > > to find out whether there was a fork, it will break
> > > when wipe triggers without a fork ...
> > > For example, imagine:
> > >
> > > MADV_WIPEONFORK
> > > copy secret data to MADV_DONTFORK
> > > fork
> > >
> > >
> > > used to work, with this change it gets 0s instead of the secret data.
> > >
> > >
> > > I am also not sure it's wise to expose each guest process
> > > to the hypervisor like this. E.g. each process needs a
> > > guest physical address of its own then. This is a finite resource.
> > >
> > >
> > > The mmap interface proposed here is somewhat baroque, but it is
> > > certainly simple to implement ...
> >
> > Wipe of fork/vmgenid/whatever could end up being much more problematic
> > than it naively appears -- it could be wiped in the middle of a read.
> > Either the API needs to handle this cleanly, or we need something more
> > aggressive like signal-on-fork.
> >
> > --Andy
>
>
> Right, it's not on fork, it's actually when process is snapshotted.
>
> If we assume it's CRIU we care about, then I
> wonder what's wrong with something like
> MADV_CHANGEONPTRACE_SEIZE
> and basically say it's X bytes which change the value...

I feel like we may be approaching this from the wrong end.  Rather
than saying "what data structure can the kernel expose that might
plausibly be useful", how about we try identifying some specific
userspace needs and see what a good solution could look like.  I can
identify two major cryptographic use cases:

1. A userspace RNG.  The API exposed by the userspace end is a
function that generates random numbers.  The userspace code in turn
wants to know some things from the kernel: it wants some
best-quality-available random seed data from the kernel (and possibly
an indication of how good it is) as well as an indication of whether
the userspace memory may have been cloned or rolled back, or, failing
that, an indication of whether a reseed is needed.  Userspace could
implement a wide variety of algorithms on top depending on its goals
and compliance requirements, but the end goal is for the userspace
part to be very, very fast.

2. A userspace crypto stack that wants to avoid shooting itself in the
foot due to inadvertently doing the same thing twice.  For example, an
AES-GCM stack does not want to reuse an IV, *expecially* if there is
even the slightest chance that it might reuse the IV for different
data.  This use case doesn't necessarily involve random numbers, but,
if anything, it needs to be even faster than #1.

The threats here are not really the same.  For #1, a userspace RNG
should be able to recover from a scenario in which an adversary clones
the entire process *and gets to own the clone*.  For example, in
Android, an adversary can often gain complete control of a fork of the
zygote -- this shouldn't adversely affect the security properties of
other forks.  Similarly, a server farm could operate by having one
booted server that is cloned to create more workers.  Those clones
could be provisioned with secrets and permissions post-clone, and at
attacker gaining control of a fresh clone could be considered
acceptable.  For #2, in contrast, if an adversary gains control of a
clone of an AES-GCM session, they learn the key outright -- the
relevant attack scenario is that the adversary gets to interact with
two clones without compromising either clone per se.

It's worth noting that, in both cases, there could possibly be more
than one instance of an RNG or an AES-GCM session in the same process.
This means that using signals is awkward but not necessarily
impossibly.  (This is an area in which Linux, and POSIX in general, is
much weaker than Windows.)

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

2020-10-18 Thread Michael S. Tsirkin 
On Sun, Oct 18, 2020 at 08:54:36AM -0700, Andy Lutomirski wrote:
> On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin  wrote:
> >
> > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote:
> > > 4c. The guest kernel maintains an array of physical addresses that are
> > > MADV_WIPEONFORK. The hypervisor knows about this array and its
> > > location through whatever protocol, and before resuming a
> > > moved/snapshotted/duplicated VM, it takes the responsibility for
> > > memzeroing this memory. The huge pro here would be that this
> > > eliminates all races, and reduces complexity quite a bit, because the
> > > hypervisor can perfectly synchronize its bringup (and SMP bringup)
> > > with this, and it can even optimize things like on-disk memory
> > > snapshots to simply not write out those pages to disk.
> > >
> > > A 4c-like approach seems like it'd be a lot of bang for the buck -- we
> > > reuse the existing mechanism (MADV_WIPEONFORK), so there's no new
> > > userspace API to deal with, and it'd be race free, and eliminate a lot
> > > of kernel complexity.
> >
> > Clearly this has a chance to break applications, right?
> > If there's an app that uses this as a non-system-calls way
> > to find out whether there was a fork, it will break
> > when wipe triggers without a fork ...
> > For example, imagine:
> >
> > MADV_WIPEONFORK
> > copy secret data to MADV_DONTFORK
> > fork
> >
> >
> > used to work, with this change it gets 0s instead of the secret data.
> >
> >
> > I am also not sure it's wise to expose each guest process
> > to the hypervisor like this. E.g. each process needs a
> > guest physical address of its own then. This is a finite resource.
> >
> >
> > The mmap interface proposed here is somewhat baroque, but it is
> > certainly simple to implement ...
> 
> Wipe of fork/vmgenid/whatever could end up being much more problematic
> than it naively appears -- it could be wiped in the middle of a read.
> Either the API needs to handle this cleanly, or we need something more
> aggressive like signal-on-fork.
> 
> --Andy


Right, it's not on fork, it's actually when process is snapshotted.

If we assume it's CRIU we care about, then I
wonder what's wrong with something like
MADV_CHANGEONPTRACE_SEIZE
and basically say it's X bytes which change the value...


-- 
MST

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

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

2020-10-18 Thread Andy Lutomirski 
On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin  wrote:
>
> On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote:
> > 4c. The guest kernel maintains an array of physical addresses that are
> > MADV_WIPEONFORK. The hypervisor knows about this array and its
> > location through whatever protocol, and before resuming a
> > moved/snapshotted/duplicated VM, it takes the responsibility for
> > memzeroing this memory. The huge pro here would be that this
> > eliminates all races, and reduces complexity quite a bit, because the
> > hypervisor can perfectly synchronize its bringup (and SMP bringup)
> > with this, and it can even optimize things like on-disk memory
> > snapshots to simply not write out those pages to disk.
> >
> > A 4c-like approach seems like it'd be a lot of bang for the buck -- we
> > reuse the existing mechanism (MADV_WIPEONFORK), so there's no new
> > userspace API to deal with, and it'd be race free, and eliminate a lot
> > of kernel complexity.
>
> Clearly this has a chance to break applications, right?
> If there's an app that uses this as a non-system-calls way
> to find out whether there was a fork, it will break
> when wipe triggers without a fork ...
> For example, imagine:
>
> MADV_WIPEONFORK
> copy secret data to MADV_DONTFORK
> fork
>
>
> used to work, with this change it gets 0s instead of the secret data.
>
>
> I am also not sure it's wise to expose each guest process
> to the hypervisor like this. E.g. each process needs a
> guest physical address of its own then. This is a finite resource.
>
>
> The mmap interface proposed here is somewhat baroque, but it is
> certainly simple to implement ...

Wipe of fork/vmgenid/whatever could end up being much more problematic
than it naively appears -- it could be wiped in the middle of a read.
Either the API needs to handle this cleanly, or we need something more
aggressive like signal-on-fork.

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

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

2020-10-18 Thread Michael S. Tsirkin 
On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote:
> 4c. The guest kernel maintains an array of physical addresses that are
> MADV_WIPEONFORK. The hypervisor knows about this array and its
> location through whatever protocol, and before resuming a
> moved/snapshotted/duplicated VM, it takes the responsibility for
> memzeroing this memory. The huge pro here would be that this
> eliminates all races, and reduces complexity quite a bit, because the
> hypervisor can perfectly synchronize its bringup (and SMP bringup)
> with this, and it can even optimize things like on-disk memory
> snapshots to simply not write out those pages to disk.
> 
> A 4c-like approach seems like it'd be a lot of bang for the buck -- we
> reuse the existing mechanism (MADV_WIPEONFORK), so there's no new
> userspace API to deal with, and it'd be race free, and eliminate a lot
> of kernel complexity.

Clearly this has a chance to break applications, right?
If there's an app that uses this as a non-system-calls way
to find out whether there was a fork, it will break
when wipe triggers without a fork ...
For example, imagine:

MADV_WIPEONFORK
copy secret data to MADV_DONTFORK
fork


used to work, with this change it gets 0s instead of the secret data.


I am also not sure it's wise to expose each guest process
to the hypervisor like this. E.g. each process needs a
guest physical address of its own then. This is a finite resource.


The mmap interface proposed here is somewhat baroque, but it is
certainly simple to implement ...

-- 
MST

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

Re: [PATCH v1 00/29] virtio-mem: Big Block Mode (BBM)

2020-10-18 Thread Michael S. Tsirkin 
On Mon, Oct 12, 2020 at 02:52:54PM +0200, David Hildenbrand wrote:
> virtio-mem currently only supports device block sizes that span at most
> a single Linux memory block. For example, gigantic pages in the hypervisor
> result on x86-64 in a device block size of 1 GiB - when the Linux memory
> block size is 128 MiB, we cannot support such devices (we fail loading the
> driver). Of course, we want to support any device block size in any Linux
> VM.
> 
> Bigger device block sizes will become especially important once supporting
> VFIO in QEMU - each device block has to be mapped separately, and the
> maximum number of mappings for VFIO is 64k. So we usually want blocks in
> the gigabyte range when wanting to grow the VM big.

I guess it missed this Linux right? There's an mm change which did not
get an ack from mm mainatiners, so I can't merge it ...

> This series:
> - Performs some cleanups
> - Factors out existing Sub Block Mode (SBM)
> - Implements memory hot(un)plug in Big Block Mode (BBM)
> 
> I need one core-mm change, to make offline_and_remove_memory() eat bigger
> chunks.
> 
> This series is based on "next-20201009" and can be found at:
>   g...@gitlab.com:virtio-mem/linux.git virtio-mem-dbm-v1
> 
> Once some virtio-mem patches that are pending in the -mm tree are upstream
> (I guess they'll go in in 5.10), I'll resend based on Linus' tree.
> I suggest to take this (including the MM patch, acks/review please) via the
> vhost tree once time has come. In the meantime, I'll do more testing.
> 
> David Hildenbrand (29):
>   virtio-mem: determine nid only once using memory_add_physaddr_to_nid()
>   virtio-mem: simplify calculation in
> virtio_mem_mb_state_prepare_next_mb()
>   virtio-mem: simplify MAX_ORDER - 1 / pageblock_order handling
>   virtio-mem: drop rc2 in virtio_mem_mb_plug_and_add()
>   virtio-mem: generalize check for added memory
>   virtio-mem: generalize virtio_mem_owned_mb()
>   virtio-mem: generalize virtio_mem_overlaps_range()
>   virtio-mem: drop last_mb_id
>   virtio-mem: don't always trigger the workqueue when offlining memory
>   virtio-mem: generalize handling when memory is getting onlined
> deferred
>   virtio-mem: use "unsigned long" for nr_pages when fake
> onlining/offlining
>   virtio-mem: factor out fake-offlining into virtio_mem_fake_offline()
>   virtio-mem: factor out handling of fake-offline pages in memory
> notifier
>   virtio-mem: retry fake-offlining via alloc_contig_range() on
> ZONE_MOVABLE
>   virito-mem: document Sub Block Mode (SBM)
>   virtio-mem: memory block states are specific to Sub Block Mode (SBM)
>   virito-mem: subblock states are specific to Sub Block Mode (SBM)
>   virtio-mem: factor out calculation of the bit number within the
> sb_states bitmap
>   virito-mem: existing (un)plug functions are specific to Sub Block Mode
> (SBM)
>   virtio-mem: nb_sb_per_mb and subblock_size are specific to Sub Block
> Mode (SBM)
>   virtio-mem: memory notifier callbacks are specific to Sub Block Mode
> (SBM)
>   virtio-mem: memory block ids are specific to Sub Block Mode (SBM)
>   virtio-mem: factor out adding/removing memory from Linux
>   virtio-mem: print debug messages from virtio_mem_send_*_request()
>   virtio-mem: Big Block Mode (BBM) memory hotplug
>   virtio-mem: allow to force Big Block Mode (BBM) and set the big block
> size
>   mm/memory_hotplug: extend offline_and_remove_memory() to handle more
> than one memory block
>   virtio-mem: Big Block Mode (BBM) - basic memory hotunplug
>   virtio-mem: Big Block Mode (BBM) - safe memory hotunplug
> 
>  drivers/virtio/virtio_mem.c | 1783 +--
>  mm/memory_hotplug.c |  105 ++-
>  2 files changed, 1373 insertions(+), 515 deletions(-)
> 
> -- 
> 2.26.2

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

Call for Papers - WorldCIST'21, Terceira Island, Azores

2020-10-18 Thread ML 
* CORE Ranking conference
* Conference with a Google Scholar H5-Index = 19
* Proceedings published by Springer, in several books of the AISC series
* Indexed in Scopus, WoS, DBLP, Ei-Compendex, etc.
* Extended versions of best articles published in JCR/WoS/SCI journals


--  --  
---
WorldCIST'21 - 9th World Conference on Information Systems and Technologies
30-31 March to 1-2 April 2021 | Terceira Island, Azores, Portugal
http://www.worldcist.org/ 
--  --  
--

Scope

The WorldCist'21 - 9th World Conference on Information Systems and 
Technologies, to be held in Terceira Island, Azores, Portugal, 30-31 March to 
1-2 April 2021, is a global forum for researchers and practitioners to present 
and discuss the most recent innovations, trends, results, experiences and 
concerns in the several perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your papers to WorldCist'21. All 
submissions will be reviewed on the basis of relevance, originality, importance 
and clarity.



Themes

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

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Software and Systems Modeling (SSM);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Multimedia Systems and Applications (MSA);

F) Computer Networks, Mobility and Pervasive Systems (CNMPS);

G) Intelligent and Decision Support Systems (IDSS);

H) Big Data Analytics and Applications (BDAA);

I) Human-Computer Interaction (HCI);

J) Ethics, Computers and Security (ECS)

K) Health Informatics (HIS);

L) Information Technologies in Education (ITE);

M) Technologies for Biomedical Applications (TBA)

N) Information Technologies in Radiocommunications (ITR);



Types of Submissions and Decisions

Four types of papers can be submitted:

Full paper: Finished or consolidated R works, to be included in one of the 
Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to 
discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These 
papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, 
etc., focused on some topics of the conference. These papers are assigned to a 
4-page limit.

Submitted papers must comply with the format of Advances in Intelligent Systems 
and Computing Series (see Instructions for Authors at Springer Website), be 
written in English, 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 
bibliographic references should not be included in the version for evaluation 
by the Program 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.

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

Based on Program Committee evaluation, a paper can be rejected or accepted by 
the Conference Chairs. In the later case, it can be accepted as the type 
originally submitted or as another type. Thus, full papers can be accepted as 
short papers or poster papers only. Similarly, short papers can be accepted as 
poster papers only.

Poster papers and Company papers are not published in the Conference 
Proceedings, being only presented and discussed. The authors of accepted poster 
papers should build and print a poster to be exhibited during the Conference. 
This poster must follow an A1 or A2 vertical format. The Conference includes 
Work Sessions where these posters are presented and orally discussed, with a 7 
minute limit per poster.

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



Publication and Indexing

To ensure that a full paper or short paper is published, poster paper or 
company paper is published, at least one of the authors must be fully 
registered by the 2nd of January 2021, and the paper must comply with the 
suggested layout and page-limit. Additionally, all recommended changes must be 
addressed by

[PATCH] Revert "virtio-net: ethtool configurable RXCSUM"

2020-10-18 Thread Michael S. Tsirkin 
This reverts commit 3618ad2a7c0e78e4258386394d5d5f92a3dbccf8.

When control vq is not negotiated, that commit causes a crash:

[   72.229171] kernel BUG at drivers/net/virtio_net.c:1667!
[   72.230266] invalid opcode:  [#1] PREEMPT SMP
[   72.231172] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.9.0-rc8-02934-g3618ad2a7c0e7 #1
[   72.231172] EIP: virtnet_send_command+0x120/0x140
[   72.231172] Code: 00 0f 94 c0 8b 7d f0 65 33 3d 14 00 00 00 75 1c 8d 65 f4 
5b 5e 5f 5d c3 66 90 be 01 00 00 00 e9 6e ff ff ff 8d b6 00
+00 00 00 <0f> 0b e8 d9 bb 82 00 eb 17 8d b4 26 00 00 00 00 8d b4 26 00 00 00
[   72.231172] EAX: 000d EBX: f72895c0 ECX: 0017 EDX: 0011
[   72.231172] ESI: f7197800 EDI: ed69bd00 EBP: ed69bcf4 ESP: ed69bc98
[   72.231172] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
[   72.231172] CR0: 80050033 CR2:  CR3: 02c84000 CR4: 000406f0
[   72.231172] Call Trace:
[   72.231172]  ? __virt_addr_valid+0x45/0x60
[   72.231172]  ? ___cache_free+0x51f/0x760
[   72.231172]  ? kobject_uevent_env+0xf4/0x560
[   72.231172]  virtnet_set_guest_offloads+0x4d/0x80
[   72.231172]  virtnet_set_features+0x85/0x120
[   72.231172]  ? virtnet_set_guest_offloads+0x80/0x80
[   72.231172]  __netdev_update_features+0x27a/0x8e0
[   72.231172]  ? kobject_uevent+0xa/0x20
[   72.231172]  ? netdev_register_kobject+0x12c/0x160
[   72.231172]  register_netdevice+0x4fe/0x740
[   72.231172]  register_netdev+0x1c/0x40
[   72.231172]  virtnet_probe+0x728/0xb60
[   72.231172]  ? _raw_spin_unlock+0x1d/0x40
[   72.231172]  ? virtio_vdpa_get_status+0x1c/0x20
[   72.231172]  virtio_dev_probe+0x1c6/0x271
[   72.231172]  really_probe+0x195/0x2e0
[   72.231172]  driver_probe_device+0x26/0x60
[   72.231172]  device_driver_attach+0x49/0x60
[   72.231172]  __driver_attach+0x46/0xc0
[   72.231172]  ? device_driver_attach+0x60/0x60
[   72.231172]  bus_add_driver+0x197/0x1c0
[   72.231172]  driver_register+0x66/0xc0
[   72.231172]  register_virtio_driver+0x1b/0x40
[   72.231172]  virtio_net_driver_init+0x61/0x86
[   72.231172]  ? veth_init+0x14/0x14
[   72.231172]  do_one_initcall+0x76/0x2e4
[   72.231172]  ? rdinit_setup+0x2a/0x2a
[   72.231172]  do_initcalls+0xb2/0xd5
[   72.231172]  kernel_init_freeable+0x14f/0x179
[   72.231172]  ? rest_init+0x100/0x100
[   72.231172]  kernel_init+0xd/0xe0
[   72.231172]  ret_from_fork+0x1c/0x30
[   72.231172] Modules linked in:
[   72.269563] ---[ end trace a6ebc4afea0e6cb1 ]---

The reason is that virtnet_set_features now calls virtnet_set_guest_offloads
unconditionally, it used to only call it when there is something
to configure.

If device does not have a control vq, everything breaks.

Looking at this some more, I noticed that it's not really checking the
hardware too much. E.g.

if ((dev->features ^ features) & NETIF_F_LRO) {
if (features & NETIF_F_LRO)
offloads |= GUEST_OFFLOAD_LRO_MASK &
vi->guest_offloads_capable;
else
offloads &= ~GUEST_OFFLOAD_LRO_MASK;
}

and

(1ULL << VIRTIO_NET_F_GUEST_TSO6) | \
(1ULL << VIRTIO_NET_F_GUEST_ECN)  | \
(1ULL << VIRTIO_NET_F_GUEST_UFO))

But there's no guarantee that e.g. VIRTIO_NET_F_GUEST_TSO6 is set.

If it isn't command should not send it.

Further

static int virtnet_set_features(struct net_device *dev,
netdev_features_t features)
{
struct virtnet_info *vi = netdev_priv(dev);
u64 offloads = vi->guest_offloads;

seems wrong since guest_offloads is zero initialized,
it does not reflect the state after reset which comes from
the features.

Revert the original commit for now.

Cc: Tonghao Zhang 
Cc: Willem de Bruijn 
Fixes: 3618ad2a7c0e7 ("virtio-net: ethtool configurable RXCSUM")
Reported-by: kernel test robot 
Signed-off-by: Michael S. Tsirkin 
---
 drivers/net/virtio_net.c | 50 +++-
 1 file changed, 13 insertions(+), 37 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d2d2c4a53cf2..21b71148c532 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -68,8 +68,6 @@ static const unsigned long guest_offloads[] = {
(1ULL << VIRTIO_NET_F_GUEST_ECN)  | \
(1ULL << VIRTIO_NET_F_GUEST_UFO))
 
-#define GUEST_OFFLOAD_CSUM_MASK (1ULL << VIRTIO_NET_F_GUEST_CSUM)
-
 struct virtnet_stat_desc {
char desc[ETH_GSTRING_LEN];
size_t offset;
@@ -2524,48 +2522,29 @@ static int virtnet_get_phys_port_name(struct net_device 
*dev, char *buf,
return 0;
 }
 
-static netdev_features_t virtnet_fix_features(struct net_device *netdev,
- netdev_features_t features)
-{
-   /* If Rx checksum is disabled, LRO should also be disabled. */
-   if (!(features &

Re: [RFC] treewide: cleanup unreachable breaks

2020-10-18 Thread Hans de Goede 
Hi Tom,

Quick self intro: I have take over drivers/platform/x86
maintainership from Andy.

On 10/17/20 6:09 PM, t...@redhat.com wrote:
> From: Tom Rix 
> 
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
> 
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
> 
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
> 
> The method of fixing was to look for warnings where the preceding statement
> was a simple statement and by inspection made the subsequent break unneeded.
> In order of frequency these look like
> 
> return and break
> 
>   switch (c->x86_vendor) {
>   case X86_VENDOR_INTEL:
>   intel_p5_mcheck_init(c);
>   return 1;
> - break;
> 
> goto and break
> 
>   default:
>   operation = 0; /* make gcc happy */
>   goto fail_response;
> - break;
> 
> break and break
>   case COLOR_SPACE_SRGB:
>   /* by pass */
>   REG_SET(OUTPUT_CSC_CONTROL, 0,
>   OUTPUT_CSC_GRPH_MODE, 0);
>   break;
> - break;
> 
> The exception to the simple statement, is a switch case with a block
> and the end of block is a return
> 
>   struct obj_buffer *buff = r->ptr;
>   return scnprintf(str, PRIV_STR_SIZE,
>   "size=%u\naddr=0x%X\n", buff->size,
>   buff->addr);
>   }
> - break;
> 
> Not considered obvious and excluded, breaks after
> multi level switches
> complicated if-else if-else blocks
> panic() or similar calls
> 
> And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c

As Greg already mentioned please split this out into per subsystem patches.

I would be happy to take all the changes to drivers/platform/x86
code upstream as a single patch for all the files there.

Regards,

Hans


> ---
> 
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 1c08cb9eb9f6..16ce86aed8e2 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -1809,15 +1809,13 @@ static int __mcheck_cpu_ancient_init(struct 
> cpuinfo_x86 *c)
>  
>   switch (c->x86_vendor) {
>   case X86_VENDOR_INTEL:
>   intel_p5_mcheck_init(c);
>   return 1;
> - break;
>   case X86_VENDOR_CENTAUR:
>   winchip_mcheck_init(c);
>   return 1;
> - break;
>   default:
>   return 0;
>   }
>  
>   return 0;
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
> b/arch/x86/kernel/cpu/microcode/amd.c
> index 3f6b137ef4e6..3d4a48336084 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -213,11 +213,10 @@ static unsigned int __verify_patch_size(u8 family, u32 
> sh_psize, size_t buf_size
>   max_size = F14H_MPB_MAX_SIZE;
>   break;
>   default:
>   WARN(1, "%s: WTF family: 0x%x\n", __func__, family);
>   return 0;
> - break;
>   }
>  
>   if (sh_psize > min_t(u32, buf_size, max_size))
>   return 0;
>  
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 838b719ec7ce..d5411a166685 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -102,11 +102,10 @@ acpi_extract_package(union acpi_object *package,
>   printk(KERN_WARNING PREFIX "Invalid package 
> element"
> " [%d]: got number, expecting"
> " [%c]\n",
> i, format_string[i]);
>   return AE_BAD_DATA;
> - break;
>   }
>   break;
>  
>   case ACPI_TYPE_STRING:
>   case ACPI_TYPE_BUFFER:
> @@ -127,11 +126,10 @@ acpi_extract_package(union acpi_object *package,
>   printk(KERN_WARNING PREFIX "Invalid package 
> element"
> " [%d] got string/buffer,"
> " expecting [%c]\n",
> i, format_string[i]);
>   return AE_BAD_DATA;
> - break;
>   }
>   break;
>   case ACPI_TYPE_LOCAL_REFERENCE:
>   switch (format_string[i]) {
>