RE: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
> -Original Message- > From: Kyle Evans > Sent: Saturday, May 30, 2020 2:33 AM > To: Wei Hu > Cc: src-committers ; svn-src-all a...@freebsd.org>; svn-src-head > 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 Fri, May 29, 2020 at 12:08 PM Wei Hu wrote: > > > -Original Message- > > > > > [... snip ...] > > > > > +void > > > > > +hvs_trans_init(void) > > > > > +{ > > > > > + /* Skip initialization of globals for non-default instances. > > > > > */ > > > > > + if (!IS_DEFAULT_VNET(curvnet)) > > > > > + return; > > > > > + > > > > > + if (vm_guest != VM_GUEST_HV) > > > > > + return; > > > > > + > > > > > + HVSOCK_DBG(HVSOCK_DBG_VERBOSE, > > > > > + "%s: HyperV Socket hvs_trans_init called\n", > > > > > + __func__); > > > > > + > > > > > + /* Initialize Globals */ > > > > > + previous_auto_bound_port = MAX_PORT; > > > > > + sx_init(_trans_socks_sx, "hvs_trans_sock_sx"); > > > > > + mtx_init(_trans_socks_mtx, > > > > > + "hvs_trans_socks_mtx", NULL, MTX_DEF); > > > > > + LIST_INIT(_trans_bound_socks); > > > > > + LIST_INIT(_trans_connected_socks); > > > > > +} > > > > > + > > > > > > > > I have a suspicion that all of these should really be per-vnet for > > > > correct semantics with VIMAGE, with the IS_DEFAULT_VNET check > > > > earlier dropped completely. I haven't read around the rest all > > > > that much, but this would at least seem to prevent port re-use by > > > > a different vnet, which is perhaps "good enough" but I think this > > > > is something that should be fixed in the mid-term. > > > > > > > > > > I have a follow-up concern about whether this is actually going to > > > be maintained... it's been a full week with not even an > > > acknowledgement or rebuttal of any of the concerns I've raised, with > > > some of them being completely trivial to address in the short-term. > > > I don't think that we really want this in the tree in its current state > > > given > this level of engagement. > > > > > Sorry for my late response, Kyle. I read your comments last week. To > > be honest I am not familiar to VNET and VIMAGE, so I don't quite > > understand. I got distracted into other work so my response to this was > delayed. > > > > Do you mean to drop these two lines? > >if (!IS_DEFAULT_VNET(curvnet)) > >return > > I copied these from other socket init code. If they are not necessary I can > remove them. > > > > Alright, let's rewind a little bit here. =-) Consider while reading the below > that I > have no idea what the host-side of these sockets look like beyond what I just > very quickly skimmed from [0]. > > It's a little more involved than that; consider each vnet as its own > independent > network stack that's largely isolated from other vnets. > The host starts out with a vnet, vnet0 (the default vnet), and root may spawn > additional vnets attached to jails to allow the jail to operate its own > network > stack as well. Your pr_init will get called once per vnet spawned, including > the > obvious default vnet, which is why the check is there in the first place -- > you > may have some global state that only needs to be initialized once, at which > point you would exclude non-default vnets from executing those bits. > > The more I think about it, though, the more I wonder if hvsock makes sense at > all in non-default vnet contexts and whether hvs_trans_attach should really be > attaching to sockets outside of the default vnet. You can bind in your FreeBSD > HyperV guest to a port, and a host service's option for connecting is > specifying > guest GUID + port; there's not really any wiggle room for multiple entities > within a guest to be binding to a given port anyways. It may very well be the > case that the status quo is the optimal outcome. > > Given that, does it make sense that the host connects via the guest GUID and > can potentially end up connected to some jail of unknown trust operating its > own network stack? > > As a final scattere
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
On Fri, May 29, 2020 at 12:08 PM Wei Hu wrote: > > -Original Message- > > > > [... snip ...] > > > > +void > > > > +hvs_trans_init(void) > > > > +{ > > > > + /* Skip initialization of globals for non-default instances. */ > > > > + if (!IS_DEFAULT_VNET(curvnet)) > > > > + return; > > > > + > > > > + if (vm_guest != VM_GUEST_HV) > > > > + return; > > > > + > > > > + HVSOCK_DBG(HVSOCK_DBG_VERBOSE, > > > > + "%s: HyperV Socket hvs_trans_init called\n", __func__); > > > > + > > > > + /* Initialize Globals */ > > > > + previous_auto_bound_port = MAX_PORT; > > > > + sx_init(_trans_socks_sx, "hvs_trans_sock_sx"); > > > > + mtx_init(_trans_socks_mtx, > > > > + "hvs_trans_socks_mtx", NULL, MTX_DEF); > > > > + LIST_INIT(_trans_bound_socks); > > > > + LIST_INIT(_trans_connected_socks); > > > > +} > > > > + > > > > > > I have a suspicion that all of these should really be per-vnet for > > > correct semantics with VIMAGE, with the IS_DEFAULT_VNET check earlier > > > dropped completely. I haven't read around the rest all that much, but > > > this would at least seem to prevent port re-use by a different vnet, > > > which is perhaps "good enough" but I think this is something that > > > should be fixed in the mid-term. > > > > > > > I have a follow-up concern about whether this is actually going to be > > maintained... it's been a full week with not even an acknowledgement or > > rebuttal of any of the concerns I've raised, with some of them being > > completely > > trivial to address in the short-term. I don't think that we really want > > this in the > > tree in its current state given this level of engagement. > > > Sorry for my late response, Kyle. I read your comments last week. To be > honest I am > not familiar to VNET and VIMAGE, so I don't quite understand. I got distracted > into other work so my response to this was delayed. > > Do you mean to drop these two lines? >if (!IS_DEFAULT_VNET(curvnet)) >return > I copied these from other socket init code. If they are not necessary I can > remove them. > Alright, let's rewind a little bit here. =-) Consider while reading the below that I have no idea what the host-side of these sockets look like beyond what I just very quickly skimmed from [0]. It's a little more involved than that; consider each vnet as its own independent network stack that's largely isolated from other vnets. The host starts out with a vnet, vnet0 (the default vnet), and root may spawn additional vnets attached to jails to allow the jail to operate its own network stack as well. Your pr_init will get called once per vnet spawned, including the obvious default vnet, which is why the check is there in the first place -- you may have some global state that only needs to be initialized once, at which point you would exclude non-default vnets from executing those bits. The more I think about it, though, the more I wonder if hvsock makes sense at all in non-default vnet contexts and whether hvs_trans_attach should really be attaching to sockets outside of the default vnet. You can bind in your FreeBSD HyperV guest to a port, and a host service's option for connecting is specifying guest GUID + port; there's not really any wiggle room for multiple entities within a guest to be binding to a given port anyways. It may very well be the case that the status quo is the optimal outcome. Given that, does it make sense that the host connects via the guest GUID and can potentially end up connected to some jail of unknown trust operating its own network stack? As a final scattered thought for the hour, does the Linux implementation of this stuff do anything to give a guest admin visibility into existing HyperV sockets on the system? AFAICT here, there's no sockstat integration or anything else that might export hvsock information to userland, so one's only option to tracking down whether a HyperV socket even exists and to which process it belongs would appear to be probing around in the kernel. Thanks, Kyle Evans [0] https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
RE: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
> -Original Message- > > > [... snip ...] > > > +void > > > +hvs_trans_init(void) > > > +{ > > > + /* Skip initialization of globals for non-default instances. */ > > > + if (!IS_DEFAULT_VNET(curvnet)) > > > + return; > > > + > > > + if (vm_guest != VM_GUEST_HV) > > > + return; > > > + > > > + HVSOCK_DBG(HVSOCK_DBG_VERBOSE, > > > + "%s: HyperV Socket hvs_trans_init called\n", __func__); > > > + > > > + /* Initialize Globals */ > > > + previous_auto_bound_port = MAX_PORT; > > > + sx_init(_trans_socks_sx, "hvs_trans_sock_sx"); > > > + mtx_init(_trans_socks_mtx, > > > + "hvs_trans_socks_mtx", NULL, MTX_DEF); > > > + LIST_INIT(_trans_bound_socks); > > > + LIST_INIT(_trans_connected_socks); > > > +} > > > + > > > > I have a suspicion that all of these should really be per-vnet for > > correct semantics with VIMAGE, with the IS_DEFAULT_VNET check earlier > > dropped completely. I haven't read around the rest all that much, but > > this would at least seem to prevent port re-use by a different vnet, > > which is perhaps "good enough" but I think this is something that > > should be fixed in the mid-term. > > > > I have a follow-up concern about whether this is actually going to be > maintained... it's been a full week with not even an acknowledgement or > rebuttal of any of the concerns I've raised, with some of them being > completely > trivial to address in the short-term. I don't think that we really want this > in the > tree in its current state given this level of engagement. > Sorry for my late response, Kyle. I read your comments last week. To be honest I am not familiar to VNET and VIMAGE, so I don't quite understand. I got distracted into other work so my response to this was delayed. Do you mean to drop these two lines? if (!IS_DEFAULT_VNET(curvnet)) return I copied these from other socket init code. If they are not necessary I can remove them. Thanks, Wei ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
On Fri, May 22, 2020 at 11:12 AM Kyle Evans wrote: > > On Wed, May 20, 2020 at 6:04 AM Wei Hu wrote: > > > > Author: whu > > Date: Wed May 20 11:03:59 2020 > > New Revision: 361275 > > URL: https://svnweb.freebsd.org/changeset/base/361275 > > > > 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. > > > > [... snip ...] > > +void > > +hvs_trans_init(void) > > +{ > > + /* Skip initialization of globals for non-default instances. */ > > + if (!IS_DEFAULT_VNET(curvnet)) > > + return; > > + > > + if (vm_guest != VM_GUEST_HV) > > + return; > > + > > + HVSOCK_DBG(HVSOCK_DBG_VERBOSE, > > + "%s: HyperV Socket hvs_trans_init called\n", __func__); > > + > > + /* Initialize Globals */ > > + previous_auto_bound_port = MAX_PORT; > > + sx_init(_trans_socks_sx, "hvs_trans_sock_sx"); > > + mtx_init(_trans_socks_mtx, > > + "hvs_trans_socks_mtx", NULL, MTX_DEF); > > + LIST_INIT(_trans_bound_socks); > > + LIST_INIT(_trans_connected_socks); > > +} > > + > > I have a suspicion that all of these should really be per-vnet for > correct semantics with VIMAGE, with the IS_DEFAULT_VNET check earlier > dropped completely. I haven't read around the rest all that much, but > this would at least seem to prevent port re-use by a different vnet, > which is perhaps "good enough" but I think this is something that > should be fixed in the mid-term. > I have a follow-up concern about whether this is actually going to be maintained... it's been a full week with not even an acknowledgement or rebuttal of any of the concerns I've raised, with some of them being completely trivial to address in the short-term. I don't think that we really want this in the tree in its current state given this level of engagement. Thanks, Kyle Evans ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
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 6:04 AM Wei Hu wrote: > > Author: whu > Date: Wed May 20 11:03:59 2020 > New Revision: 361275 > URL: https://svnweb.freebsd.org/changeset/base/361275 > > 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. > > [... snip ...] > +void > +hvs_trans_init(void) > +{ > + /* Skip initialization of globals for non-default instances. */ > + if (!IS_DEFAULT_VNET(curvnet)) > + return; > + > + if (vm_guest != VM_GUEST_HV) > + return; > + > + HVSOCK_DBG(HVSOCK_DBG_VERBOSE, > + "%s: HyperV Socket hvs_trans_init called\n", __func__); > + > + /* Initialize Globals */ > + previous_auto_bound_port = MAX_PORT; > + sx_init(_trans_socks_sx, "hvs_trans_sock_sx"); > + mtx_init(_trans_socks_mtx, > + "hvs_trans_socks_mtx", NULL, MTX_DEF); > + LIST_INIT(_trans_bound_socks); > + LIST_INIT(_trans_connected_socks); > +} > + I have a suspicion that all of these should really be per-vnet for correct semantics with VIMAGE, with the IS_DEFAULT_VNET check earlier dropped completely. I haven't read around the rest all that much, but this would at least seem to prevent port re-use by a different vnet, which is perhaps "good enough" but I think this is something that should be fixed in the mid-term. Thanks, Kyle Evans ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
On Thu, May 21, 2020 at 01:01:18PM +, Wei Hu wrote: > > -Original Message- > > From: Peter Holm > > Sent: Thursday, May 21, 2020 8:24 PM > > To: Wei Hu > > Cc: src-committ...@freebsd.org; svn-src-all@freebsd.org; svn-src- > > h...@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 +, 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%2F361275data=02%7C01%7Cweh% > > 40microsoft.com%7C61c524b5022b47b2c4e108d7fd81e75f%7C72f988bf86f14 > > 1af91ab2d7cd011db47%7C1%7C0%7C637256606689750658sdata=mw > > 4IXP3DnxICnK4U%2F8MzLbvMAzCuxih2f0waDyMSCTE%3Dreserved=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 > > 0xfe033d21d530 > > vpanic() at vpanic+0x182/frame 0xfe033d21d580 > > panic() at panic+0x43/frame 0xfe033d21d5e0 > > trap_fatal() at trap_fatal+0x387/frame 0xfe033d21d640 > > trap_pfault() at trap_pfault+0x99/frame 0xfe033d21d6a0 > > trap() at trap+0x2a5/frame 0xfe033d21d7b0 > > calltrap() at calltrap+0x8/frame 0xfe033d21d7b0 > > --- trap 0xc, rip = 0x80bcd3ba, rsp = 0xfe033d21d880, rbp = > > 0xfe033d21d910 --- > > _sx_xlock_hard() at _sx_xlock_hard+0x17a/frame 0xfe033d21d910 > > _sx_xlock() at _sx_xlock+0xba/frame 0xfe033d21d950 > > hvs_trans_close() at hvs_trans_close+0x42/frame 0xfe033d21d970 > > soclose() at soclose+0x161/frame 0xfe033d21d9e0 > > _fdrop() at _fdrop+0x1a/frame 0xfe033d21da00 > > closef() at closef+0x1db/frame 0xfe033d21da90 > > closefp() at closefp+0x96/frame 0xfe033d21dad0 > > amd64_syscall() at amd64_syscall+0x159/frame 0xfe033d21dbf0 > > fast_syscall_common() at fast_syscall_common+0x101/frame > > 0xfe033d21dbf0 > > --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8004283ca, rsp = > > 0x7fffe328, > > rbp = 0x7fffe460 --- > > > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fpeople.free > > bsd.org%2F~pho%2Fstress%2Flog%2Fsetsockopt2- > > 2.txtdata=02%7C01%7Cweh%40microsoft.com%7C61c524b5022b47b2c > > 4e108d7fd81e75f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 > > 7256606689750658sdata=RuBmWrBv7lGnhF2IHZ5NOP2rmV0c%2BJXuk > > RZl260KSIw%3Dreserved=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 The test is syscall() fuzzing, which typically flushes out missing parameter validations. This was *not* run on HyperV. You can find the test case here: https://svnweb.freebsd.org/base/user/pho/stress2/misc/setsockopt2.sh - Peter ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
RE: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
> -Original Message- > From: Peter Holm > Sent: Thursday, May 21, 2020 8:24 PM > To: Wei Hu > Cc: src-committ...@freebsd.org; svn-src-all@freebsd.org; svn-src- > h...@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 +, 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%2F361275data=02%7C01%7Cweh% > 40microsoft.com%7C61c524b5022b47b2c4e108d7fd81e75f%7C72f988bf86f14 > 1af91ab2d7cd011db47%7C1%7C0%7C637256606689750658sdata=mw > 4IXP3DnxICnK4U%2F8MzLbvMAzCuxih2f0waDyMSCTE%3Dreserved=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 > 0xfe033d21d530 > vpanic() at vpanic+0x182/frame 0xfe033d21d580 > panic() at panic+0x43/frame 0xfe033d21d5e0 > trap_fatal() at trap_fatal+0x387/frame 0xfe033d21d640 > trap_pfault() at trap_pfault+0x99/frame 0xfe033d21d6a0 > trap() at trap+0x2a5/frame 0xfe033d21d7b0 > calltrap() at calltrap+0x8/frame 0xfe033d21d7b0 > --- trap 0xc, rip = 0x80bcd3ba, rsp = 0xfe033d21d880, rbp = > 0xfe033d21d910 --- > _sx_xlock_hard() at _sx_xlock_hard+0x17a/frame 0xfe033d21d910 > _sx_xlock() at _sx_xlock+0xba/frame 0xfe033d21d950 > hvs_trans_close() at hvs_trans_close+0x42/frame 0xfe033d21d970 > soclose() at soclose+0x161/frame 0xfe033d21d9e0 > _fdrop() at _fdrop+0x1a/frame 0xfe033d21da00 > closef() at closef+0x1db/frame 0xfe033d21da90 > closefp() at closefp+0x96/frame 0xfe033d21dad0 > amd64_syscall() at amd64_syscall+0x159/frame 0xfe033d21dbf0 > fast_syscall_common() at fast_syscall_common+0x101/frame > 0xfe033d21dbf0 > --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8004283ca, rsp = > 0x7fffe328, > rbp = 0x7fffe460 --- > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fpeople.free > bsd.org%2F~pho%2Fstress%2Flog%2Fsetsockopt2- > 2.txtdata=02%7C01%7Cweh%40microsoft.com%7C61c524b5022b47b2c > 4e108d7fd81e75f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 > 7256606689750658sdata=RuBmWrBv7lGnhF2IHZ5NOP2rmV0c%2BJXuk > RZl260KSIw%3Dreserved=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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
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 +, Wei Hu wrote: > Author: whu > Date: Wed May 20 11:03:59 2020 > New Revision: 361275 > URL: https://svnweb.freebsd.org/changeset/base/361275 > > 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 0xfe033d21d530 vpanic() at vpanic+0x182/frame 0xfe033d21d580 panic() at panic+0x43/frame 0xfe033d21d5e0 trap_fatal() at trap_fatal+0x387/frame 0xfe033d21d640 trap_pfault() at trap_pfault+0x99/frame 0xfe033d21d6a0 trap() at trap+0x2a5/frame 0xfe033d21d7b0 calltrap() at calltrap+0x8/frame 0xfe033d21d7b0 --- trap 0xc, rip = 0x80bcd3ba, rsp = 0xfe033d21d880, rbp = 0xfe033d21d910 --- _sx_xlock_hard() at _sx_xlock_hard+0x17a/frame 0xfe033d21d910 _sx_xlock() at _sx_xlock+0xba/frame 0xfe033d21d950 hvs_trans_close() at hvs_trans_close+0x42/frame 0xfe033d21d970 soclose() at soclose+0x161/frame 0xfe033d21d9e0 _fdrop() at _fdrop+0x1a/frame 0xfe033d21da00 closef() at closef+0x1db/frame 0xfe033d21da90 closefp() at closefp+0x96/frame 0xfe033d21dad0 amd64_syscall() at amd64_syscall+0x159/frame 0xfe033d21dbf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe033d21dbf0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8004283ca, rsp = 0x7fffe328, rbp = 0x7fffe460 --- https://people.freebsd.org/~pho/stress/log/setsockopt2-2.txt Could this be yours? - Peter ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
On Thu, 2020-05-21 at 01:53 +, Wei Hu wrote: > > -Original Message- > > From: Enji Cooper > > Sent: Wednesday, May 20, 2020 11:58 PM > > To: Shawn Webb > > Cc: Wei Hu ; src-committ...@freebsd.org; svn-src- > > a...@freebsd.org; svn-src-h...@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 May 20, 2020, at 08:54, Enji Cooper wrote: > > > > > > > > On May 20, 2020, at 08:11, Shawn Webb > > > > wrote: > > > > > > > > > > On Wed, May 20, 2020 at 11:03:59AM +, 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%2Fsv > > > > > > > > > nweb.freebsd.org%2Fchangeset%2Fbase%2F361275data=02%7C01%7C > > weh% > > > > > > > > > 40microsoft.com%7Cd6ff3617bffa43d10a7708d7fcd68470%7C72f988bf86f141 > > a > > > > > > > > > f91ab2d7cd011db47%7C1%7C0%7C637255870581110888sdata=mzz6R > > ILCVBk > > > > > q06RI1PAfVNKWZO2y7jBO0C1E%2F%2FEJwUY%3Dreserved=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. > > > > > > Hi Wei, > > >Could you please further describe what this feature is/does? > > > > I realize after looking at the review that it contains the content I > > was hoping > > for. It would have been helpful to folks if this context had been included > > in the > > commit message. > > Hi Enji, > > I thought I just keep it simple for the commit log message while people can > refer to the review site for details. Sorry about that. Let me know if there > is > anyway to make up for it. > > Wei > Ten years from now, phabricator may just be a fading memory, but the source code repo lives forever. Usually when I put something in phab for review, the description I enter in phab is exactly the text I intend to use when committing the change. That helps the people doing the review... the description is an overview of what is being changed, and most importantly, why it is being changed (fixes a bug, adds a new feature, better performance, etc). Everything you say there to help reviewers will be equally helpful in the repo history when someone needs to research some day why a change got made. -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
On Thu, May 21, 2020 at 9:50 AM Wei Hu wrote: > I was not familiar to the mechanism of __FreeBSD_version. But it looks > like a good idea. However I am not sure if I have the right to update the > chapter.xml file. Can you help on what I need to do the update this > version number? It's no problem (actually it's required) to update doc/head/en_US.ISO8859-1/books/porters-handbook/versions/chapter.xml after you bump __FreeBSD_version in src/sys/sys/param.h Best, Li-Wen ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
RE: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
> -Original Message- > From: Enji Cooper > Sent: Wednesday, May 20, 2020 11:58 PM > To: Shawn Webb > Cc: Wei Hu ; src-committ...@freebsd.org; svn-src- > a...@freebsd.org; svn-src-h...@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 May 20, 2020, at 08:54, Enji Cooper wrote: > > > >>> On May 20, 2020, at 08:11, Shawn Webb > wrote: > >>> > >>> On Wed, May 20, 2020 at 11:03:59AM +, 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%2Fsv > >>> > nweb.freebsd.org%2Fchangeset%2Fbase%2F361275data=02%7C01%7C > weh% > >>> > 40microsoft.com%7Cd6ff3617bffa43d10a7708d7fcd68470%7C72f988bf86f141 > a > >>> > f91ab2d7cd011db47%7C1%7C0%7C637255870581110888sdata=mzz6R > ILCVBk > >>> q06RI1PAfVNKWZO2y7jBO0C1E%2F%2FEJwUY%3Dreserved=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. > > > > Hi Wei, > >Could you please further describe what this feature is/does? > > I realize after looking at the review that it contains the content I was > hoping > for. It would have been helpful to folks if this context had been included in > the > commit message. Hi Enji, I thought I just keep it simple for the commit log message while people can refer to the review site for details. Sorry about that. Let me know if there is anyway to make up for it. Wei ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
RE: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
> -Original Message- > From: Shawn Webb > Sent: Wednesday, May 20, 2020 11:11 PM > To: Wei Hu > Cc: src-committ...@freebsd.org; svn-src-all@freebsd.org; svn-src- > h...@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 +, Wei Hu wrote: > > Author: whu > > Date: Wed May 20 11:03:59 2020 > > New Revision: 361275 > > URL: https://svnweb.freebsd.org/changeset/base/361275 > > > > 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. > > > > Submitted by: Wei Hu > > Reviewed by: Dexuan Cui > > Relnotes: yes > > Sponsored by: Microsoft > > Differential Revision:https://reviews.freebsd.org/D24061 > > Hey Wei Hu, > > Would it be good to bump __FreeBSD_version after a change like this? > Hi Shawn, I was not familiar to the mechanism of __FreeBSD_version. But it looks like a good idea. However I am not sure if I have the right to update the chapter.xml file. Can you help on what I need to do the update this version number? Thanks, Wei ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
> On May 20, 2020, at 08:54, Enji Cooper wrote: > >>> On May 20, 2020, at 08:11, Shawn Webb wrote: >>> >>> On Wed, May 20, 2020 at 11:03:59AM +, Wei Hu wrote: >>> Author: whu >>> Date: Wed May 20 11:03:59 2020 >>> New Revision: 361275 >>> URL: https://svnweb.freebsd.org/changeset/base/361275 >>> >>> 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. > > Hi Wei, >Could you please further describe what this feature is/does? I realize after looking at the review that it contains the content I was hoping for. It would have been helpful to folks if this context had been included in the commit message. Thank you, -Enji ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
> On May 20, 2020, at 08:11, Shawn Webb wrote: > > On Wed, May 20, 2020 at 11:03:59AM +, Wei Hu wrote: >> Author: whu >> Date: Wed May 20 11:03:59 2020 >> New Revision: 361275 >> URL: https://svnweb.freebsd.org/changeset/base/361275 >> >> 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. Hi Wei, Could you please further describe what this feature is/does? Thanks, -Enji ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
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 +, Wei Hu wrote: > Author: whu > Date: Wed May 20 11:03:59 2020 > New Revision: 361275 > URL: https://svnweb.freebsd.org/changeset/base/361275 > > 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. > > Submitted by: Wei Hu > Reviewed by:Dexuan Cui > Relnotes: yes > Sponsored by: Microsoft > Differential Revision: https://reviews.freebsd.org/D24061 Hey Wei Hu, Would it be good to bump __FreeBSD_version after a change like this? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
svn commit: r361275 - in head/sys: conf dev/hyperv/hvsock dev/hyperv/include dev/hyperv/vmbus modules/hyperv modules/hyperv/hvsock sys
Author: whu Date: Wed May 20 11:03:59 2020 New Revision: 361275 URL: https://svnweb.freebsd.org/changeset/base/361275 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. Submitted by: Wei Hu Reviewed by: Dexuan Cui Relnotes: yes Sponsored by: Microsoft Differential Revision:https://reviews.freebsd.org/D24061 Added: head/sys/dev/hyperv/hvsock/ head/sys/dev/hyperv/hvsock/hv_sock.c (contents, props changed) head/sys/dev/hyperv/hvsock/hv_sock.h (contents, props changed) head/sys/modules/hyperv/hvsock/ head/sys/modules/hyperv/hvsock/Makefile (contents, props changed) Modified: head/sys/conf/files.x86 head/sys/dev/hyperv/include/vmbus.h head/sys/dev/hyperv/vmbus/vmbus.c head/sys/dev/hyperv/vmbus/vmbus_br.c head/sys/dev/hyperv/vmbus/vmbus_brvar.h head/sys/dev/hyperv/vmbus/vmbus_chan.c head/sys/dev/hyperv/vmbus/vmbus_chanvar.h head/sys/dev/hyperv/vmbus/vmbus_reg.h head/sys/modules/hyperv/Makefile head/sys/sys/socket.h Modified: head/sys/conf/files.x86 == --- head/sys/conf/files.x86 Wed May 20 11:01:10 2020(r361274) +++ head/sys/conf/files.x86 Wed May 20 11:03:59 2020(r361275) @@ -133,6 +133,7 @@ dev/hwpmc/hwpmc_core.c optionalhwpmc dev/hwpmc/hwpmc_uncore.c optionalhwpmc dev/hwpmc/hwpmc_tsc.c optionalhwpmc dev/hwpmc/hwpmc_x86.c optionalhwpmc +dev/hyperv/hvsock/hv_sock.coptionalhyperv dev/hyperv/input/hv_kbd.c optionalhyperv dev/hyperv/input/hv_kbdc.c optionalhyperv dev/hyperv/pcib/vmbus_pcib.c optionalhyperv pci Added: head/sys/dev/hyperv/hvsock/hv_sock.c == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/dev/hyperv/hvsock/hv_sock.cWed May 20 11:03:59 2020 (r361275) @@ -0,0 +1,1748 @@ +/*- + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD + * + * Copyright (c) 2020 Microsoft Corp. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice unmodified, this list of conditions, and the following + *disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include + +#include "hv_sock.h" + +#define HVSOCK_DBG_NONE0x0 +#define HVSOCK_DBG_INFO0x1 +#define HVSOCK_DBG_ERR 0x2 +#define HVSOCK_DBG_VERBOSE 0x3 + + +SYSCTL_NODE(_net, OID_AUTO, hvsock, CTLFLAG_RD, 0, "HyperV socket"); + +static int hvs_dbg_level; +SYSCTL_INT(_net_hvsock, OID_AUTO, hvs_dbg_level, CTLFLAG_RWTUN, _dbg_level, +0, "hyperv socket debug level: 0 = none, 1 = info, 2 = error, 3 = verbose"); + + +#define HVSOCK_DBG(level, ...) do {\ + if (hvs_dbg_level >= (level)) \ + printf(__VA_ARGS__);\ + } while (0) + +MALLOC_DEFINE(M_HVSOCK, "hyperv_socket", "hyperv socket control structures"); + +/* The MTU is 16KB per host side's design */ +#define HVSOCK_MTU_SIZE(1024 * 16) +#define HVSOCK_SEND_BUF_SZ (PAGE_SIZE - sizeof(struct vmpipe_proto_header)) + +#define HVSOCK_HEADER_LEN (sizeof(struct hvs_pkt_header)) + +#define