Hi Ben,
On 8/31/17 12:04 PM, Ben RUBSON wrote:
>> On 28 Aug 2017, at 11:27, Julien Charbon wrote:
>>
>> On 8/28/17 10:25 AM, Ben RUBSON wrote:
>>>> On 16 Aug 2017, at 11:02, Ben RUBSON wrote:
>>>>
>>>>> On 15 Aug 2017, at 23:33, Ju
Hi Ben,
On 8/28/17 10:25 AM, Ben RUBSON wrote:
>> On 16 Aug 2017, at 11:02, Ben RUBSON wrote:
>>
>>> On 15 Aug 2017, at 23:33, Julien Charbon wrote:
>>>
>>> On 8/11/17 11:32 AM, Ben RUBSON wrote:
>>>>> On 08 Aug 2017, at 13:33, Julie
Hi Ben,
On 8/11/17 11:32 AM, Ben RUBSON wrote:
>> On 08 Aug 2017, at 13:33, Julien Charbon wrote:
>>
>> On 8/8/17 10:31 AM, Hans Petter Selasky wrote:
>>>
>>> Suggested fix attached.
>>
>> I agree we your conclusion. Just for the record, more
Hi,
On 8/8/17 10:31 AM, Hans Petter Selasky wrote:
> On 08/08/17 10:06, Ben RUBSON wrote:
>>> On 08 Aug 2017, at 10:02, Hans Petter Selasky wrote:
>>>
>>> On 08/08/17 10:00, Ben RUBSON wrote:
kgdb) print *twq_2msl.tqh_first
$2 = {
tw_inpcb = 0xf8031c570740,
>>>
>>> print *
Hi Gleb,
On 2/16/17 7:49 PM, Gleb Smirnoff wrote:
> On Thu, Feb 09, 2017 at 10:30:24PM -0800, Gleb Smirnoff wrote:
> T> Two important updates.
> T>
> T> 1) The patch worked pretty okay, but the idea of separate file type is
> T>abandoned. With current filedescriptor code it is almost impo
Hi Gleb,
On 1/27/17 1:52 AM, Gleb Smirnoff wrote:
> as some of you already heard, I'm trying to separate listening sockets
> into a new file descriptor type. If we look into current struct socket,
> we see that some functional fields belong to normal data flow sockets,
> and other belong to li
Hi,
On 7/14/16 7:38 PM, Julien Charbon wrote:
> On 6/28/16 12:06 PM, Julien Charbon wrote:
>> On 12/7/15 4:36 PM, Julien Charbon wrote:
>>> On 30/05/14 06:12, k simon wrote:
>>>> Does any plan commit and MFC to the 10-stable ?
>>>
>>> I
Hi,
On 7/14/16 11:02 PM, Larry Rosenman wrote:
> On 2016-07-14 12:01, Julien Charbon wrote:
>> On 6/20/16 11:55 AM, Julien Charbon wrote:
>>> On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
>>>> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
>>>
Hi,
On 6/20/16 11:55 AM, Julien Charbon wrote:
> On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
>> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
>> J> > Comparing stable/10 and head, I see two changes that could
>> J> > affect that:
>> J
Hi,
On 6/28/16 12:06 PM, Julien Charbon wrote:
> On 12/7/15 4:36 PM, Julien Charbon wrote:
>> On 30/05/14 06:12, k simon wrote:
>>> Does any plan commit and MFC to the 10-stable ?
>>
>> I got a bit of interest of having the performance improvements for
>&g
Hi -net,
On 12/7/15 4:36 PM, Julien Charbon wrote:
> On 30/05/14 06:12, k simon wrote:
>> Does any plan commit and MFC to the 10-stable ?
>
> I got a bit of interest of having the performance improvements for
> short-lived TCP connections in 10-stable. Just to share the c
Hi Randall,
On 6/25/16 4:41 PM, Randall Stewart via freebsd-net wrote:
> Ok
>
> Lets try this again with my source changed to my @freebsd.net :-)
>
> Now I am also attaching a patch for you Gleb, this will take some poking to
> get in to your NF-head since it incorporates some changes we made
Hi,
On 6/20/16 11:58 AM, Gleb Smirnoff wrote:
> On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote:
> J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
> J> > J> > Comparing stable/10 and head, I see two changes that could
> J> >
Hi,
On 6/20/16 12:30 PM, Gleb Smirnoff wrote:
> On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote:
> H> On 06/20/16 11:58, Gleb Smirnoff wrote:
> H> > The fix I am working on now is doing exactly that. callout_reset must
> H> > return 0 if the callout is currently running.
> H>
Hi,
On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
> J> > Comparing stable/10 and head, I see two changes that could
> J> > affect that:
> J> >
> J> > - callout_async_drain
> J> > - sw
Hi Gleb,
On 6/17/16 6:53 AM, Gleb Smirnoff wrote:
> At Netflix we are observing a race in TCP timers with head.
> The problem is a regression, that doesn't happen on stable/10.
> The panic usually happens after several hours at 55 Gbit/s of
> traffic.
>
> What happens is that tcp_timer_keep f
Hi,
On 30/05/14 06:12, k simon wrote:
> Does any plan commit and MFC to the 10-stable ?
I got a bit of interest of having the performance improvements for
short-lived TCP connections in 10-stable. Just to share the current
status to a wider audience:
- I maintain a stack of our TCP perfor
Hi Hiren,
On 26/09/15 00:46, hiren panchasara wrote:
> On 09/25/15 at 09:42P, John Baldwin wrote:
>> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>>> So the issue is:
>>>
>>> - tcp_close() is called for some reasons with an inp in
Hi John,
On 25/09/15 18:42, John Baldwin wrote:
> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>> So the issue is:
>>
>> - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT
>> state and sets the INP_DROPPED flag,
>> - tcp
Hi Palle,
On 25/09/15 16:19, Palle Girgensohn wrote:
> [...]
> Secondly, is this error related? This is *not* VIMAGE, *not* jail.
> It is a binary installed GENERIC from freebsd-update. 10.1-RELEASE-p19. It
> just crashed today, and we did not get any core dump, but I found this
> core.txt from
Hi Palle,
On 25/09/15 16:14, Palle Girgensohn wrote:
>> 24 sep 2015 kl. 11:39 skrev Palle Girgensohn :
>>> 24 sep 2015 kl. 09:57 skrev Julien Charbon : On
>>> 24/09/15 09:03, Julien Charbon wrote:
>>>> On 24/09/15 08:55, Palle Girgensohn wrote:
>
Hi -net,
On 23/09/15 16:47, Julien Charbon wrote:
> Thanks to Palle, I got access to the kernel dump. And the results is
> more interesting than expected: Thus somehow the kernel reaches a state
> in tcp_detach() where:
>
> INP_TIMEWAIT && INP_DROPPED &&a
Hi -net,
On 24/09/15 09:03, Julien Charbon wrote:
> On 24/09/15 08:55, Palle Girgensohn wrote:
>>> 24 sep 2015 kl. 07:51 skrev Palle Girgensohn
>>> :
>>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn
>>>> :
>>>>> 23 sep 2015 kl.
Hi Palle,
On 24/09/15 08:55, Palle Girgensohn wrote:
>> 24 sep 2015 kl. 07:51 skrev Palle Girgensohn
>> :
>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn
>>> :
>>>> 23 sep 2015 kl. 20:32 skrev Julien Charbon :
>>>> On 23/09/15 20:26, Palle
Hi,
On 23/09/15 20:26, Palle Girgensohn wrote:
>> 23 sep. 2015 kl. 20:01 skrev Julien Charbon :
>> On 23/09/15 16:36, Palle Girgensohn wrote:
>>>> 22 sep 2015 kl. 23:59 skrev Julien Charbon : On
>>>> 22/09/15 22:58, Palle Girgensohn wrote:
>>>&
Hi Palle, Hi George,
On 23/09/15 16:36, Palle Girgensohn wrote:
>> 22 sep 2015 kl. 23:59 skrev Julien Charbon : On
>> 22/09/15 22:58, Palle Girgensohn wrote:
>>>> 22 sep 2015 kl. 20:16 skrev Julien Charbon :
>>>> On 22/09/15 18:49, Palle Girgensohn wrote
Hi -net,
On 22/09/15 23:59, Julien Charbon wrote:
> On 22/09/15 22:58, Palle Girgensohn wrote:
>>> 22 sep 2015 kl. 20:16 skrev Julien Charbon :
>>> On 22/09/15 18:49, Palle Girgensohn wrote:
>>>>> 22 sep 2015 kl. 18:46 skrev Palle Girgensohn
>>>
Hi Palle,
On 22/09/15 22:58, Palle Girgensohn wrote:
>> 22 sep 2015 kl. 20:16 skrev Julien Charbon :
>> On 22/09/15 18:49, Palle Girgensohn wrote:
>>>> 22 sep 2015 kl. 18:46 skrev Palle Girgensohn
>>>> :
>>>>> 21 sep 2015 kl. 15:53 skrev Pal
Hi Palle,
On 22/09/15 18:49, Palle Girgensohn wrote:
>> 22 sep 2015 kl. 18:46 skrev Palle Girgensohn
>> :
>>> 21 sep 2015 kl. 15:53 skrev Palle Girgensohn
>>> :
>>>> 21 sep 2015 kl. 10:21 skrev Julien Charbon
>>>> : On 18/09/15 18:06, Kons
Hi Palle,
On 18/09/15 22:42, Palle Girgensohn wrote:
>> 18 sep 2015 kl. 18:06 skrev Konstantin Belousov
>> :
>>
>>> On Fri, Sep 18, 2015 at 03:56:25PM +0200, Julien Charbon wrote:
>>> Hi Palle,
>>>
>>>> On 18/09/15 11:12, Palle Gir
Hi Konstantin, Hi Palle,
On 18/09/15 18:06, Konstantin Belousov wrote:
> On Fri, Sep 18, 2015 at 03:56:25PM +0200, Julien Charbon wrote:
>> Hi Palle,
>>
>> On 18/09/15 11:12, Palle Girgensohn wrote:
>>> We see daily panics on our production systems (web server
Hi Palle,
On 18/09/15 11:12, Palle Girgensohn wrote:
> We see daily panics on our production systems (web server, apache
> running MPM event, openjdk8. Kernel with VIMAGE. Jails using netgraph
> interfaces [not epair]).
>
> The problem started after the summer. Normal port upgrades seems to
> be
On 20/05/15 16:57, Adrian Chadd wrote:
> On 20 May 2015 at 06:27, Julien Charbon wrote:
>> On 26/05/14 15:36, Julien Charbon wrote:
>> [...]
>>
>> For people interested about this short-lived TCP connection scalability
>> effort, you can subscribe to the rev
Hi,
On 26/05/14 15:36, Julien Charbon wrote:
> On 23/05/14 23:37, Navdeep Parhar wrote:
>> On 05/23/14 13:52, Julien Charbon wrote:
>>> On 23/05/14 14:06, Julien Charbon wrote:
>>>> On 27/02/14 11:32, Julien Charbon wrote:
>>>>> On 07/11/13 14:55
Hi,
On 05/05/15 18:15, Julien Charbon wrote:
> I was asked if it is possible to MFC r281599 in FreeBSD 10:
>
> ---
> Fix an old and well-documented use-after-free race condition in
> TCP timers:
> - Add a reference from tcpcb to its inpcb
> - Defer tcpcb deletion
(Same exact email but with a meaningful topic this time...)
Hi list,
I was asked if it is possible to MFC r281599 in FreeBSD 10:
---
Fix an old and well-documented use-after-free race condition in
TCP timers:
- Add a reference from tcpcb to its inpcb
- Defer tcpcb deletion until TCP timers
Hi list,
I was asked if it is possible to MFC r281599 in FreeBSD 10:
---
Fix an old and well-documented use-after-free race condition in
TCP timers:
- Add a reference from tcpcb to its inpcb
- Defer tcpcb deletion until TCP timers have finished
---
https://svnweb.freebsd.org/base?view=revisi
jch added a subscriber: jch.
REVISION DETAIL
https://reviews.freebsd.org/D1438
To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn,
rrs, kostikbel, delphij, neel, erj, mat, remkolodder, bcr, brueffer, brd,
allanjude, wblock
Cc: jch, wblock, freebsd-net
__
Hi,
On 22/11/14 18:09, Robert N. M. Watson wrote:
> On 21 Nov 2014, at 17:40, Adrian Chadd wrote:
Skimming through a bunch of hosts with moderately loaded hosts
with reasonably high uptime I couldn't find one where
net.inet.tcp.timer_race was not zero. A ny suggestions how to
>>>
jch accepted this revision.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1982
To: harrison.grundy-astrodoggroup.com, gnn, adrian, glebius, jch
Cc: glebius, freebsd-net
___
freebsd-net@freebsd.org mailin
jch accepted this revision.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1982
To: harrison.grundy-astrodoggroup.com, gnn, adrian, jch
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://list
Hi,
On 03/11/14 14:29, Julien Charbon wrote:
> On 03/10/14 15:16, Julien Charbon wrote:
>> On 23/05/14 14:06, Julien Charbon wrote:
>>> On 27/02/14 11:32, Julien Charbon wrote:
>>>> On 07/11/13 14:55, Julien Charbon wrote:
>>>>> On Mon, 04 Nov 201
Hi,
On 03/10/14 15:16, Julien Charbon wrote:
> On 23/05/14 14:06, Julien Charbon wrote:
>> On 27/02/14 11:32, Julien Charbon wrote:
>>> On 07/11/13 14:55, Julien Charbon wrote:
>>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
>>>> wrote:
&g
Hi,
On 30/10/14 20:39, K. Macy wrote:
>> I also suspect there are further problems with buf_ring. A full wrap
>> around of the atomically swapped value is possible. I.e. the code thinks
>> it just atomically updated a head/tail index when in fact a full wrap
>> around occurred leading to undefi
Hi,
On 23/05/14 14:06, Julien Charbon wrote:
> On 27/02/14 11:32, Julien Charbon wrote:
>> On 07/11/13 14:55, Julien Charbon wrote:
>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
>>> wrote:
>>>> I have put technical and how-to-repeat details
Hi Adrian,
On 01/06/14 17:21, Adrian Chadd wrote:
I've been seeing this panic under high very short-term connection TCP
throughput tests (30,000 connections a second) with SO_REUSEPORT:
Current language: auto; currently minimal
(kgdb) frame 11
#11 0x80a6bdf1 in tcp_twclose (tw=0xff
Hi Simon,
On 30/05/14 06:12, k simon wrote:
Does any plan commit and MFC to the 10-stable ?
These patches are still under active review and testing, no plan to
commit soon yet. As usual having more people testing these changes (and
reporting found issues - or no issue) might accelerat
Hi,
On 23/05/14 22:52, Julien Charbon wrote:
On 23/05/14 14:06, Julien Charbon wrote:
On 27/02/14 11:32, Julien Charbon wrote:
On 07/11/13 14:55, Julien Charbon wrote:
On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
wrote:
I have put technical and how-to-repeat details in below PR
Hi Navdeep
On 23/05/14 23:37, Navdeep Parhar wrote:
On 05/23/14 13:52, Julien Charbon wrote:
On 23/05/14 14:06, Julien Charbon wrote:
On 27/02/14 11:32, Julien Charbon wrote:
On 07/11/13 14:55, Julien Charbon wrote:
On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
wrote:
I have put
Hi,
On 27/02/14 11:32, Julien Charbon wrote:
On 07/11/13 14:55, Julien Charbon wrote:
On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
wrote:
I have put technical and how-to-repeat details in below PR:
kern/183659: TCP stack lock contention with short-lived connections
http
Hi Adrian,
On 08/04/14 10:25, Adrian Chadd wrote:
Hm, how's this happening here? I'm not detaching the interface.
Hm, if your are positive that nothing is detaching the interface on
your behalf (like a /etc/rc.d/netif restart somewhere), then it looks
like you got an unrelated case that j
Hi Adrian,
On 07/04/14 04:58, Adrian Chadd wrote:
I'm seeing a panic in the multicast code path. I reproduce this by
trying to browse network sharing on VLC.
The panic:
http://people.freebsd.org/~adrian/ath/core.txt.0
Any ideas?
We believe this issue is due to a race condition in multica
Hi John,
On 07/03/14 13:43, Julien Charbon wrote:
On 06/03/14 22:57, John-Mark Gurney wrote:
Julien Charbon wrote this message on Thu, Feb 27, 2014 at 11:32 +0100:
[...]
Any thoughts on this particular behavior?
One thing that I noticed is that you now lock/unlock the tw and inp
lock a
Hi John,
On 06/03/14 22:57, John-Mark Gurney wrote:
Julien Charbon wrote this message on Thu, Feb 27, 2014 at 11:32 +0100:
[...]
Any thoughts on this particular behavior?
One thing that I noticed is that you now lock/unlock the tw and inp lock a
lot... Have you thought about grabing the
54 matches
Mail list logo
