On 2019/7/21 下午8:18, Michael S. Tsirkin wrote:

On Sun, Jul 21, 2019 at 06:02:52AM -0400, Michael S. Tsirkin wrote:

quoted

On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote:

quoted

syzbot has bisected this bug to:

commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
Author: Jason Wang[off-list ref]
Date:   Fri May 24 08:12:18 2019 +0000

     vhost: access vq metadata through kernel virtual address

bisection log:https://syzkaller.appspot.com/x/bisect.txt?x=149a8a20600000
start commit:   6d21a41b Add linux-next specific files for 20190718
git tree:       linux-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=169a8a20600000
console output:https://syzkaller.appspot.com/x/log.txt?x=129a8a20600000
kernel config:https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
dashboard link:https://syzkaller.appspot.com/bug?extid=e58112d71f77113ddb7b
syz repro:https://syzkaller.appspot.com/x/repro.syz?x=10139e68600000

Reported-by:syzbot+e58112d71f77113ddb7b@syzkaller.appspotmail.com
Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual
address")

For information about bisection process see:https://goo.gl/tpsmEJ#bisection

OK I poked at this for a bit, I see several things that
we need to fix, though I'm not yet sure it's the reason for
the failures:


1. mmu_notifier_register shouldn't be called from vhost_vring_set_num_addr
    That's just a bad hack, in particular I don't think device
    mutex is taken and so poking at two VQs will corrupt
    memory.
    So what to do? How about a per vq notifier?
    Of course we also have synchronize_rcu
    in the notifier which is slow and is now going to be called twice.
    I think call_rcu would be more appropriate here.
    We then need rcu_barrier on module unload.
    OTOH if we make pages linear with map then we are good
    with kfree_rcu which is even nicer.

2. Doesn't map leak after vhost_map_unprefetch?
    And why does it poke at contents of the map?
    No one should use it right?

3. notifier unregister happens last in vhost_dev_cleanup,
    but register happens first. This looks wrong to me.

4. OK so we use the invalidate count to try and detect that
    some invalidate is in progress.
    I am not 100% sure why do we care.
    Assuming we do, uaddr can change between start and end
    and then the counter can get negative, or generally
    out of sync.

So what to do about all this?
I am inclined to say let's just drop the uaddr optimization
for now. E.g. kvm invalidates unconditionally.
3 should be fixed independently.

Above implements this but is only build-tested.
Jason, pls take a look. If you like the approach feel
free to take it from here.

One thing the below does not have is any kind of rate-limiting.
Given it's so easy to restart I'm thinking it makes sense
to add a generic infrastructure for this.
Can be a separate patch I guess.

I don't get why must use kfree_rcu() instead of synchronize_rcu() here.

Signed-off-by: Michael S. Tsirkin<mst@redhat.com>

Let me try to figure out the root cause then decide whether or not to go 
for this way.

Thanks



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel