History log of /freebsd/sys/netinet/in_pcb.h (Results 226 – 250 of 514)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 8b12a7c2 16-Apr-2009 Kip Macy <kmacy@FreeBSD.org>

- convert pspare pointers in inpcb to an llentry and rtentry cache
- add flags to indicate their validity


# 773b573a 16-Apr-2009 Kip Macy <kmacy@FreeBSD.org>

- add second flags field to to inpcb
- update comments in vflag


# 82c33e73 15-Apr-2009 Kip Macy <kmacy@FreeBSD.org>

provide additional convenience macros for inpcb locking (upgrade, downgrade, exclusive)


# 9c797940 13-Apr-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- Merge from HEAD


# 80cb9f21 10-Apr-2009 Kip Macy <kmacy@FreeBSD.org>

Import "flowid" support for serializing flows across transmit queues

Reviewed by: rwatson and jeli


# ad71fe3c 15-Mar-2009 Robert Watson <rwatson@FreeBSD.org>

Correct a number of evolved problems with inp_vflag and inp_flags:
certain flags that should have been in inp_flags ended up in inp_vflag,
meaning that they were inconsistently locked, and in one cas

Correct a number of evolved problems with inp_vflag and inp_flags:
certain flags that should have been in inp_flags ended up in inp_vflag,
meaning that they were inconsistently locked, and in one case,
interpreted. Move the following flags from inp_vflag to gaps in the
inp_flags space (and clean up the inp_flags constants to make gaps
more obvious to future takers):

INP_TIMEWAIT
INP_SOCKREF
INP_ONESBCAST
INP_DROPPED

Some aspects of this change have no effect on kernel ABI at all, as these
are UDP/TCP/IP-internal uses; however, netstat and sockstat detect
INP_TIMEWAIT when listing TCP sockets, so any MFC will need to take this
into account.

MFC after: 1 week (or after dependencies are MFC'd)
Reviewed by: bz

show more ...


# 1829d5da 12-Mar-2009 Warner Losh <imp@FreeBSD.org>

Update the projects tree to a newer FreeBSD current.


# 111d57a6 11-Mar-2009 Robert Watson <rwatson@FreeBSD.org>

Add INP_INHASHLIST flag for inpcb->inp_flags to indicate whether
or not the inpcb is currenty on various hash lookup lists, rather
than using (lport != 0) to detect this. This means that the full
4-

Add INP_INHASHLIST flag for inpcb->inp_flags to indicate whether
or not the inpcb is currenty on various hash lookup lists, rather
than using (lport != 0) to detect this. This means that the full
4-tuple of a connection can be retained after close, which should
lead to more sensible netstat output in the window between TCP
close and socket close.

MFC after: 2 weeks

show more ...


# 4cf172fd 10-Mar-2009 Robert Watson <rwatson@FreeBSD.org>

Remove unused v6 macro aliases for inpcb fields:

in6p_ip6_nxt
in6p_vflag
in6p_flags
in6p_socket
in6p_lport
in6p_fport
in6p_ppcb

Remove unused

Remove unused v6 macro aliases for inpcb fields:

in6p_ip6_nxt
in6p_vflag
in6p_flags
in6p_socket
in6p_lport
in6p_fport
in6p_ppcb

Remove unused v6 macro aliases for inpcb flags:

IN6P_HIGHPORT
IN6P_LOWPORT
IN6P_ANONPORT
IN6P_RECVIF
IN6P_MTUDISC
IN6P_FAITH
IN6P_CONTROLOPTS

References to in6p_lport and in6_fport in sockstat are also replaced with
normal inp_lport and inp_fport references.

MFC after: 3 days
Reviewed by: bz

show more ...


# b9bbb597 10-Mar-2009 Robert Watson <rwatson@FreeBSD.org>

Remove now-unused INP_UNMAPPABLEOPTS.

MFC after: 3 days
Discussed with: bz


# be9347e3 09-Jan-2009 Adrian Chadd <adrian@FreeBSD.org>

Implement a new IP option (not compiled/enabled by default) to allow
applications to specify a non-local IP address when bind()'ing a socket
to a local endpoint.

This allows applications to spoof th

Implement a new IP option (not compiled/enabled by default) to allow
applications to specify a non-local IP address when bind()'ing a socket
to a local endpoint.

This allows applications to spoof the client IP address of connections
if (obviously!) they somehow are able to receive the traffic normally
destined to said clients.

This patch doesn't include any changes to ipfw or the bridging code to
redirect the client traffic through the PCB checks so TCP gets a shot
at it. The normal behaviour is that packets with a non-local destination
IP address are not handled locally. This can be dealth with some IPFW hackery;
modifications to IPFW to make this less hacky will occur in subsequent
commmits.

Thanks to Julian Elischer and others at Ironport. This work was approved
and donated before Cisco acquired them.

Obtained from: Julian Elischer and others
MFC after: 2 weeks

show more ...


Revision tags: release/7.1.0_cvs, release/7.1.0
# 41fe50f5 20-Dec-2008 Sam Leffler <sam@FreeBSD.org>

MFH @ 186335


# 97590249 17-Dec-2008 Bjoern A. Zeeb <bz@FreeBSD.org>

Another step assimilating IPv[46] PCB code:
normalize IN6P_* compat flags usage to their equialent
INP_* counterpart.

Discussed with: rwatson
Reviewed by: rwatson
MFC after: 4 weeks


# dcdb4371 17-Dec-2008 Bjoern A. Zeeb <bz@FreeBSD.org>

Use inc_flags instead of the inc_isipv6 alias which so far
had been the only flag with random usage patterns.
Switch inc_flags to be used as a real bit field by using
INC_ISIPV6 with bitops to check

Use inc_flags instead of the inc_isipv6 alias which so far
had been the only flag with random usage patterns.
Switch inc_flags to be used as a real bit field by using
INC_ISIPV6 with bitops to check for the 'isipv6' condition.

While here fix a place or two where in case of v4 inc_flags
were not properly initialized before.[1]

Found by: rwatson during review [1]
Discussed with: rwatson
Reviewed by: rwatson
MFC after: 4 weeks

show more ...


# 86413abf 11-Dec-2008 Bjoern A. Zeeb <bz@FreeBSD.org>

Put a global variables, which were virtualized but formerly
missed under VIMAGE_GLOBAL.

Start putting the extern declarations of the virtualized globals
under VIMAGE_GLOBAL as the globals themsevle

Put a global variables, which were virtualized but formerly
missed under VIMAGE_GLOBAL.

Start putting the extern declarations of the virtualized globals
under VIMAGE_GLOBAL as the globals themsevles are already.
This will help by the time when we are going to remove the globals
entirely.

While there garbage collect a few dead externs from ip6_var.h.

Sponsored by: The FreeBSD Foundation

show more ...


# 0ca989b3 10-Dec-2008 Robert Watson <rwatson@FreeBSD.org>

Update comment on INP_TIMEWAIT to say what it's about, as we caution
regarding the misplacement of flags in inp_vflag in an earlier comment.

MFC after: pretty soon


# a5654bb2 09-Dec-2008 Robert Watson <rwatson@FreeBSD.org>

Move macros defining flags and shortcus to nested structure fields in
inpcbinfo below the structure definition in order to make inpcbinfo
fit on a single printed page; related style tweaks.

MFC afte

Move macros defining flags and shortcus to nested structure fields in
inpcbinfo below the structure definition in order to make inpcbinfo
fit on a single printed page; related style tweaks.

MFC after: pretty soon

show more ...


# 28696211 08-Dec-2008 Robert Watson <rwatson@FreeBSD.org>

Add a reference count to struct inpcb, which may be explicitly
incremented using in_pcbref(), and decremented using in_pcbfree()
or inpcbrele(). Protocols using only current in_pcballoc() and
in_pcb

Add a reference count to struct inpcb, which may be explicitly
incremented using in_pcbref(), and decremented using in_pcbfree()
or inpcbrele(). Protocols using only current in_pcballoc() and
in_pcbfree() calls will see the same semantics, but it is now
possible for TCP to call in_pcbref() and in_pcbrele() to prevent
an inpcb from being freed when both tcbinfo and per-inpcb locks
are released. This makes it possible to safely transition from
holding only the inpcb lock to both tcbinfo and inpcb lock
without re-looking up a connection in the input path, timer
path, etc.

Notice that in_pcbrele() does not unlock the connection after
decrementing the refcount, if the connection remains, so that
the caller can continue to use it; in_pcbrele() returns a flag
indicating whether or not the inpcb pointer is still valid, and
in_pcbfee() is now a simple wrapper around in_pcbrele().

MFC after: 1 month
Discussed with: bz, kmacy
Reviewed by: bz, gnn, kmacy
Tested by: kmacy

show more ...


# e57c2b13 04-Dec-2008 Dag-Erling Smørgrav <des@FreeBSD.org>

integrate from head@185615


Revision tags: release/6.4.0_cvs, release/6.4.0
# 44e33a07 19-Nov-2008 Marko Zec <zec@FreeBSD.org>

Change the initialization methodology for global variables scheduled
for virtualization.

Instead of initializing the affected global variables at instatiation,
assign initial values to them in initi

Change the initialization methodology for global variables scheduled
for virtualization.

Instead of initializing the affected global variables at instatiation,
assign initial values to them in initializer functions. As a rule,
initialization at instatiation for such variables should never be
introduced again from now on. Furthermore, enclose all instantiations
of such global variables in #ifdef VIMAGE_GLOBALS blocks.

Essentialy, this change should have zero functional impact. In the next
phase of merging network stack virtualization infrastructure from
p4/vimage branch, the new initialization methology will allow us to
switch between using global variables and their counterparts residing in
virtualization containers with minimum code churn, and in the long run
allow us to intialize multiple instances of such container structures.

Discussed at: devsummit Strassburg
Reviewed by: bz, julian
Approved by: julian (mentor)
Obtained from: //depot/projects/vimage-commit2/...
X-MFC after: never
Sponsored by: NLnet Foundation, The FreeBSD Foundation

show more ...


# dc3c09c8 20-Oct-2008 Bjoern A. Zeeb <bz@FreeBSD.org>

Bring over the change switching from using sequential to random
ephemeral port allocation as implemented in netinet/in_pcb.c rev. 1.143
(initially from OpenBSD) and follow-up commits during the last

Bring over the change switching from using sequential to random
ephemeral port allocation as implemented in netinet/in_pcb.c rev. 1.143
(initially from OpenBSD) and follow-up commits during the last four and
a half years including rev. 1.157, 1.162 and 1.199.
This now is relying on the same infrastructure as has been implemented
in in_pcb.c since rev. 1.199.

Reviewed by: silby, rpaulo, mlaier
MFC after: 2 months

show more ...


# 86d02c5c 04-Oct-2008 Bjoern A. Zeeb <bz@FreeBSD.org>

Cache so_cred as inp_cred in the inpcb.
This means that inp_cred is always there, even after the socket
has gone away. It also means that it is constant for the lifetime
of the inp.
Both facts lead t

Cache so_cred as inp_cred in the inpcb.
This means that inp_cred is always there, even after the socket
has gone away. It also means that it is constant for the lifetime
of the inp.
Both facts lead to simpler code and possibly less locking.

Suggested by: rwatson
Reviewed by: rwatson
MFC after: 6 weeks
X-MFC Note: use a inp_pspare for inp_cred

show more ...


# fc18af96 29-Sep-2008 Robert Watson <rwatson@FreeBSD.org>

Fix typo in comment.

MFC after: 3 days


# 5cb2685a 07-Aug-2008 Robert Watson <rwatson@FreeBSD.org>

Minor white space tweaks.

MFC after: 1 week


# df9cf830 22-Jul-2008 Tai-hwa Liang <avatar@FreeBSD.org>

Trying to fix compilation bustage:
- removing 'const' qualifier from an input parameter to conform to the type
required by rw_assert();
- using in_addr->s_addr to retrive 32 bits address value.

Ob

Trying to fix compilation bustage:
- removing 'const' qualifier from an input parameter to conform to the type
required by rw_assert();
- using in_addr->s_addr to retrive 32 bits address value.

Observed by: tinderbox

show more ...


12345678910>>...21