#
3e92559d |
| 04-Nov-2022 |
ozaki-r <ozaki-r@NetBSD.org> |
inpcb: get rid of parentheses for return value
|
#
60402b44 |
| 04-Nov-2022 |
ozaki-r <ozaki-r@NetBSD.org> |
inpcb: use in_port_t for port numbers
|
#
da7deee6 |
| 04-Nov-2022 |
ozaki-r <ozaki-r@NetBSD.org> |
inpcb: rename functions to in6pcb_*
|
#
aea30c9a |
| 04-Nov-2022 |
ozaki-r <ozaki-r@NetBSD.org> |
inpcb: rename functions to inpcb_*
Inspired by rmind-smpnet patches.
|
#
a094f1a1 |
| 28-Oct-2022 |
ozaki-r <ozaki-r@NetBSD.org> |
inpcb: separate inpcb again to reduce the size of PCB for IPv4
The data size of PCB for IPv4 increased because of the merge of struct in6pcb. The change decreases the size to the original size by s
inpcb: separate inpcb again to reduce the size of PCB for IPv4
The data size of PCB for IPv4 increased because of the merge of struct in6pcb. The change decreases the size to the original size by separating struct inpcb (again). struct in4pcb and in6pcb that embed struct inpcb are introduced.
Even after the separation, users don't need to realize the separation and only have to use some macros to access dedicated data. For example, inp->inp_laddr is now accessed through in4p_laddr(inp).
show more ...
|
#
140683a5 |
| 28-Oct-2022 |
ozaki-r <ozaki-r@NetBSD.org> |
inpcb: integrate data structures of PCB into one
Data structures of network protocol control blocks (PCBs), i.e., struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of the data struc
inpcb: integrate data structures of PCB into one
Data structures of network protocol control blocks (PCBs), i.e., struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of the data structures have to handle them separately and thus the code is cluttered and duplicated.
The commit integrates the data structures into one, struct inpcb. As a result, users of PCBs only have to handle just one data structure, so the code becomes simple.
One drawback is that the data size of PCB for IPv4 increases by 40 bytes (from 248 bytes to 288 bytes).
show more ...
|
#
e289043c |
| 14-Oct-2022 |
ryo <ryo@NetBSD.org> |
Avoid error of "-Wreturn-local-addr", and simplify the logic.
However, -Wreturn-local-addr is still disabled by default by GCC_NO_RETURN_LOCAL_ADDR in bsd.own.mk because it causes errors in other pa
Avoid error of "-Wreturn-local-addr", and simplify the logic.
However, -Wreturn-local-addr is still disabled by default by GCC_NO_RETURN_LOCAL_ADDR in bsd.own.mk because it causes errors in other parts.
show more ...
|
#
33eb59ba |
| 29-Aug-2022 |
knakahara <knakahara@NetBSD.org> |
Add sysctl entry to control to send routing message for RTM_DYNAMIC.
Some routing daemons require such routing message to keep coherency.
If we want to let kernel send such message, set net.inet.ic
Add sysctl entry to control to send routing message for RTM_DYNAMIC.
Some routing daemons require such routing message to keep coherency.
If we want to let kernel send such message, set net.inet.icmp.dynamic_rt_msg=1 for IPv4, net.inet6.icmp6.dynamic_rt_msg=1 for IPv6. Default(=0) is the same as before, that is, not send such routing message.
show more ...
|
#
6c871d4b |
| 29-Jul-2022 |
knakahara <knakahara@NetBSD.org> |
Remove obsoleted comments.
These comments are added with IFNET_LOCK by in_pcb.c:r1.180 and in6_pcb.c:r1.162. And then, IFNET_LOCK codes are removed in in_pcb.c:r1.183 and in6_pcb.c:r1.166, however
Remove obsoleted comments.
These comments are added with IFNET_LOCK by in_pcb.c:r1.180 and in6_pcb.c:r1.162. And then, IFNET_LOCK codes are removed in in_pcb.c:r1.183 and in6_pcb.c:r1.166, however the comments have remained.
show more ...
|
#
b44b83da |
| 09-Jun-2022 |
knakahara <knakahara@NetBSD.org> |
refactor: use TAILQ_FOREACH instead of TAILQ_FOREACH_SAFE about inpt_queue.
They don't use "ninph" pointer and don't remove elements.
|
#
9c0c35ee |
| 08-Sep-2020 |
christos <christos@NetBSD.org> |
Add IP_BINDANY, IPV6_BINDANY which can be used to bind to any address in order to implement transparent proxies.
|
#
f880630b |
| 15-May-2019 |
ozaki-r <ozaki-r@NetBSD.org> |
Get rid of IFNET_LOCK for if_mcast_op to avoid a deadlock
The IFNET_LOCK was added to avoid data races on if_flags for IFF_ALLMULTI. Unfortunatetly it caused a deadlock instead. A known scenario ca
Get rid of IFNET_LOCK for if_mcast_op to avoid a deadlock
The IFNET_LOCK was added to avoid data races on if_flags for IFF_ALLMULTI. Unfortunatetly it caused a deadlock instead. A known scenario causing a deadlock is to occur the following two operations concurrently: (a) a removal of an IP adddres assigned to an interface and (b) a manipulation of multicast groups to the interface. The resource dependency graph is like this: softnet_lock => IFNET_LOCK => psref_target_destroy => softint => softnet_lock
Thanks to the previous commit that avoids data races on if_flags for IFF_ALLMULTI by another approach, we can remove IFNET_LOCK and defuse the deadlock.
PR kern/54189
show more ...
|
#
89dca4df |
| 27-Feb-2018 |
maxv <maxv@NetBSD.org> |
Dedup: merge
ipsec4_get_policy and ipsec6_get_policy ipsec4_delete_pcbpolicy and ipsec6_delete_pcbpolicy
The already-existing ipsec_get_policy() function is inlined in the new one.
|
#
80b252d6 |
| 08-Feb-2018 |
dholland <dholland@NetBSD.org> |
Typos.
|
#
5858b418 |
| 22-Dec-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Add missing curlwp_bindx
|
#
794413c0 |
| 15-Dec-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Ensure to call if_mcast_op with holding IFNET_LOCK
Note that CARP doesn't deal with IFNET_LOCK yet.
|
#
694c1025 |
| 25-Apr-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Check if solock of PCB is held when SP caches in the PCB are accessed
To this end, a back pointer from inpcbpolicy to inpcb_hdr is added.
|
#
76a1281d |
| 20-Apr-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Simplify logic of udp4_sendup and udp6_sendup
They are always passed a socket with the same protocol faimiliy as its own: AF_INET for udp4_sendup and AF_INET6 for udp6_sendup.
|
#
2e45373f |
| 02-Mar-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Make sure im6o_memberships is protected by in6p's lock (solock)
|
#
c15dcb73 |
| 02-Mar-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Use LIST_* macros
No functional change.
|
#
5f5c6574 |
| 13-Feb-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Replace splnet with splsoftnet
|
#
a59f72f9 |
| 23-Jan-2017 |
ozaki-r <ozaki-r@NetBSD.org> |
Get rid of splnet for pool(9)
We don't need it anymore.
|
#
17257ad0 |
| 13-Dec-2016 |
ozaki-r <ozaki-r@NetBSD.org> |
Remove unnecessary inclusions of nd6.h
|
#
683bfd37 |
| 12-Dec-2016 |
ozaki-r <ozaki-r@NetBSD.org> |
Make the routing table and rtcaches MP-safe
See the following descriptions for details.
Proposed on tech-kern and tech-net
Overview --------
We protect the routing table with a rwock and protect
Make the routing table and rtcaches MP-safe
See the following descriptions for details.
Proposed on tech-kern and tech-net
Overview --------
We protect the routing table with a rwock and protect rtcaches with another rwlock. Each rtentry is protected from being freed or updated via reference counting and psref.
Global rwlocks --------------
There are two rwlocks; one for the routing table (rt_lock) and the other for rtcaches (rtcache_lock). rtcache_lock covers all existing rtcaches; there may have room for optimizations (future work).
The locking order is rtcache_lock first and rt_lock is next.
rtentry references ------------------
References to an rtentry is managed with reference counting and psref. Either of the two mechanisms is used depending on where a rtentry is obtained. Reference counting is used when we obtain a rtentry from the routing table directly via rtalloc1 and rtrequest{,1} while psref is used when we obtain a rtentry from a rtcache via rtcache_* APIs. In both cases, a caller can sleep/block with holding an obtained rtentry.
The reasons why we use two different mechanisms are (i) only using reference counting hurts the performance due to atomic instructions (rtcache case) (ii) ease of implementation; applying psref to APIs such rtaloc1 and rtrequest{,1} requires additional works (adding a local variable and an argument).
We will finally migrate to use only psref but we can do it when we have a lockless routing table alternative.
Reference counting for rtentry ------------------------------
rt_refcnt now doesn't count permanent references such as for rt_timers and rtcaches, instead it is used only for temporal references when obtaining a rtentry via rtalloc1 and rtrequest{,1}. We can do so because destroying a rtentry always involves removing references of rt_timers and rtcaches to the rtentry and we don't need to track such references. This also makes it easy to wait for readers to release references on deleting or updating a rtentry, i.e., we can simply wait until the reference counter is 0 or 1. (If there are permanent references the counter can be arbitrary.)
rt_ref increments a reference counter of a rtentry and rt_unref decrements it. rt_ref is called inside APIs (rtalloc1 and rtrequest{,1} so users don't need to care about it while users must call rt_unref to an obtained rtentry after using it.
rtfree is removed and we use rt_unref and rt_free instead. rt_unref now just decrements the counter of a given rtentry and rt_free just tries to destroy a given rtentry.
See the next section for destructions of rtentries by rt_free.
Destructions of rtentries -------------------------
We destroy a rtentry only when we call rtrequst{,1}(RTM_DELETE); the original implementation can destroy in any rtfree where it's the last reference. If we use reference counting or psref, it's easy to understand if the place that a rtentry is destroyed is fixed.
rt_free waits for references to a given rtentry to be released before actually destroying the rtentry. rt_free uses a condition variable (cv_wait) (and psref_target_destroy for psref) to wait.
Unfortunately rtrequst{,1}(RTM_DELETE) can be called in softint that we cannot use cv_wait. In that case, we have to defer the destruction to a workqueue.
rtentry#rt_cv, rtentry#rt_psref and global variables (see rt_free_global) are added to conduct the procedure.
Updates of rtentries --------------------
One difficulty to use refcnt/psref instead of rwlock for rtentry is updates of rtentries. We need an additional mechanism to prevent readers from seeing inconsistency of a rtentry being updated.
We introduce RTF_UPDATING flag to rtentries that are updating. While the flag is set to a rtentry, users cannot acquire the rtentry. By doing so, we avoid users to see inconsistent rtentries.
There are two options when a user tries to acquire a rtentry with the RTF_UPDATING flag; if a user runs in softint context the user fails to acquire a rtentry (NULL is returned). Otherwise a user waits until the update completes by waiting on cv.
The procedure of a updater is simpler to destruction of a rtentry. Wait on cv (and psref) and after all readers left, proceed with the update.
Global variables (see rt_update_global) are added to conduct the procedure.
Currently we apply the mechanism to only RTM_CHANGE in rtsock.c. We would have to apply other codes. See "Known issues" section.
psref for rtentry -----------------
When we obtain a rtentry from a rtcache via rtcache_* APIs, psref is used to reference to the rtentry.
rtcache_ref acquires a reference to a rtentry with psref and rtcache_unref releases the reference after using it. rtcache_ref is called inside rtcache_* APIs and users don't need to take care of it while users must call rtcache_unref to release the reference.
struct psref and int bound that is needed for psref is embedded into struct route. By doing so we don't need to add local variables and additional argument to APIs.
However this adds another constraint to psref other than reference counting one's; holding a reference of an rtentry via a rtcache is allowed by just one caller at the same time. So we must not acquire a rtentry via a rtcache twice and avoid a recursive use of a rtcache. And also a rtcache must be arranged to be used by a LWP/softint at the same time somehow. For IP forwarding case, we have per-CPU rtcaches used in softint so the constraint is guaranteed. For a h rtcache of a PCB case, the constraint is guaranteed by the solock of each PCB. Any other cases (pf, ipf, stf and ipsec) are currently guaranteed by only the existence of the global locks (softnet_lock and/or KERNEL_LOCK). If we've found the cases that we cannot guarantee the constraint, we would need to introduce other rtcache APIs that use simple reference counting.
psref of rtcache is created with IPL_SOFTNET and so rtcache shouldn't used at an IPL higher than IPL_SOFTNET.
Note that rtcache_free is used to invalidate a given rtcache. We don't need another care by my change; just keep them as they are.
Performance impact ------------------
When NET_MPSAFE is disabled the performance drop is 3% while when it's enabled the drop is increased to 11%. The difference comes from that currently we don't take any global locks and don't use psref if NET_MPSAFE is disabled.
We can optimize the performance of the case of NET_MPSAFE on by reducing lookups of rtcache that uses psref; currently we do two lookups but we should be able to trim one of two. This is a future work.
Known issues ------------
There are two known issues to be solved; one is that a caller of rtrequest(RTM_ADD) may change rtentry (see rtinit). We need to prevent new references during the update. Or we may be able to remove the code (perhaps, need more investigations).
The other is rtredirect that updates a rtentry. We need to apply our update mechanism, however it's not easy because rtredirect is called in softint and we cannot apply our mechanism simply. One solution is to defer rtredirect to a workqueue but it requires some code restructuring.
show more ...
|
#
9de8a52b |
| 08-Dec-2016 |
ozaki-r <ozaki-r@NetBSD.org> |
Add rtcache_unref to release points of rtentry stemming from rtcache
In the MP-safe world, a rtentry stemming from a rtcache can be freed at any points. So we need to protect rtentries somehow say b
Add rtcache_unref to release points of rtentry stemming from rtcache
In the MP-safe world, a rtentry stemming from a rtcache can be freed at any points. So we need to protect rtentries somehow say by reference couting or passive references. Regardless of the method, we need to call some release function of a rtentry after using it.
The change adds a new function rtcache_unref to release a rtentry. At this point, this function does nothing because for now we don't add a reference to a rtentry when we get one from a rtcache. We will add something useful in a further commit.
This change is a part of changes for MP-safe routing table. It is separated to avoid one big change that makes difficult to debug by bisecting.
show more ...
|