#
246e7a2b |
| 02-Sep-2014 |
Neel Natu <neel@FreeBSD.org> |
IFC @r269962
Submitted by: Anish Gupta (akgupt3@gmail.com)
|
#
ee7b0571 |
| 19-Aug-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge head from 7/28
|
#
1b833d53 |
| 13-Aug-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r269943.
|
#
d5bb8bd3 |
| 12-Jul-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Expose in_pcbbind_check_bindmulti() so the upcoming IPv6 RSS changes can be made to use it.
|
Revision tags: release/9.3.0 |
|
#
0a100a6f |
| 10-Jul-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Implement the first stage of multi-bind listen sockets and RSS socket awareness.
* Introduce IP_BINDMULTI - indicating that it's okay to bind multiple sockets on the same bind details.
Although
Implement the first stage of multi-bind listen sockets and RSS socket awareness.
* Introduce IP_BINDMULTI - indicating that it's okay to bind multiple sockets on the same bind details.
Although the PCB code has been taught about this (see below) this patch doesn't introduce the rest of the PCB changes necessary to distribute lookups among multiple PCB entries in the global wildcard table.
* Introduce IP_RSS_LISTEN_BUCKET - placing an listen socket into the given RSS bucket (and thus a single PCBGROUP hash.)
* Modify the PCB add path to be aware of IP_BINDMULTI: + Only allow further PCB entries to be added if the owner credentials and IP_BINDMULTI has been specified. Ie, only allow further IP_BINDMULTI sockets to appear if the first bind() was IP_BINDMULTI.
* Teach the PCBGROUP code about IP_RSS_LISTE_BUCKET marked PCB entries. Instead of using the wildcard logic and hashing, these sockets are simply placed into the PCBGROUP and _not_ in the wildcard hash.
* When doing a PCBGROUP lookup, also do a wildcard match as well. This allows for an RSS bucket PCB entry to appear in a PCBGROUP rather than having to exist in the wildcard list.
Tested:
* TCP IPv4 server testing with igb(4) * TCP IPv4 server testing with ix(4)
TODO:
* The pcbgroup lookup code duplicated the wildcard and wildcard-PCB logic. This could be refactored into a single function.
* This doesn't yet work for IPv6 (The PCBGROUP code in netinet6/ doesn't yet know about this); nor does it yet fully work for UDP.
show more ...
|
#
6cec9cad |
| 03-Jun-2014 |
Peter Grehan <grehan@FreeBSD.org> |
MFC @ r266724
An SVM update will follow this.
|
#
414fdaf0 |
| 21-May-2014 |
Alan Somers <asomers@FreeBSD.org> |
IFC @266473
|
#
34e3dced |
| 19-May-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Add the flowtype to the inpcb.
The flowid isn't enough to use as part of any RSS related CPU affinity lookups - the RSS code would like to know what kind of hash it is.
|
#
3b8f0845 |
| 28-Apr-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge head
|
#
ae190832 |
| 24-Apr-2014 |
Steven Hartland <smh@FreeBSD.org> |
Fix jailed raw sockets not setting the correct source address by calling in_pcbladdr instead of prison_get_ip4
MFC after: 1 month
|
Revision tags: release/10.0.0 |
|
#
0bfd163f |
| 18-Oct-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r256722.
|
Revision tags: release/9.2.0 |
|
#
d1d01586 |
| 05-Sep-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head
|
#
40f65a4d |
| 07-Aug-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r254014
|
#
552311f4 |
| 17-Jul-2013 |
Xin LI <delphij@FreeBSD.org> |
IFC @253398
|
#
ceae90c2 |
| 05-Jul-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r252763
|
#
efdf104b |
| 04-Jul-2013 |
Mikolaj Golub <trociny@FreeBSD.org> |
In r227207, to fix the issue with possible NULL inp_socket pointer dereferencing, when checking for SO_REUSEPORT option (and SO_REUSEADDR for multicast), INP_REUSEPORT flag was introduced to cache th
In r227207, to fix the issue with possible NULL inp_socket pointer dereferencing, when checking for SO_REUSEPORT option (and SO_REUSEADDR for multicast), INP_REUSEPORT flag was introduced to cache the socket option. It was decided then that one flag would be enough to cache both SO_REUSEPORT and SO_REUSEADDR: when processing SO_REUSEADDR setsockopt(2), it was checked if it was called for a multicast address and INP_REUSEPORT was set accordingly.
Unfortunately that approach does not work when setsockopt(2) is called before binding to a multicast address: the multicast check fails and INP_REUSEPORT is not set.
Fix this by adding INP_REUSEADDR flag to unconditionally cache SO_REUSEADDR.
PR: 179901 Submitted by: Michael Gmelin freebsd grem.de (initial version) Reviewed by: rwatson MFC after: 1 week
show more ...
|
#
cfe30d02 |
| 19-Jun-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge fresh head.
|
Revision tags: release/8.4.0 |
|
#
f89d4c3a |
| 06-May-2013 |
Andre Oppermann <andre@FreeBSD.org> |
Back out r249318, r249320 and r249327 due to a heisenbug most likely related to a race condition in the ipi_hash_lock with the exact cause currently unknown but under investigation.
|
#
69e6d7b7 |
| 12-Apr-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
sync from head
|
#
e8b3186b |
| 09-Apr-2013 |
Andre Oppermann <andre@FreeBSD.org> |
Change certain heavily used network related mutexes and rwlocks to reside on their own cache line to prevent false sharing with other nearby structures, especially for those in the .bss segment.
NB:
Change certain heavily used network related mutexes and rwlocks to reside on their own cache line to prevent false sharing with other nearby structures, especially for those in the .bss segment.
NB: Those mutexes and rwlocks with variables next to them that get changed on every invocation do not benefit from their own cache line. Actually it may be net negative because two cache misses would be incurred in those cases.
show more ...
|
Revision tags: release/9.1.0 |
|
#
e477abf7 |
| 27-Nov-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC @ r241285
|
#
a10c6f55 |
| 11-Nov-2012 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r242684
|
#
23090366 |
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
#
df4e91d3 |
| 02-Oct-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
There is a complex race in in_pcblookup_hash() and in_pcblookup_group(). Both functions need to obtain lock on the found PCB, and they can't do classic inter-lock with the PCB hash lock, due to lock
There is a complex race in in_pcblookup_hash() and in_pcblookup_group(). Both functions need to obtain lock on the found PCB, and they can't do classic inter-lock with the PCB hash lock, due to lock order reversal. To keep the PCB stable, these functions put a reference on it and after PCB lock is acquired drop it. If the reference was the last one, this means we've raced with in_pcbfree() and the PCB is no longer valid.
This approach works okay only if we are acquiring writer-lock on the PCB. In case of reader-lock, the following scenario can happen:
- 2 threads locate pcb, and do in_pcbref() on it. - These 2 threads drop the inp hash lock. - Another thread comes to delete pcb via in_pcbfree(), it obtains hash lock, does in_pcbremlists(), drops hash lock, and runs in_pcbrele_wlocked(), which doesn't free the pcb due to two references on it. Then it unlocks the pcb. - 2 aforementioned threads acquire reader lock on the pcb and run in_pcbrele_rlocked(). One gets 1 from in_pcbrele_rlocked() and continues, second gets 0 and considers pcb freed, returns. - The thread that got 1 continutes working with detached pcb, which later leads to panic in the underlying protocol level.
To plumb that problem an additional INPCB flag introduced - INP_FREED. We check for that flag in the in_pcbrele_rlocked() and if it is set, we pretend that that was the last reference.
Discussed with: rwatson, jhb Reported by: Vladimir Medvedkin <medved rambler-co.ru>
show more ...
|
#
de720122 |
| 15-Jul-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r236710 through r238467.
|