; > > Jan Klemkow wrote:
> > > > > On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote:
> > > > > > On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote:
> > > > > > > we have several drivers which have to parse the content of m
> On 24 Jan 2023, at 19:21, Jan Klemkow wrote:
>
> On Tue, Jan 24, 2023 at 05:40:55PM +0300, Vitaliy Makkoveev wrote:
>> On Tue, Jan 24, 2023 at 03:14:36PM +0100, Jan Klemkow wrote:
>>> On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote:
>>>> On M
visa@, mpi@, I'm asking you to review, because you are involved in the
kevent(9) development.
Hrvoje, if you want to test this diff, you need to disable pipex(4) with
"net.pipex.enable=0".
Index: sys/net/if_pppx.c
===
RCS file: /cvs/
On Wed, Jan 25, 2023 at 10:43:50PM +0300, Vitaliy Makkoveev wrote:
> visa@, mpi@, I'm asking you to review, because you are involved in the
> kevent(9) development.
>
> Hrvoje, if you want to test this diff, you need to disable pipex(4) with
> "net.pipex.enable=0"
On Thu, Jan 26, 2023 at 11:37:51AM +0100, Christian Weisgerber wrote:
> Jan Klemkow:
>
> > we have several drivers which have to parse the content of mbufs. This
> > diff suggest a central parsing function for this. Thus, we can reduce
> > redundant code.
> >
> > I just start with ix(4) and ixl
On Thu, Jan 26, 2023 at 03:28:07PM +, Visa Hankala wrote:
> On Thu, Jan 26, 2023 at 01:57:56AM +0300, Vitaliy Makkoveev wrote:
> > On Wed, Jan 25, 2023 at 10:43:50PM +0300, Vitaliy Makkoveev wrote:
> > > visa@, mpi@, I'm asking you to review, because you are involve
No reason to keep it, selinfo is just wrapper to klist. netstat(1) and
libkvm use socket structure, but don't touch
so_{snd,rcv}.sb_sel.si_note.
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving
It is not required for the most cases. Also, some cases could be
protected with solock_shared().
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.297
diff -u -p -r1.297 uipc_socket.c
Since these paths became netlock serialized, we don't need to handle
side effects caused by context switch.
somove() return type changed to the type of void because we can't have
concurrent somove() while we sleep. SB_SPLICE bits we set before
somove() call will be cleared within somove() if splic
While doing isspliced() and issplicedback() we need to perform two
checks of so_sp pointer and so_sp->ssp_socket or so_sp->ssp_soback
pointers. But we always set SB_SPLICE flag on sockets buffer flags
together with ssp_socket and ssp_soback. Therefore the conditions
"so_rcv.sb_flags & SB_SPLICE)" a
It will be null op in any cases. I want to do this, because it allows
to push solock() down to sosplice() and make future sblock()/solock()
dances easier with standalone sblock().
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/s
Hi,
While switchind pppx(4) and pppac(4) from selwakeup() to KNOTE(9), I
found npppd(8) doesn't create pppx interface with "pipex no" in
npppd.conf, but successfully connects the client. So packets don't flow.
However, the pppac(4) has no this problem, because corresponding pppac
interface always
It makes sense to push solock() down to sosetopt() too. For a half cases
(*pr_ctloutput)() is just null op, so there is no reason to call it.
Also, a lot of things could be done without solock() held.
Index: sys/kern/uipc_socket.c
===
Guess, the "Push solock() down to sosetopt()" diff is better.
On Sat, Jan 28, 2023 at 02:08:36PM +0300, Vitaliy Makkoveev wrote:
> It will be null op in any cases. I want to do this, because it allows
> to push solock() down to sosplice() and make future sblock()/solock()
>
> On 30 Jan 2023, at 06:39, Visa Hankala wrote:
>
> Replace selwakeup() with KNOTE() in tun(4) and tap(4).
>
> This patch makes the tun(4) and tap(4) event filters MP-safe.
>
> This is similar to the change that just got committed to pppac(4)
> and pppx(4). However, tun(4) and tap(4) can be des
On Tue, Jan 31, 2023 at 01:40:19PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> On Sun, 29 Jan 2023 14:35:05 +0300
> Vitaliy Makkoveev wrote:
> > While switchind pppx(4) and pppac(4) from selwakeup() to KNOTE(9), I
> > found npppd(8) doesn't create pppx interface with
Since we have soalloc() to do common socket initialization, move the
rest within. I mostly need to do this because standalone socket's buffer
locking require to introduce another klistops data for buffers and there
is no reason to add more copypaste to sonewconn().
Also this makes `socket_klistops
On Tue, Jan 31, 2023 at 06:00:45PM +, Visa Hankala wrote:
> On Tue, Jan 31, 2023 at 12:44:47PM +0300, Vitaliy Makkoveev wrote:
> > Since we have soalloc() to do common socket initialization, move the
> > rest within. I mostly need to do this because standalone socket'
On Tue, Jan 31, 2023 at 06:21:01PM +, Visa Hankala wrote:
> On Mon, Jan 30, 2023 at 08:34:29PM +0300, Vitaliy Makkoveev wrote:
> > > On 30 Jan 2023, at 06:39, Visa Hankala wrote:
> > >
> > > Replace selwakeup() with KNOTE() in tun(4) and tap(4).
> > >
> On 30 Jan 2023, at 06:39, Visa Hankala wrote:
>
> Replace selwakeup() with KNOTE() in tun(4) and tap(4).
>
> This patch makes the tun(4) and tap(4) event filters MP-safe.
>
> This is similar to the change that just got committed to pppac(4)
> and pppx(4). However, tun(4) and tap(4) can be des
On Wed, Feb 01, 2023 at 09:00:13PM +0900, YASUOKA Masahiko wrote:
> Hi
>
> ...
>
> But I think we should keep the part since it is needed when adding a
> tunneling protocol which is not supported by pipex, or running npppd
> on another OS.
>
> >> If having "pipex yes/no" configuration is mislead
On Thu, Feb 02, 2023 at 04:44:11AM +, Visa Hankala wrote:
> Make knote(9) lock the knote list internally, and add knote_locked(9)
> for the typical situation where the list is already locked.
>
> Simplify the kqueue API a bit (and make room for the new function)
> by dropping the KNOTE(9) macr
On Thu, Feb 02, 2023 at 12:52:14PM +0100, Claudio Jeker wrote:
> In vlan_transmit the IFCAP_VLAN_HWTAGGING cases uses
> sc->sc_tag + (prio << EVL_PRIO_BITS)
> while the non IFCAP_VLAN_HWTAGGING cases uses
> sc->sc_tag | (prio << EVL_PRIO_BITS)
>
> Lets use the same logic in both cases. IMO using
Hi,
kevent(2) system call is ulocked more than year ago. Since select(2)
and pselect(2) are kqueue(2)/kevent(2) wrappers, it makes sense to
unlock them too. select(2) does the temporary kernel event queue
initialization for this call only and does queue scan with events
conversion between kevent(2
On Mon, Feb 06, 2023 at 11:01:00AM +0100, Claudio Jeker wrote:
> On Sat, Feb 04, 2023 at 01:24:58AM +0300, Vitaliy Makkoveev wrote:
> > Hi,
> >
> > kevent(2) system call is ulocked more than year ago. Since select(2)
> > and pselect(2) are kqueue(2)/kevent(2)
On Tue, Feb 07, 2023 at 02:29:13PM +0100, Claudio Jeker wrote:
> > I could be wrong, but membar_exit_before_atomic(9) between `p_sigmask'
> > assignment and atomic P_SIGSUSPEND flag setting should be enough for
> > that:
> >
> > p->p_oldmask = p->p_sigmask;
> > p->p_sigmask = newmask;
> >
On Tue, Feb 07, 2023 at 04:06:39PM +0100, Mark Kettenis wrote:
> > Date: Tue, 7 Feb 2023 14:29:13 +0100
> > From: Claudio Jeker
> >
> > On Mon, Feb 06, 2023 at 08:28:38PM +0300, Vitaliy Makkoveev wrote:
> > > On Mon, Feb 06, 2023 at 11:01:00AM +0100, Claudio Je
On Tue, Feb 07, 2023 at 05:42:40PM +0300, Vitaliy Makkoveev wrote:
>
> > > Otherwise, if you are concerning about serialized `p_sigmask' and
> > > P_SIGSUSPEND, dosigsuspend() should be left under kernel lock:
> > >
> > >
> On 10 Feb 2023, at 17:53, Visa Hankala wrote:
>
> This makes log event filter MP-safe.
>
> OK?
>
ok mvs@
> Index: kern/subr_log.c
> ===
> RCS file: src/sys/kern/subr_log.c,v
> retrieving revision 1.75
> diff -u -p -r1.75 subr_l
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2021
diff -u -p -r1.2021 pcidevs
--- sys/dev/pci/pcidevs 7 Feb 2023 07:10:43 - 1.2021
+++ sys/dev/pci/pcidevs 11 Feb 2023 19:15:38
On Wed, Feb 08, 2023 at 12:47:23PM +0100, Claudio Jeker wrote:
> On Wed, Feb 08, 2023 at 12:40:50PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 8 Feb 2023 14:17:14 +0300
> > > From: Vitaliy Makkoveev
> > >
> > > On Tue, Feb 07, 2023 at 05
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2021
diff -u -p -r1.2021 pcidevs
--- sys/dev/pci/pcidevs 7 Feb 2023 07:10:43 - 1.2021
+++ sys/dev/pci/pcidevs 13 Feb 2023 10:06:56
On Mon, Feb 13, 2023 at 11:22:36AM +0100, Mark Kettenis wrote:
> > Date: Mon, 13 Feb 2023 13:08:54 +0300
> > From: Vitaliy Makkoveev
>
> What makes you think this is a PEX 8311? The data sheet I found has
> the PCI device ID down as 0x8311, althogh this can be changed
r RDK kit. Meanwhile
according "PEX8311AA Data Book" the default PID is 0x9056 as they used
for PLX 9056 PCI bridge. Since PEX 8311 is mostly bit to bit identical
to PLX 9056 this smells like true.
However, want to drop this diff. Sorry for noise.
> On Mon, Feb 13, 2023 at 01:08:54
On Wed, Feb 15, 2023 at 08:08:42PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 30, 2023 at 05:03:30PM +0300, Vitaliy Makkoveev wrote:
> > It makes sense to push solock() down to sosetopt() too. For a half cases
> > (*pr_ctloutput)() is just null op, so there is no reason to call
On Thu, Feb 16, 2023 at 01:19:07PM +0300, Vitaliy Makkoveev wrote:
>
> Sorry for big non obvious diff. I need this refactoring to keep required
> lock order between solock() and the standalone sblock().
>
The standalone sblock() could be non obvious for this moment. I want to
to
This is the mbuf(9) allocation and broadcast transmission for PF_ROUTE
sockets, netlock is not required here. Make sense for systems with many
short time living pseudo interfaces like tun(4) and pppx(4).
The corresponding IFAN_ARRIVAL announce could be also done without
netlock held, but I like t
On Wed, Feb 15, 2023 at 08:08:42PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 30, 2023 at 05:03:30PM +0300, Vitaliy Makkoveev wrote:
> > It makes sense to push solock() down to sosetopt() too. For a half cases
> > (*pr_ctloutput)() is just null op, so there is no reason to call
On Thu, Mar 02, 2023 at 09:36:52AM +, Klemens Nanni wrote:
> Used but not initialised:
>
> $ grep arp_list if_ether.c
> LIST_ENTRY(llinfo_arp) la_list; /* [mN] global arp_list
> */
> LIST_HEAD(, llinfo_arp) arp_list; /* [mN] list of all llinfo_arp
> structur
> On 16 Mar 2023, at 20:52, Alexander Bluhm wrote:
>
> Hi,
>
> When syslogd is sending messages per UDP, it stops if there is a
> permanent error. It has a list of transient errors.
>
> Since OpenBSD 6.5 pf has changed its error code to EACCES. If pf
> blocks your outgoing syslog packets and
> On 17 Mar 2023, at 22:53, Moritz Buhl wrote:
>
> Any better names?
> "ffs-node-lock"
> "ffsndlock"
ffsnodelk or ffsndlck if the length shouldn’t exceed 8.
On Mon, Apr 03, 2023 at 02:12:45PM +0200, Alexander Bluhm wrote:
> Hi,
>
> The arp mbuf queue la_mq has its own mutex, la_hold_total uses
> atomic operations. So they don't need the global arp mutex.
>
> Pull them out of arp_mtx blocks to make clear what the scope of
> arp_mtx protection is.
>
It performs read-only access to netlock protected data.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
--- sys/net/rtsock.c22 Jan 2023 12:05:44 - 1.
As sysctl_ifnames(), it performs read-only access to netlock protected
data.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
--- sys/net/rtsock.c22 Jan 2023 1
Also performs read-only access to netlock protected data.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
--- sys/net/rtsock.c22 Jan 2023 12:05:44 -
It seems rt_setsource() needs some attention, but sysctl_source() could
be called with shared netlock just now.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
--
We use netlock to protect `if_list' and `ifa_list' lists, and the `ifa'
dereference, so kernel lock within ifa_ifwithaddr() is wrong. We have no
problems, because we call ifadel()/ifafree() with kernel lock held, but
we should not rely on this.
So use netlock assertion within ifa_ifwithaddr() inst
On Mon, Apr 17, 2023 at 02:58:59PM +0200, Alexander Bluhm wrote:
> On Mon, Apr 17, 2023 at 01:20:28AM +0300, Vitaliy Makkoveev wrote:
> > It performs read-only access to netlock protected data.
>
> OK bluhm@
>
> Could you somewhere document that ifnetlist is protected by ne
On Mon, Apr 17, 2023 at 04:32:13PM +0200, Alexander Bluhm wrote:
> On Mon, Apr 17, 2023 at 02:36:57AM +0300, Vitaliy Makkoveev wrote:
> > It seems rt_setsource() needs some attention, but sysctl_source() could
> > be called with shared netlock just now.
>
> I think rtable_
On Tue, Apr 18, 2023 at 03:36:09PM +0200, Alexander Bluhm wrote:
> On Mon, Apr 17, 2023 at 05:53:28PM +0200, Alexander Bluhm wrote:
> > On Mon, Apr 17, 2023 at 04:32:13PM +0200, Alexander Bluhm wrote:
> > > On Mon, Apr 17, 2023 at 02:36:57AM +0300, Vitaliy Makkoveev wrote
On Tue, Apr 18, 2023 at 03:15:54PM +0200, Alexander Bluhm wrote:
> On Mon, Apr 17, 2023 at 03:16:36AM +0300, Vitaliy Makkoveev wrote:
> > Index: sys/dev/usb/if_umb.c
> This umb chunk is OK bluhm@
>
> >
Index: sys/net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.416
diff -u -p -r1.416 route.c
--- sys/net/route.c 28 Jan 2023 10:17:16 - 1.416
+++ sys/net/route.c 19 Apr 2023 14:00:31 -
@@ -5
Forgot to say, rt_timer_remove_all() and ifafree() could be moved out of
kernel lock too, but with next diff.
On Wed, Apr 19, 2023 at 05:03:00PM +0300, Vitaliy Makkoveev wrote:
> Index: sys/net/route.c
> ===
> RCS file: /cv
Now rtable_*source() are polished, so we could push this diff to tree.
ok?
On Mon, Apr 17, 2023 at 02:36:57AM +0300, Vitaliy Makkoveev wrote:
> It seems rt_setsource() needs some attention, but sysctl_source() could
> be called with shared netlock just now.
>
> Index: sys/
It does read-olny access to tetlock protected data, so the radix tree
will not be modified during spd_table_walk() run.
The second spd_table_walk() call in PF_KEY layer can't be performed with
shared netlock, because pfkeyv2_policy_flush() modifies tree and the
following tdb_walk() requires exclus
At least network subset of sysctl(8) MIBs relies on netlock or another
locks and doesn't require kernel lock. Also some integers in other
subsets can be read without kernel lock held.
Diff below actually pushes kernel lock down to net_sysctl(). It is
required for MPLS and PFLOW cases. The protocol
... and use it to protect route labels storage. This time it is not
clean, which lock protects it because we holding kernel and net locks in
various combinations while accessing it. I see no reason to put kernel
lock to all the places. Also netlock could not be used, because rtfree()
which calls rt
On Tue, Apr 25, 2023 at 11:44:34AM +0200, Alexander Bluhm wrote:
> Hi,
>
> Mutex arp_mtx protects the llinfo_arp la_... fields. So kernel
> lock is only needed for changing the route rt_flags.
>
> Of course there is a race between checking and setting rt_flags.
> But the other checks of the RTF
> On 26 Apr 2023, at 15:30, Hrvoje Popovski wrote:
>
> On 26.4.2023. 12:15, Alexander Bluhm wrote:
>> On Wed, Apr 26, 2023 at 11:17:32AM +0200, Alexander Bluhm wrote:
>>> On Tue, Apr 25, 2023 at 11:57:09PM +0300, Vitaliy Makkoveev wrote:
>>>> On Tue, Apr 25,
Route timers and route labels protected by corresponding mutexes. `ifa'
uses references counting for protection. No protection required for `rt'
passed to rt_mpls_clear() because only current thread owns it.
ok?
Index: sys/net/route.c
==
Index: sys/net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.418
diff -u -p -r1.418 route.c
--- sys/net/route.c 26 Apr 2023 16:09:44 - 1.418
+++ sys/net/route.c 26 Apr 2023 23:00:02 -
@@ -1
Now only direct netlock used for inet sockets protection. The unlocked
access to all other sockets is safe, but we could lost consistency for a
little. Since the solock() used for sockets protection, make locking
path common and use it. Make it shared because this is read-only access
to sockets dat
> On 27 Apr 2023, at 15:16, Alexander Bluhm wrote:
>
> On Wed, Apr 26, 2023 at 11:17:37PM +0300, Vitaliy Makkoveev wrote:
>> Route timers and route labels protected by corresponding mutexes. `ifa'
>> uses references counting for protection. No protection requ
> On 27 Apr 2023, at 15:40, Alexander Bluhm wrote:
>
> On Thu, Apr 27, 2023 at 03:22:10PM +0300, Vitaliy Makkoveev wrote:
>>> On 27 Apr 2023, at 15:16, Alexander Bluhm wrote:
>>>
>>> On Wed, Apr 26, 2023 at 11:17:37PM +0300, Vitaliy Makkoveev wrote
On Thu, Apr 27, 2023 at 02:54:38PM +0200, Claudio Jeker wrote:
> On Thu, Apr 27, 2023 at 01:55:33PM +0300, Vitaliy Makkoveev wrote:
> > Now only direct netlock used for inet sockets protection. The unlocked
> > access to all other sockets is safe, but we could lost consistency f
n
this cpu could happen on any other. IPL_MPFLOOR has very high level and
I guess it was chosen mostly for insurance.
We do rt allocation and release in the sockets, ioctl and softnet
context, so I see no reason to disable interrupts with priority greater
than IPL_SOFTNET.
>
> On Thu, Apr 27, 2
On Fri, Apr 28, 2023 at 02:13:15PM +0200, Alexander Bluhm wrote:
> After running stress test successfully with this diff, next day
> machine crashed while compiling a new kernel. It is unclear whether
> it is related to the diff. The softdep in ps is problably processing
> make output via ssh. L
> On 28 Apr 2023, at 15:57, Vitaliy Makkoveev wrote:
>
> On Fri, Apr 28, 2023 at 02:13:15PM +0200, Alexander Bluhm wrote:
>> After running stress test successfully with this diff, next day
>> machine crashed while compiling a new kernel. It is unclear whether
>>
> On 28 Apr 2023, at 15:38, Alexander Bluhm wrote:
>
> On Fri, Apr 28, 2023 at 02:51:23PM +0300, Vitaliy Makkoveev wrote:
>>> On 28 Apr 2023, at 14:03, Alexander Bluhm wrote:
>>>
>>> That basically means we must never call one of the pool get or put
>>
Ping.
> On 21 Apr 2023, at 17:17, Vitaliy Makkoveev wrote:
>
> At least network subset of sysctl(8) MIBs relies on netlock or another
> locks and doesn't require kernel lock. Also some integers in other
> subsets can be read without kernel lock held.
>
> Diff below a
> On 12 May 2023, at 03:34, David Gwynne wrote:
>
> so in top you see softnet0, softnet1, etc.
>
> the real change is putting a struct softnet in place to wrap the name
> and taskq up with.
>
> ok?
Makes sense. ok mvs
>
> Index: if.c
>
> On 12 May 2023, at 15:07, Alexander Bluhm wrote:
>
> On Fri, May 12, 2023 at 11:43:42AM +, Klemens Nanni wrote:
>>> Access rt_llinfo and check for NULL without checking RTF_LLINFO
>>> flag before. They are changed togehter with the arp or nd6 mutex.
>>
>> It is the same change, but I'd co
Let's start to unlock (*pr_sysctl)() handlers. We have many of them, so
introduce temporary PR_MPSAFE flag to mark MP safe instead of pushing
kernel lock within handlers.
Unlock ip_sysctl(). Still take kernel lock within IPCTL_MRTSTATS case.
It looks like `mrtstat' protection is inconsistent, so k
On Thu, Apr 27, 2023 at 02:54:38PM +0200, Claudio Jeker wrote:
> On Thu, Apr 27, 2023 at 01:55:33PM +0300, Vitaliy Makkoveev wrote:
> > Now only direct netlock used for inet sockets protection. The unlocked
> > access to all other sockets is safe, but we could lost consistency f
> On 16 May 2023, at 18:35, Alexander Bluhm wrote:
>
> I saw one issue in sysctl_niq(). Another CPU could write mq_maxlen
> and our logic is inconsistent. Below is a fix with read once. Each
> CPU detects its own change, last write wins. Or should we protect
> everything with mq_mtx? Then sy
On Tue, May 16, 2023 at 08:26:37PM +0300, Vitaliy Makkoveev wrote:
> > On 16 May 2023, at 18:35, Alexander Bluhm wrote:
> >
> > I saw one issue in sysctl_niq(). Another CPU could write mq_maxlen
> > and our logic is inconsistent. Below is a fix with read once. Each
Introduce `ip6_soiikey_lock' rwlock(9) to protect `ip6_soiikey'. It
accessed only by ip6_sysctl_soiikey() and ip6_sysctl() is the only
ip6_sysctl_soiikey() caller so context switch is allowed here. Also
remove unused `oldkey' from ip6_sysctl_soiikey().
For IPV6CTL_MRTSTATS, IPV6CTL_MRTMIF and IPV6
mrt_rtwalk_mfcsysctl() performs read-only access to protected data, so
rtable_walk() could be called with shared netlock.
Index: sys/netinet/ip_input.c
===
RCS file: /cvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.384
diff -u
Also read-only access to netlock protected data.
Index: sys/netinet/ip_input.c
===
RCS file: /cvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.384
diff -u -p -r1.384 ip_input.c
--- sys/netinet/ip_input.c 16 May 2023 19:36:0
> On 18 May 2023, at 01:14, Alexander Bluhm wrote:
>
> On Wed, May 17, 2023 at 12:46:02PM +0300, Vitaliy Makkoveev wrote:
>> Introduce `ip6_soiikey_lock' rwlock(9) to protect `ip6_soiikey'. It
>> accessed only by ip6_sysctl_soiikey() and ip6_sysctl() is the only
&g
701 - 780 of 780 matches
Mail list logo
