Re: 11.0 stuck on high network load
On Mon, Oct 10, 2016 at 05:44:21PM +0200, Julien Charbon wrote: > >> can check the current other usages of goto findpcb in tcp_input(). The > >> rational here being: > >> > >> - Behavior before the patch: If the inp we found was deleted then goto > >> findpcb. > >> - Behavior after the patch: If the inp we found was deleted or dropped > >> then goto findpcb. > >> > >> I just prefer having the same behavior applied everywhere: If > >> tcp_input() loses the inp lock race and the inp was deleted or dropped > >> then retry to find a new inpcb to deliver to. > >> > >> But you are right dropping the packet here will also fix the issue. > >> > >> Then the review process becomes quite helpful because people can argue: > >> Dropping here is better because "blah", or goto findpcb is better > >> because "bluh", etc. And at the review end you have a nice final patch. > >> > >> https://reviews.freebsd.org/D8211 > > > > I am not sure, I am see to > > > > sys/netinet/in_pcb.h:#defineINP_DROPPED 0x0400 /* > protocol drop flag */ > > > > and think this is a flag 'all packets must be droped' > > Hm, I believe this flag means "this inp has been dropped by the TCP > stack, so don't use it anymore". Actually this flag is better described > in the function that sets it: > > "(INP_DROPPED) is used by TCP to mark an inpcb as unused and avoid > future packet delivery or event notification when a socket remains open > but TCP has closed." > > https://github.com/freebsd/freebsd/blob/release/11.0.0/sys/netinet/in_pcb.c#L1320 > > /* > * in_pcbdrop() removes an inpcb from hashed lists, releasing its > address and > * port reservation, and preventing it from being returned by inpcb lookups. > * > * It is used by TCP to mark an inpcb as unused and avoid future packet > * delivery or event notification when a socket remains open but TCP has > * closed. This might occur as a result of a shutdown()-initiated TCP close > * or a RST on the wire, and allows the port binding to be reused while > still > * maintaining the invariant that so_pcb always points to a valid inpcb > until > * in_pcbdetach(). > * > */ > void > in_pcbdrop(struct inpcb *inp) > { > inp->inp_flags |= INP_DROPPED; > ... > > The classical example where "goto findpcb" is useful: You receive a > new connection request with a TCP SYN packet and this packet is unlucky > and reached a inp being dropped: > > - with "goto findpcb" approach, the next lookup will most likely find > the LISTEN inp and start the TCP hand-shake as usual > - with "drop the packet" approach, the TCP client will need to > re-transmit a TCP SYN packet > > It is not because a packet was unlucky once that it deserves to be > dropped. :) Thanks for explaining, very helpfull. In this situation (TCP SYN with same 4-tuple as existing socket) allocate new PCB is best. But for this we must destroy current PCB. I am think INP_WUNLOCK(inp) don't destroy it and in_pcblookup_mbuf find it again (I am think in_pcblookup_mbuf find this PCB on first turn). I am assume for classical example in_pcbrele_wlocked(inp) free and destroy current PCB for possibility in_pcblookup_mbuf allocate new one. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 stuck on high network load
Hi, On 10/10/16 4:29 PM, Slawa Olhovchenkov wrote: > On Mon, Oct 10, 2016 at 04:03:39PM +0200, Julien Charbon wrote: >> On 10/10/16 3:32 PM, Slawa Olhovchenkov wrote: >>> On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote: On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the >> process continues and calls INP_WUNLOCK() here: >> >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > Look also to sys/netinet/tcp_timewait.c:488 > > And check other locks from r160549 You are right, and here the a fix proposal for this issue: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped https://reviews.freebsd.org/D8211 It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED inpcb should never be proceed further. Slawa, as you are the only one to reproduce this issue currently, could test this patch? (And remove the temporary patch I did provided to you before). I will wait for your tests results before pushing further. Thanks! diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index c72f01f..37f27e0 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -921,6 +921,16 @@ findpcb: goto dropwithreset; } INP_WLOCK_ASSERT(inp); + /* +* While waiting for inp lock during the lookup, another thread +* can have droppedt the inpcb, in which case we need to loop back +* and try to find a new inpcb to deliver to. +*/ + if (inp->inp_flags & INP_DROPPED) { + INP_WUNLOCK(inp); + inp = NULL; + goto findpcb; >>> >>> Are you sure about this goto? >>> Can this cause infinite loop by found same inpcb? >>> May be drop packet is more correct? >> >> Good question: Infinite loop is not possible here, as the next TCP >> hash lookup will return NULL or a fresh new and not dropped inp. You > > I am not expert in this api and don't see cause of this: I am assume > hash lookup don't remove from hash returned args and I am don't see > any removing of this inp. Why hash lookup don't return same inp? > > (assume this input patch interrupt callout code on the same CPU core). > >> can check the current other usages of goto findpcb in tcp_input(). The >> rational here being: >> >> - Behavior before the patch: If the inp we found was deleted then goto >> findpcb. >> - Behavior after the patch: If the inp we found was deleted or dropped >> then goto findpcb. >> >> I just prefer having the same behavior applied everywhere: If >> tcp_input() loses the inp lock race and the inp was deleted or dropped >> then retry to find a new inpcb to deliver to. >> >> But you are right dropping the packet here will also fix the issue. >> >> Then the review process becomes quite helpful because people can argue: >> Dropping here is better because "blah", or goto findpcb is better >> because "bluh", etc. And at the review end you have a nice final patch. >> >> https://reviews.freebsd.org/D8211 > > I am not sure, I am see to > > sys/netinet/in_pcb.h:#defineINP_DROPPED 0x0400 /* > protocol drop flag */ > > and think this is a flag 'all packets must be droped' On 10/10/16 4:29 PM, Slawa Olhovchenkov wrote: > On Mon, Oct 10, 2016 at 04:03:39PM +0200, Julien Charbon wrote: >> On 10/10/16 3:32 PM, Slawa Olhovchenkov wrote: >>> On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote: On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the >> process continues and calls INP_WUNLOCK() here: >> >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > Look also to sys/netinet/tcp_timewait.c:488 > > And check other locks from r160549 You are right, and here the a fix proposal for this issue: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped https://reviews.freebsd.org/D8211 It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED inpcb should never be proceed further. Slawa, as you are the only one to reproduce this issue currently, could test this patch? (And remove the temporary patch I did provided to you before). I will wait for your tests results before pushing further. Thanks! diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index c72f01f..37f27e0 100644
Re: 11-current becoming 11-stable
On Mon, Oct 10, 2016 at 3:48 AM, tech-listswrote: > Hi, > > I have a desktop that has run 11-current for at least the last year. I > periodically rebuild kernel and world to keep on top of things. As it's a > desktop, there are lots of ports installed. These are installed via the > older cd /port && make install clean way, rather than poudiere. > > Basically I'm asking that, when 11-stable becomes available (as far as I > can see, it's still at PRERELEASE), is it worthwhile/advisable to recompile > all my ports after doing the make world & make delete-old dance? > > thanks, > -- > J. > 11.0-RELEASE should be showing up any day. It is on Release Candidate 3. First, there is nothing outdated about building ports from source. The only time using poudiere makes real sense is when you need to build a "standard" set of ports for redistribution to other systems. If you are building for a single system, it really is just an added complication. The real choice is between building from ports or installing packages. If you need to build some ports with non-standard options, then using packages may not work for you. Mixing ports and packages can greatly complicate things and may result in unexpected issues, though it can work if you are careful. For my server I use all packages EXCEPT postfix. Since nothing depends on it, I am comfortable in building it from source whenever it is updated. That saves me a LOT of time. As to the need to update, most ports don't require rebuilding after the move to 11. FreeBSD libraries use symbol versioning so that ABI should never be broken when new versions change the API. The exception would be contributed code that is does not have symbol versioning. The most significant of these is probably OpenSSL. It is likely that ports that use the base system library will fail to run on 11. If they use the port version of OpenSSL or LibreSSL, this is not an issue. I strongly recommend that you install security/openssl and never link ports with the base system libraries. If you have done this, it is likely that any ports will need a rebuild. There are several other contributed libraries that are not commonly used by ports. These may cause some issues, but in general you can move from 10 to 11 and not re-build ports. You certainly won't need to re-build many. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11-current becoming 11-stable
Op 10/10/2016 om 12:48 schreef tech-lists: > Hi, > > I have a desktop that has run 11-current for at least the last year. I > periodically rebuild kernel and world to keep on top of things. As > it's a desktop, there are lots of ports installed. These are installed > via the older cd /port && make install clean way, rather than poudiere. > > Basically I'm asking that, when 11-stable becomes available (as far as > I can see, it's still at PRERELEASE), is it worthwhile/advisable to > recompile all my ports after doing the make world & make delete-old > dance? > > thanks, If you stay at FreeBSD 11 then there is no need to rebuild your ports. Only if you decide to go to FreeBSD 12 aka CURRENT, then you need to reinstall the ports! regards Johan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 stuck on high network load
On Mon, Oct 10, 2016 at 04:03:39PM +0200, Julien Charbon wrote: > > Hi Slawa, > > On 10/10/16 3:32 PM, Slawa Olhovchenkov wrote: > > On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote: > >> On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > >>> On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > >>> > 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the > process continues and calls INP_WUNLOCK() here: > > https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > >>> > >>> Look also to sys/netinet/tcp_timewait.c:488 > >>> > >>> And check other locks from r160549 > >> > >> You are right, and here the a fix proposal for this issue: > >> > >> Fix a double-free when an inp transitions to INP_TIMEWAIT state after > >> having been dropped > >> https://reviews.freebsd.org/D8211 > >> > >> It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED > >> inpcb should never be proceed further. > >> > >> Slawa, as you are the only one to reproduce this issue currently, could > >> test this patch? (And remove the temporary patch I did provided to you > >> before). > >> > >> I will wait for your tests results before pushing further. > >> > >> Thanks! > >> > >> diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c > >> index c72f01f..37f27e0 100644 > >> --- a/sys/netinet/tcp_input.c > >> +++ b/sys/netinet/tcp_input.c > >> @@ -921,6 +921,16 @@ findpcb: > >> goto dropwithreset; > >> } > >> INP_WLOCK_ASSERT(inp); > >> + /* > >> +* While waiting for inp lock during the lookup, another thread > >> +* can have droppedt the inpcb, in which case we need to loop back > >> +* and try to find a new inpcb to deliver to. > >> +*/ > >> + if (inp->inp_flags & INP_DROPPED) { > >> + INP_WUNLOCK(inp); > >> + inp = NULL; > >> + goto findpcb; > > > > Are you sure about this goto? > > Can this cause infinite loop by found same inpcb? > > May be drop packet is more correct? > > Good question: Infinite loop is not possible here, as the next TCP > hash lookup will return NULL or a fresh new and not dropped inp. You I am not expert in this api and don't see cause of this: I am assume hash lookup don't remove from hash returned args and I am don't see any removing of this inp. Why hash lookup don't return same inp? (assume this input patch interrupt callout code on the same CPU core). > can check the current other usages of goto findpcb in tcp_input(). The > rational here being: > > - Behavior before the patch: If the inp we found was deleted then goto > findpcb. > - Behavior after the patch: If the inp we found was deleted or dropped > then goto findpcb. > > I just prefer having the same behavior applied everywhere: If > tcp_input() loses the inp lock race and the inp was deleted or dropped > then retry to find a new inpcb to deliver to. > > But you are right dropping the packet here will also fix the issue. > > Then the review process becomes quite helpful because people can argue: > Dropping here is better because "blah", or goto findpcb is better > because "bluh", etc. And at the review end you have a nice final patch. > > https://reviews.freebsd.org/D8211 I am not sure, I am see to sys/netinet/in_pcb.h:#defineINP_DROPPED 0x0400 /* protocol drop flag */ and think this is a flag 'all packets must be droped' ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 stuck on high network load
Hi Slawa, On 10/10/16 3:32 PM, Slawa Olhovchenkov wrote: > On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote: >> On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: >>> On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: >>> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the process continues and calls INP_WUNLOCK() here: https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 >>> >>> Look also to sys/netinet/tcp_timewait.c:488 >>> >>> And check other locks from r160549 >> >> You are right, and here the a fix proposal for this issue: >> >> Fix a double-free when an inp transitions to INP_TIMEWAIT state after >> having been dropped >> https://reviews.freebsd.org/D8211 >> >> It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED >> inpcb should never be proceed further. >> >> Slawa, as you are the only one to reproduce this issue currently, could >> test this patch? (And remove the temporary patch I did provided to you >> before). >> >> I will wait for your tests results before pushing further. >> >> Thanks! >> >> diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c >> index c72f01f..37f27e0 100644 >> --- a/sys/netinet/tcp_input.c >> +++ b/sys/netinet/tcp_input.c >> @@ -921,6 +921,16 @@ findpcb: >> goto dropwithreset; >> } >> INP_WLOCK_ASSERT(inp); >> + /* >> +* While waiting for inp lock during the lookup, another thread >> +* can have droppedt the inpcb, in which case we need to loop back >> +* and try to find a new inpcb to deliver to. >> +*/ >> + if (inp->inp_flags & INP_DROPPED) { >> + INP_WUNLOCK(inp); >> + inp = NULL; >> + goto findpcb; > > Are you sure about this goto? > Can this cause infinite loop by found same inpcb? > May be drop packet is more correct? Good question: Infinite loop is not possible here, as the next TCP hash lookup will return NULL or a fresh new and not dropped inp. You can check the current other usages of goto findpcb in tcp_input(). The rational here being: - Behavior before the patch: If the inp we found was deleted then goto findpcb. - Behavior after the patch: If the inp we found was deleted or dropped then goto findpcb. I just prefer having the same behavior applied everywhere: If tcp_input() loses the inp lock race and the inp was deleted or dropped then retry to find a new inpcb to deliver to. But you are right dropping the packet here will also fix the issue. Then the review process becomes quite helpful because people can argue: Dropping here is better because "blah", or goto findpcb is better because "bluh", etc. And at the review end you have a nice final patch. https://reviews.freebsd.org/D8211 -- Julien signature.asc Description: OpenPGP digital signature
Re: Failing to upgrade from 10.1-RELEASE to 10.3-STABLE
On 10/10/16 03:04, Matthew Seaman wrote: > [...] > Most of the time you should be able to upgrade from any patch level of > release to the latest on any supported release branch using > freebsd-update(8). However there have been a number of occasions where > changes to freebsd-update itself cause that not to work. This is one of > those occasions. > > As you've discovered, the answer is to update to the latest patch level > of the branch you're already on, which will pull in the necessary fixes > to freebsd-update(8), and then you can upgrade to a more recent branch. > > As other people have noted, you can't use freebsd-update(8) to get to > 10.3-STABLE -- for that, you need to build the OS from source. > > Cheers, > > Matthew > > Thanks for the further details. -- George ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 stuck on high network load
On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote: > > Hi, > > On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > > On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > > > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the > >> process continues and calls INP_WUNLOCK() here: > >> > >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > > > Look also to sys/netinet/tcp_timewait.c:488 > > > > And check other locks from r160549 > > You are right, and here the a fix proposal for this issue: > > Fix a double-free when an inp transitions to INP_TIMEWAIT state after > having been dropped > https://reviews.freebsd.org/D8211 > > It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED > inpcb should never be proceed further. > > Slawa, as you are the only one to reproduce this issue currently, could > test this patch? (And remove the temporary patch I did provided to you > before). > > I will wait for your tests results before pushing further. > > Thanks! > > diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c > index c72f01f..37f27e0 100644 > --- a/sys/netinet/tcp_input.c > +++ b/sys/netinet/tcp_input.c > @@ -921,6 +921,16 @@ findpcb: > goto dropwithreset; > } > INP_WLOCK_ASSERT(inp); > + /* > +* While waiting for inp lock during the lookup, another thread > +* can have droppedt the inpcb, in which case we need to loop back > +* and try to find a new inpcb to deliver to. > +*/ > + if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb; Are you sure about this goto? Can this cause infinite loop by found same inpcb? May be drop packet is more correct? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 stuck on high network load
On Mon, Oct 10, 2016 at 01:26:12PM +0200, Julien Charbon wrote: > > Hi, > > On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > > On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > > > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the > >> process continues and calls INP_WUNLOCK() here: > >> > >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > > > Look also to sys/netinet/tcp_timewait.c:488 > > > > And check other locks from r160549 > > You are right, and here the a fix proposal for this issue: > > Fix a double-free when an inp transitions to INP_TIMEWAIT state after > having been dropped > https://reviews.freebsd.org/D8211 > > It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED > inpcb should never be proceed further. > > Slawa, as you are the only one to reproduce this issue currently, could > test this patch? (And remove the temporary patch I did provided to you > before). > > I will wait for your tests results before pushing further. OK, I am will try it tomorrow Thanks! > Thanks! > > diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c > index c72f01f..37f27e0 100644 > --- a/sys/netinet/tcp_input.c > +++ b/sys/netinet/tcp_input.c > @@ -921,6 +921,16 @@ findpcb: > goto dropwithreset; > } > INP_WLOCK_ASSERT(inp); > + /* > +* While waiting for inp lock during the lookup, another thread > +* can have droppedt the inpcb, in which case we need to loop back > +* and try to find a new inpcb to deliver to. > +*/ > + if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb; > + } > if ((inp->inp_flowtype == M_HASHTYPE_NONE) && > (M_HASHTYPE_GET(m) != M_HASHTYPE_NONE) && > ((inp->inp_socket == NULL) || > @@ -981,6 +991,10 @@ relocked: > if (in_pcbrele_wlocked(inp)) { > inp = NULL; > goto findpcb; > + } else if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb; > } > } else > ti_locked = TI_RLOCKED; > @@ -1040,6 +1054,10 @@ relocked: > if (in_pcbrele_wlocked(inp)) { > inp = NULL; > goto findpcb; > + } else if (inp->inp_flags & INP_DROPPED) { > + INP_WUNLOCK(inp); > + inp = NULL; > + goto findpcb; > } > goto relocked; > } else > > -- > Julien > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 stuck on high network load
Hi, On 10/6/16 1:10 PM, Slawa Olhovchenkov wrote: > On Thu, Oct 06, 2016 at 09:28:06AM +0200, Julien Charbon wrote: > >> 2. thread1: In tcp_close() the inp is marked with INP_DROPPED flag, the >> process continues and calls INP_WUNLOCK() here: >> >> https://github.com/freebsd/freebsd/blob/releng/11.0/sys/netinet/tcp_subr.c#L1568 > > Look also to sys/netinet/tcp_timewait.c:488 > > And check other locks from r160549 You are right, and here the a fix proposal for this issue: Fix a double-free when an inp transitions to INP_TIMEWAIT state after having been dropped https://reviews.freebsd.org/D8211 It basically enforces in_pcbdrop() logic in tcp_input(): A INP_DROPPED inpcb should never be proceed further. Slawa, as you are the only one to reproduce this issue currently, could test this patch? (And remove the temporary patch I did provided to you before). I will wait for your tests results before pushing further. Thanks! diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index c72f01f..37f27e0 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -921,6 +921,16 @@ findpcb: goto dropwithreset; } INP_WLOCK_ASSERT(inp); + /* +* While waiting for inp lock during the lookup, another thread +* can have droppedt the inpcb, in which case we need to loop back +* and try to find a new inpcb to deliver to. +*/ + if (inp->inp_flags & INP_DROPPED) { + INP_WUNLOCK(inp); + inp = NULL; + goto findpcb; + } if ((inp->inp_flowtype == M_HASHTYPE_NONE) && (M_HASHTYPE_GET(m) != M_HASHTYPE_NONE) && ((inp->inp_socket == NULL) || @@ -981,6 +991,10 @@ relocked: if (in_pcbrele_wlocked(inp)) { inp = NULL; goto findpcb; + } else if (inp->inp_flags & INP_DROPPED) { + INP_WUNLOCK(inp); + inp = NULL; + goto findpcb; } } else ti_locked = TI_RLOCKED; @@ -1040,6 +1054,10 @@ relocked: if (in_pcbrele_wlocked(inp)) { inp = NULL; goto findpcb; + } else if (inp->inp_flags & INP_DROPPED) { + INP_WUNLOCK(inp); + inp = NULL; + goto findpcb; } goto relocked; } else -- Julien signature.asc Description: OpenPGP digital signature
11-current becoming 11-stable
Hi, I have a desktop that has run 11-current for at least the last year. I periodically rebuild kernel and world to keep on top of things. As it's a desktop, there are lots of ports installed. These are installed via the older cd /port && make install clean way, rather than poudiere. Basically I'm asking that, when 11-stable becomes available (as far as I can see, it's still at PRERELEASE), is it worthwhile/advisable to recompile all my ports after doing the make world & make delete-old dance? thanks, -- J. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Do not upgrade Hyper-V instances from 10.x to 11.x yet
11.0-RELEASE has issues with Hyper-V compatibility. It does not recognizes and then detaches virtual disk. storvsc0: on vmbus0 (probe0:blkvsc0:0:0:0): storvsc scsi_status = 2 (probe0:blkvsc0:0:1:1): invalid LUN 1 ... (probe0:blkvsc0:0:0:1): invalid LUN 1 da0 at blkvsc0 bus 0 scbus1 target 0 lun 0 da0: da0 at blkvsc0 bus 0 scbus1 target 0 lun 0 da0: detached Unfortunately bug affects possibility to upgrade existing instances and prevents new 11.0 installations in Hyper-V environment. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212721 I guess that this might be fixed with an errata notice after the release announcement. --- Best Regards, Alexander ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failing to upgrade from 10.1-RELEASE to 10.3-STABLE
On 09/10/2016 23:56, George Mitchell wrote: > On 10/09/16 15:57, Kurt Jaeger wrote: >> Hi! >> >>> What am I doing wrong? (I get the same failure attempting to upgrade >>> to 10.1-RELEASE and 10.2-RELEASE.) -- George >> >> Ah, one thing: >> >> Please do update to the latest 10.1-REL patch level, first. >> > After upgrading to the latest 10.1-RELEASE: > > I can update to 10.3-RELEASE, and that will probably do for now. > Should it have worked to update from 10.1-RELEASE to 10.3-STABLE > directly? If I decide to upgrade from 10.3-RELEASE to 10.3-STABLE > later on, should I expect that to work? -- George Most of the time you should be able to upgrade from any patch level of release to the latest on any supported release branch using freebsd-update(8). However there have been a number of occasions where changes to freebsd-update itself cause that not to work. This is one of those occasions. As you've discovered, the answer is to update to the latest patch level of the branch you're already on, which will pull in the necessary fixes to freebsd-update(8), and then you can upgrade to a more recent branch. As other people have noted, you can't use freebsd-update(8) to get to 10.3-STABLE -- for that, you need to build the OS from source. Cheers, Matthew signature.asc Description: OpenPGP digital signature