Re: INFO: task hung in vhost_net_stop_vq
On 2019/3/25 下午10:02, Michael S. Tsirkin wrote:
Looks like more iotlb locking mess?
Looking at the calltrace:
[ 221.743675] =
[ 221.744297] [ INFO: possible recursive locking detected ]
[ 221.744944] 4.7.0+ #1 Not tainted
[ 221.745326] -
[ 221.746128] syz-executor1/6823 is trying to acquire lock:
[ 221.746737] (&vq->mutex){+.+...}, at: []
vhost_process_iotlb_msg+0xe0/0x9e0
[ 221.747789]
[ 221.747789] but task is already holding lock:
[ 221.748470] (&vq->mutex){+.+...}, at: []
vhost_process_iotlb_msg+0xe0/0x9e0
[ 221.749535]
[ 221.749535] other info that might help us debug this:
[ 221.750280] Possible unsafe locking scenario:
[ 221.750280]
[ 221.750946]CPU0
[ 221.751232]
[ 221.751523] lock(&vq->mutex);
[ 221.751922] lock(&vq->mutex);
[ 221.752339]
[ 221.752339] *** DEADLOCK ***
[ 221.752339]
I could not think of a path that can hit this. And I could not reproduce with
the reproducer in the link in net-next.
Thanks
On Tue, Mar 19, 2019 at 10:21:00PM -0700, syzbot wrote:
syzbot has bisected this bug to:
commit 6b1e6cc7855b09a0a9bfa1d9f30172ba366f161c
Author: Jason Wang
Date: Thu Jun 23 06:04:32 2016 +
vhost: new device IOTLB API
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1486ad2720
start commit: 6b1e6cc7 vhost: new device IOTLB API
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=1686ad2720
console output: https://syzkaller.appspot.com/x/log.txt?x=1286ad2720
kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
dashboard link: https://syzkaller.appspot.com/bug?extid=d21e6e297322a900c128
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141db34d40
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=108ef29340
Reported-by: syzbot+d21e6e297322a900c...@syzkaller.appspotmail.com
Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: INFO: task hung in vhost_net_stop_vq
On Tue, Mar 26, 2019 at 11:17 AM Jason Wang wrote:
>
>
> On 2019/3/25 下午10:02, Michael S. Tsirkin wrote:
> > Looks like more iotlb locking mess?
>
>
> Looking at the calltrace:
>
> [ 221.743675] =
> [ 221.744297] [ INFO: possible recursive locking detected ]
> [ 221.744944] 4.7.0+ #1 Not tainted
> [ 221.745326] -
> [ 221.746128] syz-executor1/6823 is trying to acquire lock:
> [ 221.746737] (&vq->mutex){+.+...}, at: []
> vhost_process_iotlb_msg+0xe0/0x9e0
> [ 221.747789]
> [ 221.747789] but task is already holding lock:
> [ 221.748470] (&vq->mutex){+.+...}, at: []
> vhost_process_iotlb_msg+0xe0/0x9e0
> [ 221.749535]
> [ 221.749535] other info that might help us debug this:
> [ 221.750280] Possible unsafe locking scenario:
> [ 221.750280]
> [ 221.750946]CPU0
> [ 221.751232]
> [ 221.751523] lock(&vq->mutex);
> [ 221.751922] lock(&vq->mutex);
> [ 221.752339]
> [ 221.752339] *** DEADLOCK ***
> [ 221.752339]
>
> I could not think of a path that can hit this. And I could not reproduce with
> the reproducer in the link in net-next.
Looking at the bisection log, syzbot is able to reproduce this
super-reliably on multiple kernel revisions. Are you sure you are
using the right config/revision? What else can be in play? syzbot uses
VMs. The image is available.
> Thanks
>
>
> >
> > On Tue, Mar 19, 2019 at 10:21:00PM -0700, syzbot wrote:
> >> syzbot has bisected this bug to:
> >>
> >> commit 6b1e6cc7855b09a0a9bfa1d9f30172ba366f161c
> >> Author: Jason Wang
> >> Date: Thu Jun 23 06:04:32 2016 +
> >>
> >> vhost: new device IOTLB API
> >>
> >> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1486ad2720
> >> start commit: 6b1e6cc7 vhost: new device IOTLB API
> >> git tree: upstream
> >> final crash:https://syzkaller.appspot.com/x/report.txt?x=1686ad2720
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=1286ad2720
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
> >> dashboard link:
> >> https://syzkaller.appspot.com/bug?extid=d21e6e297322a900c128
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141db34d40
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=108ef29340
> >>
> >> Reported-by: syzbot+d21e6e297322a900c...@syzkaller.appspotmail.com
> >> Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/df4f2cf6-8469-f894-8f45-7c48a6a1801f%40redhat.com.
> For more options, visit https://groups.google.com/d/optout.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Jan 30, 2019 at 08:44:27AM +0100, Christoph Hellwig wrote: > On Tue, Jan 29, 2019 at 09:36:08PM -0500, Michael S. Tsirkin wrote: > > This has been discussed ad nauseum. virtio is all about compatibility. > > Losing a couple of lines of code isn't worth breaking working setups. > > People that want "just use DMA API no tricks" now have the option. > > Setting a flag in a feature bit map is literally a single line > > of code in the hypervisor. So stop pushing for breaking working > > legacy setups and just fix it in the right place. > > I agree with the legacy aspect. What I am missing is an extremely > strong wording that says you SHOULD always set this flag for new > hosts, including an explanation why. So as far as power is concerned, IIUC the issue they are struggling with is that some platforms do not support pass-through mode in the emulated IOMMU. Disabling PLATFORM_ACCESS is so far a way around that, unfortunately just for virtio devices. I would like virtio-iommu to be able to address that need as well. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net v3] failover: allow name change on IFF_UP slave interfaces
On Tue, 26 Mar 2019 19:48:13 -0400
Si-Wei Liu wrote:
> When a netdev appears through hot plug then gets enslaved by a failover
> master that is already up and running, the slave will be opened
> right away after getting enslaved. Today there's a race that userspace
> (udev) may fail to rename the slave if the kernel (net_failover)
> opens the slave earlier than when the userspace rename happens.
> Unlike bond or team, the primary slave of failover can't be renamed by
> userspace ahead of time, since the kernel initiated auto-enslavement is
> unable to, or rather, is never meant to be synchronized with the rename
> request from userspace.
>
> As the failover slave interfaces are not designed to be operated
> directly by userspace apps: IP configuration, filter rules with
> regard to network traffic passing and etc., should all be done on master
> interface. In general, userspace apps only care about the
> name of master interface, while slave names are less important as long
> as admin users can see reliable names that may carry
> other information describing the netdev. For e.g., they can infer that
> "ens3nsby" is a standby slave of "ens3", while for a
> name like "eth0" they can't tell which master it belongs to.
>
> Historically the name of IFF_UP interface can't be changed because
> there might be admin script or management software that is already
> relying on such behavior and assumes that the slave name can't be
> changed once UP. But failover is special: with the in-kernel
> auto-enslavement mechanism, the userspace expectation for device
> enumeration and bring-up order is already broken. Previously initramfs
> and various userspace config tools were modified to bypass failover
> slaves because of auto-enslavement and duplicate MAC address. Similarly,
> in case that users care about seeing reliable slave name, the new type
> of failover slaves needs to be taken care of specifically in userspace
> anyway.
>
> It's less risky to lift up the rename restriction on failover slave
> which is already UP. Although it's possible this change may potentially
> break userspace component (most likely configuration scripts or
> management software) that assumes slave name can't be changed while
> UP, it's relatively a limited and controllable set among all userspace
> components, which can be fixed specifically to listen for the rename
> and/or link down/up events on failover slaves. Userspace component
> interacting with slaves is expected to be changed to operate on failover
> master interface instead, as the failover slave is dynamic in nature
> which may come and go at any point. The goal is to make the role of
> failover slaves less relevant, and userspace components should only
> deal with failover master in the long run.
>
> Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module")
> Signed-off-by: Si-Wei Liu
> Reviewed-by: Liran Alon
Why do you need to do dev_close/dev_open which will bounce
the link?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
