On 1/24/23 04:31, Jakub Kicinski wrote:
On Sun, 22 Jan 2023 15:47:08 +0200 Eli Cohen wrote:
@@ -3956,6 +3958,18 @@ static int virtnet_probe(struct virtio_device *vdev)
pr_debug("virtnet: registered device %s with %d RX and TX vq's\n",
dev->name, max_queue_pairs);
+
On Tue, Jan 24, 2023 at 04:42:31PM +1100, Alistair Popple wrote:
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index ec32f78..a31dd53 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
...
> @@ -780,6 +780,10 @@ static int vhost_vdpa_map(struct vhost_vdpa *v, struct
> +/**
> + * vm_account_init - Initialise a new struct vm_account.
> + * @vm_account: pointer to uninitialised vm_account.
> + * @task: task to charge against.
> + * @user: user to charge against. Must be non-NULL for VM_ACCOUNT_USER.
> + * @flags: flags to use when charging to vm_account.
> + *
>
When the MAC address is not provided by the vdpa device virtio_net
driver assigns a random one without notifying the device.
The consequence, in the case of mlx5_vdpa, is the internal routing
tables of the device are not updated and this can block the
communication between two namespaces.
To fix
In virtnet_probe(), if the device doesn't provide a MAC address the
driver assigns a random one.
As we modify the MAC address we need to notify the device to allow it
to update all the related information.
The problem can be seen with vDPA and mlx5_vdpa driver as it doesn't
assign a MAC address
On 1/22/23 11:23, Michael S. Tsirkin wrote:
On Sun, Jan 22, 2023 at 11:05:22AM +0100, Laurent Vivier wrote:
When the MAC address is not provided by the vdpa device virtio_net
driver assigns a random one without notifying the device.
The consequence, in the case of mlx5_vdpa, is the internal
1. This will be a native userspace daemon that will be running only in
the Linux VM which will use virtio-mem driver that uses memory hotplug
to add/remove memory. The VM (aka Secondary VM, SVM) will request for
memory from the host which is Primary VM, PVM via the backend hypervisor
which takes
On 1/22/23 14:47, Eli Cohen wrote:
On 22/01/2023 12:05, Laurent Vivier wrote:
In virtnet_probe(), if the device doesn't provide a MAC address the
driver assigns a random one.
As we modify the MAC address we need to notify the device to allow it
to update all the related information.
The
On Fri, Jan 20, 2023 at 01:53:40PM -0400, Jason Gunthorpe wrote:
> > Well, having GFP parameters is not a strict kernel convention. There are
> > places doing it differently and have sleeping and atomic variants of
> > APIs. I have to say I like the latter more. But given that this leads to
> > an
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 691781f561e9868a94c3ed7daf4adad7f8af5d16 Add linux-next specific
files for 20230123
Error/Warning: (recently discovered and may have been fixed)
ERROR: modpost: "devm_platform_ioremap_res
As already done for regular arch_atomic, always inline arch_atomic64.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/atomic64_32.h | 44 ++---
arch/x86/include/asm/atomic64_64.h | 36 +++---
2 files changed, 40
0-day robot reported graph-tracing made the cpuidle-vs-rcu rework go splat.
These patches appear to cure this, the ftrace selftest now runs to completion
without spamming scary messages to dmesg.
---
arch/x86/include/asm/atomic64_32.h | 44 +++---
With sched_clock() noinstr, provide a noinstr implementation of
local_clock().
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/sched/clock.h |8 +++-
kernel/sched/clock.c| 27 +--
2 files changed, 24 insertions(+), 11 deletions(-)
---
All RCU disabled code should be noinstr and hence we should never get
here -- when we do, WARN about it and make sure to not actually do
tracing.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/kernel/ftrace.c |3 +++
1 file changed, 3 insertions(+)
--- a/arch/x86/kernel/ftrace.c
+++
The instrumentation_begin()/end() annotations in poll_idle() were
complete nonsense. Specifically they caused tracing to happen in the
middle of noinstr code, resulting in RCU splats.
Now that local_clock() is noinstr, mark up the rest and let it rip.
Fixes: 00717eb8c955 ("cpuidle: Annotate
In order to use sched_clock() from noinstr code, mark it and all it's
implenentations noinstr.
The whole pvclock thing (used by KVM/Xen) is a bit of a pain,
since it calls out to watchdogs, create a
pvclock_clocksource_read_nowd() variant doesn't do that and can be
noinstr.
Signed-off-by: Peter
From: Uros Bizjak
Improve atomic update of last_value in pvclock_clocksource_read:
- Atomic update can be skipped if the "last_value" is already
equal to "ret".
- The detection of atomic update failure is not correct. The value,
returned by atomic64_cmpxchg should be compared to the old
On Mon, 23 Jan 2023 21:50:12 +0100
Peter Zijlstra wrote:
> All RCU disabled code should be noinstr and hence we should never get
> here -- when we do, WARN about it and make sure to not actually do
> tracing.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/kernel/ftrace.c |3
On Mon, 23 Jan 2023 16:53:04 -0500
Steven Rostedt wrote:
> On Mon, 23 Jan 2023 21:50:12 +0100
> Peter Zijlstra wrote:
>
> > All RCU disabled code should be noinstr and hence we should never get
> > here -- when we do, WARN about it and make sure to not actually do
> > tracing.
> >
> >
On Thu, Jan 19, 2023 at 03:36:47PM +0800, Jason Wang wrote:
> Al Viro said:
>
> """
> Since "vhost/scsi: fix reuse of >iov[out] in response"
> we have this:
> cmd->tvc_resp_iov = vq->iov[vc.out];
> cmd->tvc_in_iovs = vc.in;
> combined with
>
20 matches
Mail list logo
