svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys

[Wei Hu]

> -----Original Message-----
> From: Peter Holm <pho at freebsd.org>
> Sent: Thursday, May 21, 2020 8:24 PM
> To: Wei Hu <whu at freebsd.org>
> Cc: src-committers at freebsd.org; svn-src-all at freebsd.org; svn-src-
> head at freebsd.org
> Subject: Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock
> dev/hyperv/include dev/hyperv/vmbus modules/hyperv
> modules/hyperv/hvsock sys
> 
> On Wed, May 20, 2020 at 11:03:59AM +0000, Wei Hu wrote:
> > Author: whu
> > Date: Wed May 20 11:03:59 2020
> > New Revision: 361275
> > URL:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb
> .freebsd.org%2Fchangeset%2Fbase%2F361275&data=02%7C01%7Cweh%
> 40microsoft.com%7C61c524b5022b47b2c4e108d7fd81e75f%7C72f988bf86f14
> 1af91ab2d7cd011db47%7C1%7C0%7C637256606689750658&sdata=mw
> 4IXP3DnxICnK4U%2F8MzLbvMAzCuxih2f0waDyMSCTE%3D&reserved=0
> >
> > Log:
> >   HyperV socket implementation for FreeBSD
> >
> >   This change adds Hyper-V socket feature in FreeBSD. New socket address
> >   family AF_HYPERV and its kernel support are added.
> >
> 
> Found this with a syscall fuzz test:
> 
> panic: page fault
> cpuid = 2
> time = 1590050529
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe033d21d530
> vpanic() at vpanic+0x182/frame 0xfffffe033d21d580
> panic() at panic+0x43/frame 0xfffffe033d21d5e0
> trap_fatal() at trap_fatal+0x387/frame 0xfffffe033d21d640
> trap_pfault() at trap_pfault+0x99/frame 0xfffffe033d21d6a0
> trap() at trap+0x2a5/frame 0xfffffe033d21d7b0
> calltrap() at calltrap+0x8/frame 0xfffffe033d21d7b0
> --- trap 0xc, rip = 0xffffffff80bcd3ba, rsp = 0xfffffe033d21d880, rbp =
> 0xfffffe033d21d910 ---
> _sx_xlock_hard() at _sx_xlock_hard+0x17a/frame 0xfffffe033d21d910
> _sx_xlock() at _sx_xlock+0xba/frame 0xfffffe033d21d950
> hvs_trans_close() at hvs_trans_close+0x42/frame 0xfffffe033d21d970
> soclose() at soclose+0x161/frame 0xfffffe033d21d9e0
> _fdrop() at _fdrop+0x1a/frame 0xfffffe033d21da00
> closef() at closef+0x1db/frame 0xfffffe033d21da90
> closefp() at closefp+0x96/frame 0xfffffe033d21dad0
> amd64_syscall() at amd64_syscall+0x159/frame 0xfffffe033d21dbf0
> fast_syscall_common() at fast_syscall_common+0x101/frame
> 0xfffffe033d21dbf0
> --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8004283ca, rsp = 0x7fffffffe328,
> rbp = 0x7fffffffe460 ---
> 
> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fpeople.free
> bsd.org%2F~pho%2Fstress%2Flog%2Fsetsockopt2-
> 2.txt&data=02%7C01%7Cweh%40microsoft.com%7C61c524b5022b47b2c
> 4e108d7fd81e75f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> 7256606689750658&sdata=RuBmWrBv7lGnhF2IHZ5NOP2rmV0c%2BJXuk
> RZl260KSIw%3D&reserved=0
> 
> Could this be yours?


Yes. Looks the lock was not initialized. The lock only gets initialized when it is running
on HyperV. This type of socket only works on HyperV. 

How to reproduce it? Was it on HyperV? I am not sure how it can enter this state.

Wei