Re: 11.0 stuck on high network load

[Slawa Olhovchenkov]

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

[Julien Charbon]

 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

[Kevin Oberman]

On Mon, Oct 10, 2016 at 3:48 AM, tech-lists  wrote:

> 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

[Johan Hendriks]

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

[Slawa Olhovchenkov]

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

[Julien Charbon]

 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

[George Mitchell]

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

[Slawa Olhovchenkov]

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

[Slawa Olhovchenkov]

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

[Julien Charbon]

 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

[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,
--
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

[Alexander Shitov]

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

[Matthew Seaman]

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