|Repeatable panic in |due to locking issues and
|dummynet due to locking |use-after-free
|issues and use-after-free |
CC||ko...@freebsd.org,
||n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026
--- Comment #3 from Stanislav Trofimov ---
(In reply to Stanislav Trofimov from comment #1)
Latest p6 update fixed my problem
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026
Dmitry changed:
What|Removed |Added
CC||dkun...@gmail.com
--- Comment #2 from Dmi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026
Stanislav Trofimov changed:
What|Removed |Added
CC||norespo...@yandex.ru
--- Comm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234026
Bug ID: 234026
Summary: [panic] [dummynet] Repeatable panic in dummynet due to
locking issues and use-after-free
Product: Base System
Version: 11.2-STABLE
Hardware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=85086
Brooks Davis changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=85086
Eitan Adler changed:
What|Removed |Added
Status|In Progress |Open
--- Comment #3 from Eitan Adler
be a common anti-pattern amongst drivers.
I found something very similar in bxe. My hypothesis in both cases is that
they rolled their own simply because they don't know any better.
Understanding the locking hierarchy on either Linux or FreeBSD is something
that we all have to do a better j
Hello,
I am looking for people to give feedback on a review I've opened to
improve the locking in vlan(4). Anyone who's done a fair amount of
destroying vlan interfaces on live systems has probably run into
panics in if_vlan. This is because there is no real synchronization to
prev
I do something similar, but I rely entirely on vnet and PF instead of
netgraph. My host has two ethernet ports, so I use one for the host
and one for all of the jails. That makes the pf setup easier. I use
iocage to configure an ordinary vnet jail, bridged to the host's
second ethernet port. Th
many good questions but looking at what you are doing, maybe we should
be asking you the questions.
Certainly firewalling on the outside of the jail makes sense. I've not
used ng_ipfw but it would make sense to do a quick santity check for
every packet leaving each jail.
On 14/2/17 9:47 am, J
For several years I've been using netgraph to provide connectivity for
"service hosts" in jails on a "jail server"
Since I'm finally getting the jail server off FreeBSD 9 and solidly onto
11, I've got the chance to rewrite the scripting of how I'm handling
jail connectivity and am hoping that
own issue? If not, has anyone else had similar problems, or
does anyone know of locking issues in the CARP code which might trigger
a livelock or panic when a CARP address is added or removed?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
fre
Hello,
At Isilon we end up creating/destroying vlan interfaces a lot more
than users typically do. Unfortunately this lead to a myriad of panics
due to locking insufficiencies in if_vlan. I've fixed these internally
and I've submitted a review of the changes. I would appreciate if
an
Hi,
I have had a patch in review https://reviews.freebsd.org/D3721 for a while
which improves IPv6/UDP packets per second rates.
It’s modelled after the IPv4 version done a few years back.
In case anyone wants to or can review or test it, any feedback will be welcome.
I plan to commit it befor
Hi,
based on some work I have done a few years back I have updated an UDP6 locking
change and it’s at the “it compiles” stage. I have not re-read it yet. I’ll
have to split it up into a couple of changes for PB as it also fixes:
- some UDP-Lite bug(s)
- some control mbuf leak
- something else
On Thu, 7/30/15, Hooman Fazaeli wrote:
Subject: Re: Locking Memory Question
To: "Laurie Jennings"
Cc: "freebsd-net@freebsd.org"
Date: Thursday, July 30, 2015, 2:35 PM
On 7/30/2015 5:22 AM,
Laurie Jennings v
On 7/30/2015 5:22 AM, Laurie Jennings via freebsd-net wrote:
On Wed, 7/29/15, John-Mark Gurney wrote:
Subject: Re: Locking Memory Question
To: "Laurie Jennings"
Cc: "John Baldwin" , freebsd-net@freebsd.org
Date: Wednesd
On Thu, 7/30/15, John Baldwin wrote:
Subject: Re: Locking Memory Question
To: "K. Macy"
Cc: "freebsd-net@freebsd.org" , "John-Mark Gurney"
, "Laurie Jennings"
Date: Thursday, July 30, 2015, 10:16 AM
On Thu, 7/30/15, John Baldwin wrote:
Subject: Re: Locking Memory Question
To: "K. Macy"
Cc: "freebsd-net@freebsd.org" , "John-Mark Gurney"
, "Laurie Jennings"
Date: Thursday, July 30, 2015, 10:16 AM
On Thu, 7/30/15, John Baldwin wrote:
Subject: Re: Locking Memory Question
To: "K. Macy"
Cc: "freebsd-net@freebsd.org" , "John-Mark Gurney"
, "Laurie Jennings"
Date: Thursday, July 30, 2015, 10:16 AM
On Wednesday, July 29, 2015 11:28:03 PM K. Macy wrote:
> >>
> >> Im not clear how I'd do that. the data being passed up from the kernel is
> >> a variable size. To use copyout I'd have to pass a
> >> pointer with a static buffer, right?
> >
> > Correct, you can pass along the size, and if it's not
>>
>> Im not clear how I'd do that. the data being passed up from the kernel is a
>> variable size. To use copyout I'd have to pass a
>> pointer with a static buffer, right?
>
> Correct, you can pass along the size, and if it's not large enough
> try again... Less than ideal...
>
>> Is there a way
Laurie Jennings wrote this message on Wed, Jul 29, 2015 at 17:52 -0700:
>
> On Wed, 7/29/15, John-Mark Gurney wrote:
>
> Subject: Re: Locking Memory Question
> To: "Laurie Jennings"
> Cc: "John Baldwin" , free
On Wednesday, July 29, 2015 03:26:46 PM Laurie Jennings wrote:
>
> I have a problem and I can't quite figure out where to look. This is what Im
> doing:
>
> I have an IOCTL to read a block of data, but the data is too large to return
> via ioctl. So to get the data,
> I allocate a block in a ke
On Wed, 7/29/15, John-Mark Gurney wrote:
Subject: Re: Locking Memory Question
To: "Laurie Jennings"
Cc: "John Baldwin" , freebsd-net@freebsd.org
Date: Wednesday, July 29, 2015, 7:25 PM
Laurie Jennings via
freebsd-net w
Laurie Jennings via freebsd-net wrote this message on Wed, Jul 29, 2015 at
15:26 -0700:
>
> I have a problem and I can't quite figure out where to look. This is what Im
> doing:
>
> I have an IOCTL to read a block of data, but the data is too large to return
> via ioctl. So to get the data,
>
I have a problem and I can't quite figure out where to look. This is what Im
doing:
I have an IOCTL to read a block of data, but the data is too large to return
via ioctl. So to get the data,
I allocate a block in a kernel module:
foo = malloc(1024000,M_DEVBUF,M_WAITOK);
I pass up a pointer
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Hi,
I've created a review for this:
https://reviews.freebsd.org/D2095
It does a couple things:
* The IPv4 reassembly locking is now per-bucket, rather than global
* If space needs to be made, it's made /after/ the reassembly queue
manipulation is done. This way it's done wi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=85086
Mark Linimon changed:
What|Removed |Added
Assignee|wkos...@freebsd.org |freebsd-net@FreeBSD.org
--- Comment
locking (not to mention there is an interestng comment:
XXXRW: in6_ifaddrhead locking :>)
Yes, I'm going to fix some issues there after writing proper API.
ND changes are in https://reviews.freebsd.org/D903 .
Dropping it here in case there is someone interested in fixing
Hello there,
dtrace revealed that the kernel schedules nd6_timer a lot. Not only
that, his callout is not mpsafe so the kernel locks Giant which I
believe is an oversight.
Also the code looks really suspicious as it walks V_in6_ifaddrhead
without any locking (not to mention there is an
se of prelist_remove and how it is invoked.) One of
them succeeded, and the other was left holding a chunk of free()ed memory, and
crashed when trying to delete it.
I looked at the code surrounding this function, and I can find no sign of locking around the
prefix list or, indeed, anywhere in the call-
d.)
> One of them succeeded, and the other was left holding a chunk of free()ed
> memory, and crashed when trying to delete it.
>
> I looked at the code surrounding this function, and I can find no sign of
> locking around the prefix list or, indeed, anywhere in the call-stack
>
, and crashed when trying to delete it.
I looked at the code surrounding this function, and I can find no sign
of locking around the prefix list or, indeed, anywhere in the call-stack
(sys_ioctl=>kern_ioctl=>soo_ioctl==>ifi_ioctl=>in6_control=>prelist_remove).
I looked in HEAD, and t
Hello,
I've reworked the locking model of the ng_ipacct module
(ports/net-mgmt/ng_ipacct) for better parallel access support. I did the
following:
- convert locking from a global mutex to hash bucket level locks;
- convert a mutex to rmlock (as ip accounting data is mostly read from
Synopsis: [ip6] [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c)
State-Changed-From-To: open->closed
State-Changed-By: ae
State-Changed-When: Sun Jun 9 04:31:46 UTC 2013
State-Changed-Why:
This was fixed in r248180 and merged to stable/9, stable/8.
Responsible-Changed-From
Hi Mark,
In the patch that you provided to freebsd-net,
http://lists.freebsd.org/pipermail/freebsd-net/2013-February/034695.html, I
have a question.
nd6_timer() acquires the write lock using ND_DEFRTR_WLOCK. However,
defrouter_select again tries to acquire a read lock using ND_DEFRTR_RLOCK.
Th
n tracking down some memory corruption
> > issues that seem to be caused by a double free that can happen when
> > destroying an IPv6-enabled interface or when removing an IPv6 address
> > from an interface.
> >
> > The problem seems to be caused by a lack of locking fo
eryone,
>
> For the past little while I've been tracking down some memory corruption
> issues that seem to be caused by a double free that can happen when
> destroying an IPv6-enabled interface or when removing an IPv6 address
> from an interface.
>
> The problem seems to be
Hi Everyone,
For the past little while I've been tracking down some memory corruption
issues that seem to be caused by a double free that can happen when
destroying an IPv6-enabled interface or when removing an IPv6 address
from an interface.
The problem seems to be caused by a lack of lo
Le 9 nov. 2012 à 19:55, Alexander V. Chernikov a écrit :
> On 09.11.2012 20:51, Fabien Thomas wrote:
>>
>> Le 9 nov. 2012 à 17:43, Ingo Flaschberger a écrit :
>>
>>> Am 09.11.2012 15:03, schrieb Fabien Thomas:
In in_arpinput only exclusive access to the entry is taken during the
upda
On 09.11.2012 20:51, Fabien Thomas wrote:
Le 9 nov. 2012 à 17:43, Ingo Flaschberger a écrit :
Am 09.11.2012 15:03, schrieb Fabien Thomas:
In in_arpinput only exclusive access to the entry is taken during the update no
IF_AFDATA_LOCK that's why i was surprised.
I'll update patch to reflect c
Le 9 nov. 2012 à 17:43, Ingo Flaschberger a écrit :
> Am 09.11.2012 15:03, schrieb Fabien Thomas:
>> In in_arpinput only exclusive access to the entry is taken during the update
>> no IF_AFDATA_LOCK that's why i was surprised.
>
> what about this:
I'm not against optimizing but an API that see
Am 09.11.2012 15:03, schrieb Fabien Thomas:
In in_arpinput only exclusive access to the entry is taken during the update no
IF_AFDATA_LOCK that's why i was surprised.
what about this:
--
--- /usr/src/sys/netinet/if_ether.c_org 2012-11-09 16:15:43.0 +
+++ /usr/src/sys/netinet/if_eth
Le 9 nov. 2012 à 12:18, Alexander V. Chernikov a écrit :
> On 09.11.2012 13:59, Fabien Thomas wrote:
>>
>> Le 9 nov. 2012 à 10:05, Alexander V. Chernikov a écrit :
>>
>>> On 09.11.2012 12:51, Fabien Thomas wrote:
Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit :
> On
On 09.11.2012 13:59, Fabien Thomas wrote:
Le 9 nov. 2012 à 10:05, Alexander V. Chernikov a écrit :
On 09.11.2012 12:51, Fabien Thomas wrote:
Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit :
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wro
Le 9 nov. 2012 à 10:05, Alexander V. Chernikov a écrit :
> On 09.11.2012 12:51, Fabien Thomas wrote:
>>
>> Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit :
>>
>>> On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
> Hello list!
>
On 09.11.2012 12:51, Fabien Thomas wrote:
Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit :
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp r
Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit :
> On 08.11.2012 14:24, Andre Oppermann wrote:
>> On 08.11.2012 00:24, Alexander V. Chernikov wrote:
>>> Hello list!
>>>
>>> Currently we need to acquire 2 read locks to perform simple 6-byte
>>> copying from arp record to packet
>>> ethern
Dear Alexander,
If nobody objects I plan to commit this change at the end of next week.
LLE_RNLOCK(la); should be LLE_RLOCK(la); in arpresolve
Kind regards,
Ingo Flaschberger
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org
On 8 November 2012 13:48, Alexander V. Chernikov wrote:
>> That's a great catch! How'd you discover it?
>
> We have lots of FreeBSD routers doing 10G firewalling, so we're very much
> concerned with forwarding/firewalling performance, constantly looking for
> something to optimize :)
I mean, how
On 08.11.2012 03:46, Adrian Chadd wrote:
On 7 November 2012 15:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte copying
from arp record to packet ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow)
On 08.11.2012 11:25, Alexander V. Chernikov wrote:
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp record to packet
ethernet header.
It seems that acq
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp record to packet
ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow) is
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte copying from
arp record to packet
ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow) is not
necessary even with
current code.
My
On 7 November 2012 15:24, Alexander V. Chernikov wrote:
> Hello list!
>
> Currently we need to acquire 2 read locks to perform simple 6-byte copying
> from arp record to packet ethernet header.
>
> It seems that acquiring lle lock for fast path (main traffic flow) is not
> necessary even with curr
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp record to packet ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow) is
not necessary even with current code.
My tests shows ~10% improvement with this patch appli
On 22.10.2012 05:43, Ryan Stone wrote:
On Sun, Oct 21, 2012 at 2:21 PM, Alexander V. Chernikov
wrote:
ix:rx -> udp is also fairly obvious (here's one backtrace):
The same question, where "udp" -> "ix:rx" can happen ?
It can't happen directly as far as I can tell. But to trigger a
deadlock,
On Sun, Oct 21, 2012 at 2:21 PM, Alexander V. Chernikov
wrote:
>> ix:rx -> udp is also fairly obvious (here's one backtrace):
> The same question, where "udp" -> "ix:rx" can happen ?
It can't happen directly as far as I can tell. But to trigger a
deadlock, "all" that has to happen is that a thr
On 16.10.2012 17:20, Ryan Stone wrote:
On Tue, Oct 16, 2012 at 8:47 AM, Gleb Smirnoff wrote:
Can you please provide hints how can SIOCADDMULTI lead to obtaining RX
lock in the stock driver?
It doesn't. But it does acquire the core lock, and the core lock is
acquired before the RX lock (in ix
On Fri, Oct 19, 2012 at 8:23 AM, Alexander V. Chernikov <
melif...@freebsd.org> wrote:
> On 17.10.2012 18:06, John Baldwin wrote:
>
>> On Monday, October 15, 2012 9:04:27 am John Baldwin wrote:
>>
>>> On Monday, October 15, 2012 10:10:40 am Alexander V. Chernikov wrote:
>>>
On 13.10.2012 23:2
On 17.10.2012 18:06, John Baldwin wrote:
On Monday, October 15, 2012 9:04:27 am John Baldwin wrote:
On Monday, October 15, 2012 10:10:40 am Alexander V. Chernikov wrote:
On 13.10.2012 23:24, Jack Vogel wrote:
On Sat, Oct 13, 2012 at 11:22 AM, Luigi Rizzo wrote:
one option could be (same a
Le 18 oct. 2012 à 20:09, Jack Vogel a écrit :
> On Thu, Oct 18, 2012 at 6:20 AM, Andre Oppermann wrote:
>
>> On 13.10.2012 20:22, Luigi Rizzo wrote:
>>
>>> On Sat, Oct 13, 2012 at 09:49:21PM +0400, Alexander V. Chernikov wrote:
>>>
Hello list!
Packets receiving code for b
; one by one.
this is exactly what the dummynet code does -- collect a batch
of packets, release the lock, and then loop over the batch to feed
ip_input/ip_output or other things.
My point was, however, that instead of having to write an explicit
loop in all clients of ether_input(), we could ma
On Thu, Oct 18, 2012 at 6:20 AM, Andre Oppermann wrote:
> On 13.10.2012 20:22, Luigi Rizzo wrote:
>
>> On Sat, Oct 13, 2012 at 09:49:21PM +0400, Alexander V. Chernikov wrote:
>>
>>> Hello list!
>>>
>>>
>>> Packets receiving code for both ixgbe and if_igb looks like the
>>> following:
>>>
>>>
>>> i
On 13.10.2012 20:22, Luigi Rizzo wrote:
On Sat, Oct 13, 2012 at 09:49:21PM +0400, Alexander V. Chernikov wrote:
Hello list!
Packets receiving code for both ixgbe and if_igb looks like the following:
ixgbe_msix_que
-- ixgbe_rxeof()
{
IXGBE_RX_LOCK(rxr);
while
{
On Monday, October 15, 2012 9:04:27 am John Baldwin wrote:
> On Monday, October 15, 2012 10:10:40 am Alexander V. Chernikov wrote:
> > On 13.10.2012 23:24, Jack Vogel wrote:
> > > On Sat, Oct 13, 2012 at 11:22 AM, Luigi Rizzo wrote:
> >
> > >>
> > >> one option could be (same as it is done in the
ot;send and ignore",
but for wireless drivers where the stack implements a lot more state,
it really does quite suck. And since wireless drivers have a top level
idea of sequence and encryption (ie, it's not per-TCP stream, it's
across multiple sending streams to a given node), I can&#
threads to CPUs.
> > switches. Neither the task or the MSI-X interrupt handler are on a thread
> > that is shared with any other tasks or handlers, so all that scheduling (or
> > rescheduling) the task will do is result in the task being immediately run
> > (after either
On Tue, Oct 16, 2012 at 8:47 AM, Gleb Smirnoff wrote:
> Can you please provide hints how can SIOCADDMULTI lead to obtaining RX
> lock in the stock driver?
It doesn't. But it does acquire the core lock, and the core lock is
acquired before the RX lock (in ixgbe_init, for instance).
__
On Monday, October 15, 2012 6:36:57 pm Adrian Chadd wrote:
> The reason why I've started moving net80211 and ath _away_ from using
> direct dispatch (for now) and to using a taskqueue for TX (and RX) is
> because it's too freaking annoying right now to deal with all the
> crazy long-held locks to g
read).
If you look at the drivers, if a burst of RX traffic ends, the taskqueue
It is questionable if this behavior is good during burst:
1) Due to RX locking taskq eats signifficant (if not all) RX packets
from given queue
2) Tasq can run on any cpu so this introduces possible out-of-order
packe
On Tue, Oct 16, 2012 at 08:40:47AM -0400, Ryan Stone wrote:
R> > Are you using stock ixgbe driver?
R>
R> Pay no attention to the line numbers behind the curtain. :)
R>
R> I don't believe that I've changed the locking order at all in the
R> driver, but you are ri
On Tue, Oct 16, 2012 at 8:12 AM, Alexander V. Chernikov
wrote:
> Are you using stock ixgbe driver?
Pay no attention to the line numbers behind the curtain. :)
I don't believe that I've changed the locking order at all in the
driver, but you are right, that wasn't taken fro
On 16.10.2012 00:48, Ryan Stone wrote:
On Mon, Oct 15, 2012 at 12:29 PM, Gleb Smirnoff wrote:
To me this unlock/lock looks like a legacy from times, when the driver
had a single mutex for both TX and RX parts.
And removing this re-locking in foo_rxeof() was one of the aims for separate
TX/RX
The reason why I've started moving net80211 and ath _away_ from using
direct dispatch (for now) and to using a taskqueue for TX (and RX) is
because it's too freaking annoying right now to deal with all the
crazy long-held locks to guarantee consistency between multiple
transmitting threads.
Consid
On Mon, Oct 15, 2012 at 12:29 PM, Gleb Smirnoff wrote:
> To me this unlock/lock looks like a legacy from times, when the driver
> had a single mutex for both TX and RX parts.
>
> And removing this re-locking in foo_rxeof() was one of the aims for separate
> TX/RX locking.
>
On Monday, October 15, 2012 12:32:10 pm Gleb Smirnoff wrote:
> On Mon, Oct 15, 2012 at 09:04:27AM -0400, John Baldwin wrote:
> J> > 3) in practice taskqueue routine is a nightmare for many people since
> J> > there is no way to stop "kernel {ix0 que}" thread eating 100% cpu after
> J> > some traf
On Mon, Oct 15, 2012 at 9:58 AM, Gleb Smirnoff wrote:
> On Mon, Oct 15, 2012 at 09:39:24AM -0700, Jack Vogel wrote:
> J> > To me this unlock/lock looks like a legacy from times, when the driver
> J> > had a single mutex for both TX and RX parts.
> J> >
> J&g
On Mon, Oct 15, 2012 at 09:39:24AM -0700, Jack Vogel wrote:
J> > To me this unlock/lock looks like a legacy from times, when the driver
J> > had a single mutex for both TX and RX parts.
J> >
J> > And removing this re-locking in foo_rxeof() was one of the aims for
J> &g
On 15.10.2012 20:39, Jack Vogel wrote:
I did not want to add it back, there were problems that constrained me
to do so, although its
been some time, I'd be happy to do some testing again without and see.
We've got more than hundred routers/firewalls running under heavy load
without this lock
ich is
> A> nearly 20%.
> A>
> A> So my questions are:
> A>
> A> Can any real LORs happen in some complex setup? (I can't imagine any).
> A> If so: maybe we can somehow avoid/workaround such cases? (and consider
> A> removing those locks).
>
> To me this
On Mon, Oct 15, 2012 at 09:04:27AM -0400, John Baldwin wrote:
J> > 3) in practice taskqueue routine is a nightmare for many people since
J> > there is no way to stop "kernel {ix0 que}" thread eating 100% cpu after
J> > some traffic burst happens: once it is called it starts to schedule
J> > itse
ases? (and consider
A> removing those locks).
To me this unlock/lock looks like a legacy from times, when the driver
had a single mutex for both TX and RX parts.
And removing this re-locking in foo_rxeof() was one of the aims for separate
TX/RX locking.
Really, lurking through history shows th
On Monday, October 15, 2012 10:10:40 am Alexander V. Chernikov wrote:
> On 13.10.2012 23:24, Jack Vogel wrote:
> > On Sat, Oct 13, 2012 at 11:22 AM, Luigi Rizzo wrote:
>
> >>
> >> one option could be (same as it is done in the timer
> >> routine in dummynet) to build a list of all the packets
> >
On 13.10.2012 23:24, Jack Vogel wrote:
On Sat, Oct 13, 2012 at 11:22 AM, Luigi Rizzo wrote:
one option could be (same as it is done in the timer
routine in dummynet) to build a list of all the packets
that need to be sent to if_input(), and then call
if_input with the entire list outside the
God, yes please. Please please please please.
Adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Sat, Oct 13, 2012 at 11:22 AM, Luigi Rizzo wrote:
> On Sat, Oct 13, 2012 at 09:49:21PM +0400, Alexander V. Chernikov wrote:
> > Hello list!
> >
> >
> > Packets receiving code for both ixgbe and if_igb looks like the
> following:
> >
> >
> > ixgbe_msix_que
> >
> > -- ixgbe_rxeof()
> >{
> >
On Sat, Oct 13, 2012 at 09:49:21PM +0400, Alexander V. Chernikov wrote:
> Hello list!
>
>
> Packets receiving code for both ixgbe and if_igb looks like the following:
>
>
> ixgbe_msix_que
>
> -- ixgbe_rxeof()
>{
> IXGBE_RX_LOCK(rxr);
> while
> {
>get_packe
Hello list!
Packets receiving code for both ixgbe and if_igb looks like the following:
ixgbe_msix_que
-- ixgbe_rxeof()
{
IXGBE_RX_LOCK(rxr);
while
{
get_packet;
-- ixgbe_rx_input()
{
++ IXGBE_RX_UNLOCK(rxr);
Hey,
I have a patch here that reduces the scope of scope6 locking and I'd love
to get review/feedback for it. More details at the beginning of the file.
http://people.freebsd.org/~bz/20120502-04-scope6.diff
/bz
--
Bjoern A. Zeeb You have to have visions!
zero.
No additional locking is required here: same struct bpfif lives as long
as interface exists, so pointer will be either NULL or pointer to
structure in and period of time. Even if some thread on other CPU sees
non-coherent value - no problem. NULL means no filter is set so we skips
BPF, non
Old Synopsis: [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c)
New Synopsis: [ip6] [patch] locking error in rip6_input()
(sys/netinet6/raw_ip6.c)
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat May 21 22:48:21
On Tue, Apr 19, 2011 at 12:06 PM, K. Macy wrote:
> On Tue, Apr 19, 2011 at 8:19 PM, Freddie Cash wrote:
>> On Tue, Apr 19, 2011 at 7:42 AM, K. Macy wrote:
I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this
something
present only in HEAD?
>>>
>>> It looks like i
r_dequeue(ifp, txr->br);
}
if (enq > 0) {
/* Set the watchdog */
txr->queue_status = IGB_QUEUE_WORKING;
txr->watchdog_time = ticks;
}
return (err);
}
I haven't tested this to make sure there aren't any hid
On Tue, Apr 19, 2011 at 7:42 AM, K. Macy wrote:
>> I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this
>> something
>> present only in HEAD?
>
> It looks like it is now EM_MULTIQUEUE.
Just curious, how would one enable this to test it? We have igb(4)
interfaces in our new stor
> Hi,
>
> I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this
> something
> present only in HEAD?
It looks like it is now EM_MULTIQUEUE.
Cheers
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebs
ueing is provided by buf_ring, a
> lock-free multi-producer ring buffer written just for this purpose.
>
> Thus, the fairly low transmit rate may be attributable to driver locking.
>
> Cheers
Hi,
I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE,
1 - 100 of 247 matches
Mail list logo
