Revision tags: release/14.3.0, release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0, release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0, release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0 |
|
#
0daa334c |
| 03-Apr-2020 |
Fernando Gont <fernando@gont.com.ar> |
inet6: RFC 8981 SLAAC Temporary Address Extensions
Initial implementation of SLAAC temporary address extensions back when they were still draft-ietf-6man-rfc4941bis.
PR: 245103 MFC after: 1 month
|
#
e64fe5ad |
| 21-May-2025 |
Zhenlei Huang <zlei@FreeBSD.org> |
netinet6: Remove a set but not used global variable in6_maxmtu
and its setter in6_setmaxmtu().
This variable was introduced by the KAME projec [1]. It holds the max IPv6 MTU through all the interfa
netinet6: Remove a set but not used global variable in6_maxmtu
and its setter in6_setmaxmtu().
This variable was introduced by the KAME projec [1]. It holds the max IPv6 MTU through all the interfaces, but is never used anywhere.
[1] 82cd038d51e2 KAME netinet6 basic part(no IPsec,no V6 Multicast Forwarding, no UDP/TCP for IPv6 yet)
Reviewed by: glebius MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D49357
show more ...
|
#
fdafd315 |
| 24-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Automated cleanup of cdefs and other formatting
Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row.
Remov
sys: Automated cleanup of cdefs and other formatting
Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
show more ...
|
#
685dc743 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
3d0d5b21 |
| 23-Jan-2023 |
Justin Hibbits <jhibbits@FreeBSD.org> |
IfAPI: Explicitly include <net/if_private.h> in netstack
Summary: In preparation of making if_t completely opaque outside of the netstack, explicitly include the header. <net/if_var.h> will stop in
IfAPI: Explicitly include <net/if_private.h> in netstack
Summary: In preparation of making if_t completely opaque outside of the netstack, explicitly include the header. <net/if_var.h> will stop including the header in the future.
Sponsored by: Juniper Networks, Inc. Reviewed by: glebius, melifaro Differential Revision: https://reviews.freebsd.org/D38200
show more ...
|
#
663428ea |
| 09-Aug-2021 |
Mark Johnston <markj@FreeBSD.org> |
nd6: Mark several callouts as MPSAFE
The use of Giant here is vestigal and does not provide any useful synchronization. Furthermore, non-MPSAFE callouts can cause the softclock threads to block wai
nd6: Mark several callouts as MPSAFE
The use of Giant here is vestigal and does not provide any useful synchronization. Furthermore, non-MPSAFE callouts can cause the softclock threads to block waiting for long-running newbus operations to complete.
Reported by: mav Reviewed by: bz MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31470
show more ...
|
#
8ee0826f |
| 09-Aug-2021 |
Mark Johnston <markj@FreeBSD.org> |
in6: Enter the net epoch in in6_tmpaddrtimer()
We need to do so to safely traverse the ifnet list.
Reviewed by: bz MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: http
in6: Enter the net epoch in in6_tmpaddrtimer()
We need to do so to safely traverse the ifnet list.
Reviewed by: bz MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31470
show more ...
|
#
8268d82c |
| 15-Feb-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Remove per-packet ifa refcounting from IPv6 fast path.
Currently ip6_input() calls in6ifa_ifwithaddr() for every local packet, in order to check if the target ip belongs to the local ifa in proper
Remove per-packet ifa refcounting from IPv6 fast path.
Currently ip6_input() calls in6ifa_ifwithaddr() for every local packet, in order to check if the target ip belongs to the local ifa in proper state and increase its counters.
in6ifa_ifwithaddr() references found ifa. With epoch changes, both `ip6_input()` and all other current callers of `in6ifa_ifwithaddr()` do not need this reference anymore, as epoch provides stability guarantee.
Given that, update `in6ifa_ifwithaddr()` to allow it to return ifa without referencing it, while preserving option for getting referenced ifa if so desired.
MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D28648
show more ...
|
#
e58c8da0 |
| 13-Jan-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Map IPv6 link-local prefix to the link-local ifa.
Currently we create link-local route by creating an always-on IPv6 prefix in the prefix list. This prefix is not tied to the link-local ifa.
This
Map IPv6 link-local prefix to the link-local ifa.
Currently we create link-local route by creating an always-on IPv6 prefix in the prefix list. This prefix is not tied to the link-local ifa.
This leads to the following problems:
First, when flushing interface addresses we skip on-link route, leaving fe80::/64 prefix on the interface without any IPv6 addresses. Second, when creating and removing link-local alias we lose fe80::/64 prefix from the routing table.
Fix this by attaching link-local prefix to the ifa at the initial creation.
Reviewed by: hrs MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D28129
show more ...
|
#
440cec3f |
| 12-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
8460d754 |
| 10-Aug-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r364051 through r364081.
|
#
3689652c |
| 10-Aug-2020 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Make sure the multicast release tasks are properly drained when destroying a VNET or a network interface.
Else the inm release tasks, both IPv4 and IPv6 may cause a panic accessing a freed VNET or n
Make sure the multicast release tasks are properly drained when destroying a VNET or a network interface.
Else the inm release tasks, both IPv4 and IPv6 may cause a panic accessing a freed VNET or network interface.
Reviewed by: jmg@ Discussed with: bz@ Differential Revision: https://reviews.freebsd.org/D24914 MFC after: 1 week Sponsored by: Mellanox Technologies
show more ...
|
Revision tags: release/12.1.0 |
|
#
ef2e580e |
| 13-Oct-2019 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Don't cover in6_ifattach() with network epoch, as it may call into network drivers ioctls, that may sleep.
PR: 241223
|
#
8b3bc70a |
| 08-Oct-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r352764 through r353315.
|
#
b8a6e03f |
| 08-Oct-2019 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Widen NET_EPOCH coverage.
When epoch(9) was introduced to network stack, it was basically dropped in place of existing locking, which was mutexes and rwlocks. For the sake of performance mutex cover
Widen NET_EPOCH coverage.
When epoch(9) was introduced to network stack, it was basically dropped in place of existing locking, which was mutexes and rwlocks. For the sake of performance mutex covered areas were as small as possible, so became epoch covered areas.
However, epoch doesn't introduce any contention, it just delays memory reclaim. So, there is no point to minimise epoch covered areas in sense of performance. Meanwhile entering/exiting epoch also has non-zero CPU usage, so doing this less often is a win.
Not the least is also code maintainability. In the new paradigm we can assume that at any stage of processing a packet, we are inside network epoch. This makes coding both input and output path way easier.
On output path we already enter epoch quite early - in the ip_output(), in the ip6_output().
This patch does the same for the input path. All ISR processing, network related callouts, other ways of packet injection to the network stack shall be performed in net_epoch. Any leaf function that walks network configuration now asserts epoch.
Tricky part is configuration code paths - ioctls, sysctls. They also call into leaf functions, so some need to be changed.
This patch would introduce more epoch recursions (see EPOCH_TRACE) than we had before. They will be cleaned up separately, as several of them aren't trivial. Note, that unlike a lock recursion the epoch recursion is safe and just wastes a bit of resources.
Reviewed by: gallatin, hselasky, cy, adrian, kristof Differential Revision: https://reviews.freebsd.org/D19111
show more ...
|
Revision tags: release/11.3.0 |
|
#
7f49ce7a |
| 28-Jun-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @349476
Sponsored by: The FreeBSD Foundation
|
#
59854ecf |
| 25-Jun-2019 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Convert all IPv4 and IPv6 multicast memberships into using a STAILQ instead of a linear array.
The multicast memberships for the inpcb structure are protected by a non-sleepable lock, INP_WLOCK(), w
Convert all IPv4 and IPv6 multicast memberships into using a STAILQ instead of a linear array.
The multicast memberships for the inpcb structure are protected by a non-sleepable lock, INP_WLOCK(), which needs to be dropped when calling the underlying possibly sleeping if_ioctl() method. When using a linear array to keep track of multicast memberships, the computed memory location of the multicast filter may suddenly change, due to concurrent insertion or removal of elements in the linear array. This in turn leads to various invalid memory access issues and kernel panics.
To avoid this problem, put all multicast memberships on a STAILQ based list. Then the memory location of the IPv4 and IPv6 multicast filters become fixed during their lifetime and use after free and memory leak issues are easier to track, for example by: vmstat -m | grep multi
All list manipulation has been factored into inline functions including some macros, to easily allow for a future hash-list implementation, if needed.
This patch has been tested by pho@ .
Differential Revision: https://reviews.freebsd.org/D20080 Reviewed by: markj @ MFC after: 1 week Sponsored by: Mellanox Technologies
show more ...
|
#
7648bc9f |
| 13-May-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @347527
Sponsored by: The FreeBSD Foundation
|
#
c4cc6097 |
| 23-Apr-2019 |
Konstantin Belousov <kib@FreeBSD.org> |
poib: assign link-local address according to RFC
RFC 4391 specifies that the IB interface GID should be re-used as IPv6 link-local address. Since the code in in6_get_hw_ifid() ignored IFT_INFINIBAN
poib: assign link-local address according to RFC
RFC 4391 specifies that the IB interface GID should be re-used as IPv6 link-local address. Since the code in in6_get_hw_ifid() ignored IFT_INFINIBAND case, ibX interfaces ended up with the local address borrowed from some other interface, which is non-compliant.
Use lowest eight bytes from GID for filling the link-local address, same as Linux.
Reviewed by: bz (previous version), ae, hselasky, slavash, Sponsored by: Mellanox Technologies MFC after: 1 week Differential revision: https://reviews.freebsd.org/D20006
show more ...
|
#
9a696dc6 |
| 04-Apr-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead@r345880
|
#
ca1163bd |
| 30-Mar-2019 |
Mark Johnston <markj@FreeBSD.org> |
Do not perform DAD on stf(4) interfaces.
stf(4) interfaces are not multicast-capable so they can't perform DAD. They also did not set IFF_DRV_RUNNING when an address was assigned, so the logic in nd
Do not perform DAD on stf(4) interfaces.
stf(4) interfaces are not multicast-capable so they can't perform DAD. They also did not set IFF_DRV_RUNNING when an address was assigned, so the logic in nd6_timer() would periodically flag such an address as tentative, resulting in interface flapping.
Fix the problem by setting IFF_DRV_RUNNING when an address is assigned, and do some related cleanup: - In in6if_do_dad(), remove a redundant check for !UP || !RUNNING. There is only one caller in the tree, and it only looks at whether the return value is non-zero. - Have in6if_do_dad() return false if the interface is not multicast-capable. - Set ND6_IFF_NO_DAD when an address is assigned to an stf(4) interface and the interface goes UP as a result. Note that this is not sufficient to fix the problem because the new address is marked as tentative and DAD is started before in6_ifattach() is called. However, setting no_dad is formally correct. - Change nd6_timer() to not flag addresses as tentative if no_dad is set.
This is based on a patch from Viktor Dukhovni.
Reported by: Viktor Dukhovni <ietf-dane@dukhovni.org> Reviewed by: ae MFC after: 3 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D19751
show more ...
|
#
7e565c55 |
| 30-Jan-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r343320 through r343570.
|
#
2cd6ad76 |
| 24-Jan-2019 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Fix refcounting leaks in IPv6 MLD code leading to loss of IPv6 connectivity.
Looking at past changes in this area like r337866, some refcounting bugs have been introduced, one by one. For example li
Fix refcounting leaks in IPv6 MLD code leading to loss of IPv6 connectivity.
Looking at past changes in this area like r337866, some refcounting bugs have been introduced, one by one. For example like calling in6m_disconnect() and in6m_rele_locked() in mld_v1_process_group_timer() where previously no disconnect nor refcount decrement was done. Calling in6m_disconnect() when it shouldn't causes IPv6 solitation to no longer work, because all the multicast addresses receiving the solitation messages are now deleted from the network interface.
This patch reverts some recent changes while improving the MLD refcounting and concurrency model after the MLD code was converted to using EPOCH(9).
List changes: - All CK_STAILQ_FOREACH() macros are now properly enclosed into EPOCH(9) sections. This simplifies assertion of locking inside in6m_ifmultiaddr_get_inm(). - Corrected bad use of in6m_disconnect() leading to loss of IPv6 connectivity for MLD v1. - Factored out checks for valid inm structure into in6m_ifmultiaddr_get_inm().
PR: 233535 Differential Revision: https://reviews.freebsd.org/D18887 Reviewed by: bz (net) Tested by: ae MFC after: 1 week Sponsored by: Mellanox Technologies
show more ...
|
#
dea72f06 |
| 24-Jan-2019 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
When detaching a network interface drain the workqueue freeing the inm's because the destructor will access the if_ioctl() callback in the ifnet pointer which is about to be freed. This prevents use-
When detaching a network interface drain the workqueue freeing the inm's because the destructor will access the if_ioctl() callback in the ifnet pointer which is about to be freed. This prevents use-after-free.
PR: 233535 Differential Revision: https://reviews.freebsd.org/D18887 Reviewed by: bz (net) Tested by: ae MFC after: 1 week Sponsored by: Mellanox Technologies
show more ...
|
#
a68cc388 |
| 09-Jan-2019 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Mechanical cleanup of epoch(9) usage in network stack.
- Remove macros that covertly create epoch_tracker on thread stack. Such macros a quite unsafe, e.g. will produce a buggy code if same macro
Mechanical cleanup of epoch(9) usage in network stack.
- Remove macros that covertly create epoch_tracker on thread stack. Such macros a quite unsafe, e.g. will produce a buggy code if same macro is used in embedded scopes. Explicitly declare epoch_tracker always.
- Unmask interface list IFNET_RLOCK_NOSLEEP(), interface address list IF_ADDR_RLOCK() and interface AF specific data IF_AFDATA_RLOCK() read locking macros to what they actually are - the net_epoch. Keeping them as is is very misleading. They all are named FOO_RLOCK(), while they no longer have lock semantics. Now they allow recursion and what's more important they now no longer guarantee protection against their companion WLOCK macros. Note: INP_HASH_RLOCK() has same problems, but not touched by this commit.
This is non functional mechanical change. The only functionally changed functions are ni6_addrs() and ni6_store_addrs(), where we no longer enter epoch recursively.
Discussed with: jtl, gallatin
show more ...
|