| #
7b71f57f
|
| 03-Dec-2025 |
Warner Losh <imp@FreeBSD.org> |
netinet: Remove left-over sys/cdefs.h
These were for $FreeBSD$ that was removed a while ago, but these includes didn't get swept up in that. Remove them all now.
Sponsored by: Netflix MFC After:
netinet: Remove left-over sys/cdefs.h
These were for $FreeBSD$ that was removed a while ago, but these includes didn't get swept up in that. Remove them all now.
Sponsored by: Netflix MFC After: 2 weeks
show more ...
|
| #
28aafeb8
|
| 31-Oct-2024 |
John Baldwin <jhb@FreeBSD.org> |
netinet*: Add assertions for some places that don't support M_EXTPG mbufs
Found while auditing calls to M_WRITABLE to see if M_EXTPG could be removed from its checks.
Reviewed by: gallatin Differen
netinet*: Add assertions for some places that don't support M_EXTPG mbufs
Found while auditing calls to M_WRITABLE to see if M_EXTPG could be removed from its checks.
Reviewed by: gallatin Differential Revision: https://reviews.freebsd.org/D46785
show more ...
|
| #
685dc743
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
| #
662c1305
|
| 01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
net: clean up empty lines in .c and .h files
|
| #
6ad7446c
|
| 02-Jul-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Complete conversions from fib<4|6>_lookup_nh_<basic|ext> to fib<4|6>_lookup().
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and re
Complete conversions from fib<4|6>_lookup_nh_<basic|ext> to fib<4|6>_lookup().
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and requiring on-stack data copying.
With no callers remaining, remove fib[46]_lookup_nh_ functions.
Submitted by: Neel Chauhan <neel AT neelc DOT org> Differential Revision: https://reviews.freebsd.org/D25445
show more ...
|
| #
44e86fbd
|
| 13-Feb-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r357662 through r357854.
|
| #
481be5de
|
| 12-Feb-2020 |
Randall Stewart <rrs@FreeBSD.org> |
White space cleanup -- remove trailing tab's or spaces from any line.
Sponsored by: Netflix Inc.
|
| #
8b3bc70a
|
| 08-Oct-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r352764 through r353315.
|
| #
b8a6e03f
|
| 07-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 ...
|
| #
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 ...
|
| #
c6879c6c
|
| 23-Oct-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r339015 through r339669.
|
| #
7c328352
|
| 09-Oct-2018 |
Glen Barber <gjb@FreeBSD.org> |
MFH r338661 through r339253.
Sponsored by: The FreeBSD Foundation
|
| #
13c6ba6d
|
| 09-Oct-2018 |
Jonathan T. Looney <jtl@FreeBSD.org> |
There are three places where we return from a function which entered an epoch section without exiting that epoch section. This is bad for two reasons: the epoch section won't exit, and we will leave
There are three places where we return from a function which entered an epoch section without exiting that epoch section. This is bad for two reasons: the epoch section won't exit, and we will leave the epoch tracker from the stack on the epoch list.
Fix the epoch leak by making sure we exit epoch sections before returning.
Reviewed by: ae, gallatin, mmacy Approved by: re (gjb, kib) Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D17450
show more ...
|
| #
7b71f57f
|
| 03-Dec-2025 |
Warner Losh <imp@FreeBSD.org> |
netinet: Remove left-over sys/cdefs.h
These were for $FreeBSD$ that was removed a while ago, but these includes didn't get swept up in that. Remove them all now.
Sponsored by: Netflix MFC After:
netinet: Remove left-over sys/cdefs.h
These were for $FreeBSD$ that was removed a while ago, but these includes didn't get swept up in that. Remove them all now.
Sponsored by: Netflix MFC After: 2 weeks
show more ...
|
| #
28aafeb8
|
| 31-Oct-2024 |
John Baldwin <jhb@FreeBSD.org> |
netinet*: Add assertions for some places that don't support M_EXTPG mbufs
Found while auditing calls to M_WRITABLE to see if M_EXTPG could be removed from its checks.
Reviewed by: gallatin Differen
netinet*: Add assertions for some places that don't support M_EXTPG mbufs
Found while auditing calls to M_WRITABLE to see if M_EXTPG could be removed from its checks.
Reviewed by: gallatin Differential Revision: https://reviews.freebsd.org/D46785
show more ...
|
| #
685dc743
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
| #
662c1305
|
| 01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
net: clean up empty lines in .c and .h files
|
| #
6ad7446c
|
| 02-Jul-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Complete conversions from fib<4|6>_lookup_nh_<basic|ext> to fib<4|6>_lookup().
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and re
Complete conversions from fib<4|6>_lookup_nh_<basic|ext> to fib<4|6>_lookup().
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and requiring on-stack data copying.
With no callers remaining, remove fib[46]_lookup_nh_ functions.
Submitted by: Neel Chauhan <neel AT neelc DOT org> Differential Revision: https://reviews.freebsd.org/D25445
show more ...
|
| #
44e86fbd
|
| 13-Feb-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r357662 through r357854.
|
| #
481be5de
|
| 12-Feb-2020 |
Randall Stewart <rrs@FreeBSD.org> |
White space cleanup -- remove trailing tab's or spaces from any line.
Sponsored by: Netflix Inc.
|
| #
8b3bc70a
|
| 08-Oct-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r352764 through r353315.
|
| #
b8a6e03f
|
| 07-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 ...
|
| #
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 ...
|
| #
c6879c6c
|
| 23-Oct-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r339015 through r339669.
|
| #
7c328352
|
| 09-Oct-2018 |
Glen Barber <gjb@FreeBSD.org> |
MFH r338661 through r339253.
Sponsored by: The FreeBSD Foundation
|