> On 14 Jun 2022, at 15:47, Alexander Bluhm wrote:
>
> Hi,
>
> I made a little mistake when adding acquire refcount. The timeout
> does not decrement the counter to 0 properly.
>
> We have one reference count for the lists, and one for the timeout
> handler. When the timout fires, it has to
And use this mutex(9) to make the `session' dereference safe.
Hrvoje Popovski pointed me, he triggered netlock assertion with pipex(4)
pppoe sessions:
>
> r420-1# splassert: pipex_ppp_output: want 2 have 0
> Starting stack trace...
> pipex_ppp_output(fd80cb7c9500,800022761200,21) at
>
ote:
>
> On 20.6.2022. 16:46, Vitaliy Makkoveev wrote:
>> And use this mutex(9) to make the `session' dereference safe.
>>
>> Hrvoje Popovski pointed me, he triggered netlock assertion with pipex(4)
>> pppoe sessions:
>>
>
> Hi,
>
> I can trigger thi
pipex(4) doesn't rely on netlock anymore.
Index: sys/net/if_pppx.c
===
RCS file: /cvs/src/sys/net/if_pppx.c,v
retrieving revision 1.119
diff -u -p -r1.119 if_pppx.c
--- sys/net/if_pppx.c 15 Jul 2022 22:56:13 - 1.119
+++
We don't use "static" keyword for functions declaration to allow ddb(4)
debug. Also, many "Static" functions are called by pppx(4) layer outside
pipex(4) layer.
This is the mostly mechanic diff, except the `pipex_pppoe_padding' which
should be "static const".
Index: sys/net/pipex.c
Use per-session `pxs_mtx' mutex(9) to protect session context. Except
MPPE encryption, PPPOE sessions are mostly immutable, so no lock
required for that case.
Global pipex(4) data is already protected by `pipex_list_mtx', so
pipex(4) doesn't rely on netlock anymore. Netlock could be also removed
On Thu, Jul 14, 2022 at 01:46:14PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Protect all writers to ifm_cur with a mutex. ifmedia_match() does
> not return any pointers without lock anymore.
>
> ok?
I like to use fmedia_get() instead fmedia_match_get(). With this change
ok mvs@.
>
> bluhm
>
>
On Thu, Jul 14, 2022 at 02:44:16PM +0200, Alexander Bluhm wrote:
> On Thu, Jul 14, 2022 at 06:16:14AM +0300, Vitaliy Makkoveev wrote:
> > > On 14 Jul 2022, at 05:51, Visa Hankala wrote:
> > >
> > > On Thu, Jul 14, 2022 at 04:39:33AM +0300, Vitaliy Makkoveev wrote:
On Thu, Jul 14, 2022 at 04:33:27PM +0200, Jeremie Courreges-Anglas wrote:
> On Thu, Jul 14 2022, Vitaliy Makkoveev wrote:
>
> [...]
>
> > Also may be the problem lays in other layer, but triggered here...
>
> What is the syzkaller report that lead to this discussi
On Fri, Jul 15, 2022 at 02:25:41PM +0200, Alexander Bluhm wrote:
> On Fri, Jul 15, 2022 at 02:05:12PM +0300, Vitaliy Makkoveev wrote:
> > I see no reason to move 'not_ours' checks outside pipex_common_input()
> > because this introduce code duplication. Also I see no reason to t
On Thu, Jul 14, 2022 at 04:56:03PM +0200, Alexander Bluhm wrote:
> On Wed, Jul 13, 2022 at 12:49:53PM +0300, Vitaliy Makkoveev wrote:
> > Use per-session `pxs_mtx' mutex(9) to protect session context. Except
> > MPPE encryption, PPPOE sessions are mostly immutable, so no lo
It looks like sometimes the `unp_conn' doesn't reloaded in
the "unp->unp_conn != unp2" check, and READ_ONCE() should prevent this.
unp_solock_peer(struct socket *so)
{
struct unpcb *unp, *unp2;
struct socket *so2;
unp = so->so_pcb;
again:
if ((unp2 =
ok by me
> On 26 Jul 2022, at 19:11, Alexander Bluhm wrote:
>
> On Fri, Jul 22, 2022 at 06:13:04PM +0200, Alexander Bluhm wrote:
>> But I am fine with committing ifmedia, gem(4) and bge(4) now. Then
>> we can decide on a per driver basis. As long kernel lock is not
>> removed from the ifmedia
ok mvs@
> On 22 Jul 2022, at 22:43, Alexander Bluhm wrote:
>
> Hi,
>
> During regress testing I found this bug.
>
> splassert: rip6_input: want 1 have 2
> Starting stack trace...
> rip6_input(1,2,d0c6b7ad,f57ff9fc) at rip6_input+0x166
> rip6_input(f57ffbfc,f57ffbe8,3a,18) at rip6_input+0x166
ok mvs@
> On 23 Jul 2022, at 03:15, Alexander Bluhm wrote:
>
> Hi,
>
> The IPv6 reassembly code looks MP safe. So we can run it in parallel.
> Note that ip_ours() runs with shared netlock, while ip_local() has
> exclusive netlock after queuing.
>
> ok?
>
> bluhm
>
> Index:
> On 14 Jul 2022, at 05:51, Visa Hankala wrote:
>
> On Thu, Jul 14, 2022 at 04:39:33AM +0300, Vitaliy Makkoveev wrote:
>> It looks like sometimes the `unp_conn' doesn't reloaded in
>> the "unp->unp_conn != unp2" check, and READ_ONCE() should prevent thi
The updated diff. It was triggered by Hrvoje Popovski, we could do
direct (*if_qstart)() call in pipex(4) PPPOE input path, and this
provides deadlock. The updated diff uses ip{,6}_send() instead of
ipv{4,6}_input().
r420-1# witness: acquiring duplicate lock of same type: ">pxs_mtx"
1st >pxs_mtx
sbappendaddr() has no sleep points, so this should work. I have no
objections to commit this as quick and dirty fix. Otherwise the
network stack parallelisation diff should be reverted.
> On 6 May 2022, at 15:48, Alexander Bluhm wrote:
>
> On Thu, May 05, 2022 at 11:10:54PM +0200, Mark Kettenis
sys_umask() only modifies `fd_cmask', which modification is already
protected by `fd_lock' rwlock(9).
Index: sys/kern/syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.223
diff -u -p -r1.223
On Wed, May 11, 2022 at 09:49:34AM -0600, Theo de Raadt wrote:
> Alexander Bluhm wrote:
>
> > On Wed, May 11, 2022 at 11:20:15AM +0300, Vitaliy Makkoveev wrote:
> > > sys_umask() only modifies `fd_cmask', which modification is already
> > > protected by `fd_loc
On Wed, May 11, 2022 at 01:22:51PM -0600, Theo de Raadt wrote:
> Vitaliy Makkoveev wrote:
>
> > Index: sys/sys/filedesc.h
> > ===
> > RCS file: /cvs/src/sys/sys/filedesc.h,v
> > retrieving revis
On Wed, Jul 27, 2022 at 08:53:38PM +0200, Mark Kettenis wrote:
> > Date: Wed, 27 Jul 2022 00:11:19 +0200
> > From: Alexander Bluhm
> >
> > On Tue, Jul 26, 2022 at 11:19:27PM +0200, Mark Kettenis wrote:
> > > > Date: Tue, 26 Jul 2022 18:11:01 +0200
> > > > From: Alexander Bluhm
> > > >
> > > >
> Philip Guenther
>
>
>
> On Mon, Aug 22, 2022 at 1:40 PM Vitaliy Makkoveev wrote:
>
> > Another one.
> >
> > Since we never use `flags' arg within handlers, remove it from the
> > pru_rcvd() args.
> >
> > Index: sys/sys/protosw.h
> >
On Fri, Aug 26, 2022 at 05:27:08PM +0200, Claudio Jeker wrote:
> On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > grep and CVS agree that this is a switch(4) left-over.
> > >
> > > OK?
> >
> > This is exported to userland isn't
PRU_SENDOOB request always consumes passed `top' and `control' mbufs. We
don't want to have dummy m_freem(9) handlers for all protocols, so we
release passed mbufs in the pru_sendoob() EOPNOTSUPP error path.
Also we had the `control' mbuf(9) leak in the tcp(4) PRU_SENDOOB error
path, which was
The former PRU_SEND error path of gre_usrreq() had `control' mbuf(9)
leak. It was fixed in new gre_send().
The former pfkeyv2_send() was renamed to pfkeyv2_dosend().
Index: sys/kern/uipc_usrreq.c
===
RCS file:
Looks good by me.
> On 29 Aug 2022, at 14:15, Alexander Bluhm wrote:
>
> Anyone?
>
> On Sat, Aug 20, 2022 at 03:24:28PM +0200, Alexander Bluhm wrote:
>> Hi,
>>
>> Can we rename the the function in_pcbhashlookup() to in_pcblookup()?
>> Then we have in_pcblookup() and in_pcblookup_listen() as
> On 29 Aug 2022, at 20:34, Alexander Bluhm wrote:
>
> Hi,
>
> The diff below is needed to protect the receive socket buffer in
> UDP input with per PCB mutex.
>
> With that, parallel UDP input and soreceive can be activated. There
> are still issues with socket splicing and maybe pipex. So
ok?
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.170
diff -u -p -r1.170 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c 21 Aug 2022 17:30:21 - 1.170
+++
On Sun, Aug 21, 2022 at 07:19:23PM +0200, Alexander Bluhm wrote:
> Hi,
>
> When testing parallel UDP input, I see contention on the netlock
> from the protocol timer. There is a check to avoid loop traversal
> if igmp and mld6 are not active. Move the shortcut to avoid grabbing
> netlock. This
guenther@ said, that sys/protosw.h hunk on top of the diff makes it
easier to review. Is it really helpful?
ok?
Index: sys/sys/protosw.h
===
RCS file: /cvs/src/sys/sys/protosw.h,v
retrieving revision 1.40
diff -u -p -r1.40 protosw.h
Subj. Start the (*pru_usrreq)() split.
bluhm@ pointed, that many KASSERT()s are not welcomed, so I didn't
insert them into newly introduced handlers. Anyway except the tcp(4)
protocol, `so_pcb' cant be NULL here. But the socket lock assertion
looks reasonable.
Some unp_*() functions could be
On Mon, Aug 22, 2022 at 09:38:15AM +0200, Alexander Bluhm wrote:
> Hi,
>
> To run over all PCB, I have introduced temporary notify lists. They
> are necessary as the list of all PCB is protected by a mutex. Notify
> may call ip_output() eventually which may sleep as pf lock is a
> rwlock. Also
The former tcp_disconnect() was renamed to tcp_dodisconnect().
ok?
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.172
diff -u -p -r1.172 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c
On Mon, Aug 22, 2022 at 03:59:39PM +0200, Alexander Bluhm wrote:
> On Sun, Aug 21, 2022 at 10:10:53PM +0300, Vitaliy Makkoveev wrote:
> > On Sun, Aug 21, 2022 at 07:19:23PM +0200, Alexander Bluhm wrote:
> > > When testing parallel UDP input, I see contention on the netlock
>
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.173
diff -u -p -r1.173 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c 22 Aug 2022 13:23:06 - 1.173
+++ sys/kern/uipc_usrreq.c
On Mon, Aug 22, 2022 at 05:51:00PM +0300, Vitaliy Makkoveev wrote:
> On Mon, Aug 22, 2022 at 03:59:39PM +0200, Alexander Bluhm wrote:
> > On Sun, Aug 21, 2022 at 10:10:53PM +0300, Vitaliy Makkoveev wrote:
> > > On Sun, Aug 21, 2022 at 07:19:23PM +0200, Alexander Bluhm wrote:
&g
> On 22 Aug 2022, at 18:51, Alexander Bluhm wrote:
>
> On Mon, Aug 22, 2022 at 05:59:09PM +0300, Vitaliy Makkoveev wrote:
>> On Mon, Aug 22, 2022 at 05:51:00PM +0300, Vitaliy Makkoveev wrote:
>>> On Mon, Aug 22, 2022 at 03:59:39PM +0200, Alexander Bluhm wrote:
>>&g
On Sat, Aug 20, 2022 at 03:49:08PM +0200, Alexander Bluhm wrote:
> On Fri, Aug 19, 2022 at 04:28:24PM -0900, Philip Guenther wrote:
> > On Fri, Aug 19, 2022 at 12:42 PM Vitaliy Makkoveev wrote:
> >
> > > bluhm@ pointed, that many KASSERT()s are not welcomed, so I
On Thu, Sep 01, 2022 at 09:00:50PM +0200, Alexander Bluhm wrote:
> On Mon, Aug 15, 2022 at 05:12:22PM +0200, Alexander Bluhm wrote:
> > System calls should not fail due to temporary memory shortage in
> > malloc(9) or pool_get(9).
> >
> > Pass down a wait flag to pru_attach(). During syscall
On Thu, Sep 01, 2022 at 10:58:49PM +0300, Vitaliy Makkoveev wrote:
> On Thu, Sep 01, 2022 at 09:00:50PM +0200, Alexander Bluhm wrote:
> > On Mon, Aug 15, 2022 at 05:12:22PM +0200, Alexander Bluhm wrote:
> > > System calls should not fail due to temporary memory shortage
On Thu, Sep 01, 2022 at 05:59:44PM +0200, Alexander Bluhm wrote:
> On Thu, Sep 01, 2022 at 01:27:18AM +0300, Vitaliy Makkoveev wrote:
> > +int
> > +uipc_connect2(struct socket *so, struct socket *so2)
> > +{
> > + struct unpcb *unp = sotounpcb(so), *unp2 = sotoun
The 'proc *' is not used for PRU_CONTROL request, so remove it from
pru_control() wrapper.
I want to use existing in{6,}_control for tcp(4) and udp(4) sockets, so
for inet6 case I introduced `tcp6_usrreqs' and `udp6_usrreqs'
structures. I also want to use them for the following PRU_SOCKADDR and
On Fri, Sep 02, 2022 at 10:46:12PM +0200, Alexander Bluhm wrote:
> On Fri, Sep 02, 2022 at 06:01:20PM +0300, Vitaliy Makkoveev wrote:
> > We always call in6_setpeeraddr() and never call in_setpeeraddr() fro the
> > inet6 case.
>
> Should we do it the other way around?
>
On Fri, Sep 02, 2022 at 11:56:02AM +0200, Alexander Bluhm wrote:
> On Thu, Sep 01, 2022 at 11:04:19PM +0300, Vitaliy Makkoveev wrote:
> > On Thu, Sep 01, 2022 at 10:58:49PM +0300, Vitaliy Makkoveev wrote:
> > > On Thu, Sep 01, 2022 at 09:00:50PM +0200, Alexander Bluhm wrote:
>
On Fri, Sep 02, 2022 at 10:48:56PM +0200, Alexander Bluhm wrote:
> On Fri, Sep 02, 2022 at 05:56:33PM +0300, Vitaliy Makkoveev wrote:
> > Introduce in{,6}_sockaddr() and in{,6}_peeraddr() functions, and use
> > them for all except tcp(4) sockets. Use tcp_sockaddr() and
> > tcp
The last one.
As for the previous PRU_SOCKADDR, introduce in{,6}_peeraddr() and use it
for inet and inet sockets, except tcp(4).
Also remove *_usrreq() handlers. This makes diff bigger, but I guess we
don't want to commit code like below:
rip_usrreq(struct socket *so, int req, struct mbuf *m,
> On 4 Sep 2022, at 00:56, Alexander Bluhm wrote:
>
> On Sat, Sep 03, 2022 at 11:20:17PM +0200, Hrvoje Popovski wrote:
>> with this diff while booting I'm getting this witness trace
>
> It is not related to soreceive() diff, but TCP diff I commited
> before. I forgot a mutex initalization
> On 3 Sep 2022, at 23:47, Alexander Bluhm wrote:
>
> Hi,
>
> The next small step towards parallel network stack is to use shared
> netlock in soreceive(). The UDP and IP divert layer provide locking
> of the PCB. If that is possible, use shared instead of exclusive
> netlock in soreceive().
PRU_ABORT is another candidate to change return type to void. Also
actually we abort only the sockets which are linked to `so_q' or `so_q0'
queues of listening socket. Such sockets have no corresponding file
descriptor and are not accessed from userland, so PRU_ABORT used to
destroy them on
tcp(4) sockets are the only sockets which could have NULL `so_pcb' and
we handle this case within tcp_rcvd() handler.
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.285
diff -u -p
On Tue, Aug 30, 2022 at 03:41:29PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I looks like syzkaller has found a missing input validation in pipex.
>
> https://syzkaller.appspot.com/bug?id=c7ac769bd7ee15549b8a2be188bcee07d98a5357
>
> As I have no pipex setup, can anyone test this diff please?
>
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.181
diff -u -p -r1.181 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c 31 Aug 2022 21:23:02 - 1.181
+++ sys/kern/uipc_usrreq.c
On Mon, Aug 22, 2022 at 08:22:11PM +0200, Alexander Bluhm wrote:
> > +
> > +out:
> > + if (otp)
> > + tcp_trace(TA_USER, ostate, tp, otp, NULL, PRU_SHUTDOWN, 0);
> > return (0);
>
> This must be return (error).
>
Fixed, thanks!
Index: sys/kern/uipc_usrreq.c
Another one.
Since we never use `flags' arg within handlers, remove it from the
pru_rcvd() args.
Index: sys/sys/protosw.h
===
RCS file: /cvs/src/sys/sys/protosw.h,v
retrieving revision 1.43
diff -u -p -r1.43 protosw.h
---
On Mon, Aug 22, 2022 at 10:42:05PM +0200, Alexander Bluhm wrote:
> On Mon, Aug 22, 2022 at 08:14:05PM +0300, Vitaliy Makkoveev wrote:
> > May be I misunderstood something, but what is the reason to compiler to
> > drop this read? The value is not yet loaded, and we have no oth
> On 28 Aug 2022, at 20:48, Alexander Bluhm wrote:
>
> Hi,
>
> Since we have no raw_usrreq anymore, we can retire pr_output.
> pfkeyv2 and route can call ther output functions directly.
>
> ok?
>
ok mvs@
> bluhm
>
> Index: net/pfkeyv2.c
>
Another candidate for future refactoring. Except the tcp(4) and unix(4)
cases we do nothing with passed `ub', but in all cases we return no
error.
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.178
diff -u -p -r1.178 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c 28 Aug 2022 21:35:11 - 1.178
+++ sys/kern/uipc_usrreq.c
On Sun, Aug 28, 2022 at 10:42:11PM +0200, Alexander Bluhm wrote:
> On Sun, Aug 28, 2022 at 10:51:31PM +0300, Vitaliy Makkoveev wrote:
> > Another candidate for future refactoring. Except the tcp(4) and unix(4)
> > cases we do nothing with passed `ub', but in all cases we retu
ok mvs@
> On 21 Aug 2022, at 16:04, Alexander Bluhm wrote:
>
> Hi,
>
> After moving the IPv4 fragment reassembly and IPv6 hob-by-hob header
> chain processing out of ip_local() and ip6_local(), we can remove
> these almost empty stubs. No functional change intended.
>
> ok?
>
> bluhm
>
>
We never interesting soabort() return value.
I don't see any reason to change pru_abort() return type right now,
because it calls (*pru_usrreq)() within. I'll modify it with the
upcoming PRU_ABORT split.
Index: sys/kern/uipc_socket.c
> On 21 Aug 2022, at 00:31, Alexander Bluhm wrote:
>
> Hi,
>
> A inpcb mutex seems usable to serialize access to socket receive
> buffer. I have tried it for divert and udp input.
>
> As first step I would like to replace the kernel lock with a per
> PCB mutex in divert input.
>
> ok?
>
ok
ok?
Index: sys/kern/uipc_usrreq.c
===
RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.169
diff -u -p -r1.169 uipc_usrreq.c
--- sys/kern/uipc_usrreq.c 20 Aug 2022 23:48:57 - 1.169
+++
On Fri, Oct 21, 2022 at 10:28:04AM +, Klemens Nanni wrote:
> All interface ioctls always run with the kernel lock anyway, so this
> doesn't make a difference, except that it reflects how ifnetlist is not
> modified.
>
> OK?
>
netlock could be completely dropped here.
> diff --git
On Fri, Oct 21, 2022 at 12:14:16PM +, Klemens Nanni wrote:
> On Fri, Oct 21, 2022 at 03:02:33PM +0300, Vitaliy Makkoveev wrote:
> > netlock could be completely dropped here.
>
> We could probably drop the net lock around ifnetlist wherever the kernel
> lock is currently he
We have no interest on pru_abort() return value. Also we call it only
through soabort() which is dummy pru_abort() wrapper and has no return
value.
Also only the connection oriented sockets need to implement
(*pru_abort)() handler. Such sockets are tcp(4) and unix(4) sockets, so
we could remove
As it was done for udp and divert sockets.
Index: sys/netinet/ip_var.h
===
RCS file: /cvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.104
diff -u -p -r1.104 ip_var.h
--- sys/netinet/ip_var.h3 Sep 2022 22:43:38 -
We have no interest on pru_rcvd() return value. Also, we call pru_rcvd()
only if the socket's protocol have PR_WANTRCVD flag set. Such sockets
are route domain, tcp(4) and unix(4) sockets.
This diff keeps the PR_WANTRCVD check. In other hand we could always
call pru_rcvd() and do "pru_rcvd !=
ping
> On 17 Sep 2022, at 22:44, Vitaliy Makkoveev wrote:
>
> We have no interest on pru_abort() return value. Also we call it only
> through soabort() which is dummy pru_abort() wrapper and has no return
> value.
>
> Also only the connection oriented sockets need to im
Introduce in{,6}_sockaddr() and in{,6}_peeraddr() functions, and use
them for all except tcp(4) sockets. Use tcp_sockaddr() and
tcp_peeraddr() functions to keep debug ability.
The key management and route domain sockets returns EINVAL error for
PRU_SOCKADDR request, so keep this behaviour for a
We always call in6_setpeeraddr() and never call in_setpeeraddr() fro the
inet6 case.
Index: sys/netinet/in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.273
diff -u -p -r1.273 in_pcb.c
---
Also, I like to have exclusive layer locks like `tcp_lock’,
`udp_lock’, etc.. And take them with shared netlock held as the
first step of inet sockets unlocking.
> On 4 Aug 2022, at 02:13, Vitaliy Makkoveev wrote:
>
>> On 4 Aug 2022, at 01:36, Alexander Bluhm wrote:
>>
&g
> On 4 Aug 2022, at 01:36, Alexander Bluhm wrote:
>
> Hi,
>
> Divert packet has a strange design as it calls the protocol layer
> directly from pf. As pf runs in parallel, divert_packet() has a
> XXXSMP comment and kernel lock. This gives the opportunity to make
> experiments.
>
> I added a
> On 6 Aug 2022, at 01:07, Vitaliy Makkoveev wrote:
>
> I thought you will introduce something like below. This does the
> same but it has no heuristic under the hood.
>
> int
> sbwait_shared(struct socket *so, struct sockbuf *sb)
> {
>int error;
&
> On 5 Aug 2022, at 23:50, Alexander Bluhm wrote:
>
> On Thu, Aug 04, 2022 at 06:07:49PM +0300, Vitaliy Makkoveev wrote:
>> Yes please. Also I like (*pr_usrreq)() be splitted to multiple handlers.
>
> With all you feedback diff looks like this now.
>
Did you missed
> On 6 Aug 2022, at 00:36, Alexander Bluhm wrote:
>
> On Sat, Aug 06, 2022 at 12:20:48AM +0300, Vitaliy Makkoveev wrote:
>>> On 5 Aug 2022, at 23:50, Alexander Bluhm wrote:
>>>
>>> On Thu, Aug 04, 2022 at 06:07:49PM +0300, Vitaliy Makkoveev wrote:
>
> On 7 Aug 2022, at 23:18, Alexander Bluhm wrote:
>
> On Sun, Aug 07, 2022 at 03:53:27AM +0300, Vitaliy Makkoveev wrote:
>> Please note, the `so_pcb' can't be NULL. We nullify it only on dead
>> socket, which should not be passed to (*pr_userreq)(). The newly created
> On 14 Aug 2022, at 23:35, Jeremie Courreges-Anglas wrote:
>
> On Sun, Aug 14 2022, Vitaliy Makkoveev wrote:
>> I propose to avoid netlock relocking for SIOCGIFSFFPAGE too.
>
> sigh, that seems to be needed indeed.
>
>> Also, since the relock should be avoid
I propose to avoid netlock relocking for SIOCGIFSFFPAGE too.
Also, since the relock should be avoided for many commands, I prefer
to have something like below:
switch(cmd){
case SIOCGIFMEDIA:
case ...:
relock = 1;
break;
}
On Mon, Aug 15, 2022 at 11:47:03AM +0200, Alexander Bluhm wrote:
> On Sun, Aug 14, 2022 at 02:04:09AM +0300, Vitaliy Makkoveev wrote:
> > On Sat, Aug 13, 2022 at 09:08:36PM +0200, Alexander Bluhm wrote:
> > > Hi,
> > >
> > > While running forwarding i
Nothing special, just get assign `inp' and `tp' from passed socket. I
want to do this before (*pru_usrreq)() split to avoid huge code
duplication.
We have "tp might get 0 when using socket splicing" commentary. I
checked where we set `inp_ppcb' to NULL and found, tcp_close() is the
only place,
On Mon, Aug 15, 2022 at 04:28:28PM +0300, Vitaliy Makkoveev wrote:
> On Mon, Aug 15, 2022 at 04:20:57PM +0300, Vitaliy Makkoveev wrote:
> > On Mon, Aug 15, 2022 at 02:36:34PM +0200, Alexander Bluhm wrote:
> > > On Mon, Aug 15, 2022 at 02:29:02PM +0300, Vitaliy Makkoveev wrot
On Mon, Aug 15, 2022 at 04:20:57PM +0300, Vitaliy Makkoveev wrote:
> On Mon, Aug 15, 2022 at 02:36:34PM +0200, Alexander Bluhm wrote:
> > On Mon, Aug 15, 2022 at 02:29:02PM +0300, Vitaliy Makkoveev wrote:
> > > Nothing special, just get assign `inp' and `tp' from passed socket.
On Mon, Aug 15, 2022 at 02:36:34PM +0200, Alexander Bluhm wrote:
> On Mon, Aug 15, 2022 at 02:29:02PM +0300, Vitaliy Makkoveev wrote:
> > Nothing special, just get assign `inp' and `tp' from passed socket. I
> > want to do this before (*pru_usrreq)() split to avoid huge code
Subj.
Index: sys/net/if_pflow.c
===
RCS file: /cvs/src/sys/net/if_pflow.c,v
retrieving revision 1.94
diff -u -p -r1.94 if_pflow.c
--- sys/net/if_pflow.c 6 Jun 2022 14:45:41 - 1.94
+++ sys/net/if_pflow.c 12 Aug 2022
On Sat, Aug 13, 2022 at 09:28:46PM +0200, Alexander Bluhm wrote:
> On Sat, Aug 13, 2022 at 09:58:16PM +0300, Vitaliy Makkoveev wrote:
> > I propose to commit pru_*() hunks first.
>
> OK bluhm@
>
The pr_usrreqs hunks. I replaced spaces by tab within `routesw'
structure
On Sat, Aug 13, 2022 at 09:08:36PM +0200, Alexander Bluhm wrote:
> Hi,
>
> While running forwarding in parallel, I have introduced a hard
> barrier for parallel local protocol processing. The packets are
> requeued from shared to exclusive netlock.
>
> Unless we unlock all protocol input
On Sat, Aug 13, 2022 at 12:04:57PM +0200, Alexander Bluhm wrote:
> On Mon, Aug 08, 2022 at 03:48:57PM +0300, Vitaliy Makkoveev wrote:
> > We use if (error != 0) or if (m == NULL) idioms in the network stack, so
> > I used them too in the trivial places.
>
> I nearly got them
On Thu, Aug 04, 2022 at 01:42:48PM +0200, Alexander Bluhm wrote:
> On Thu, Aug 04, 2022 at 02:18:49AM +0300, Vitaliy Makkoveev wrote:
> > Also, I like to have exclusive layer locks like `tcp_lock???,
> > `udp_lock???, etc.. And take them with shared netlock held as the
> &g
On Thu, Aug 04, 2022 at 02:14:40PM +0200, Claudio Jeker wrote:
> On Thu, Aug 04, 2022 at 01:42:48PM +0200, Alexander Bluhm wrote:
> > On Thu, Aug 04, 2022 at 02:18:49AM +0300, Vitaliy Makkoveev wrote:
> > > Also, I like to have exclusive layer locks like `tcp_lock???,
>
I’m surprised by ISSET() macro.
ok mvs@
> On 4 Aug 2022, at 20:06, Alexander Bluhm wrote:
>
> On Thu, Jul 28, 2022 at 04:41:54PM +0200, Alexander Bluhm wrote:
>> -mff = (ip->ip_off & htons(IP_MF)) != 0;
>> +mff = ISSET(ip->ip_off, htons(IP_MF));
>
> This part breaks
> On 4 Aug 2022, at 18:05, Vitaliy Makkoveev wrote:
>
> On Thu, Aug 04, 2022 at 01:42:48PM +0200, Alexander Bluhm wrote:
>> On Thu, Aug 04, 2022 at 02:18:49AM +0300, Vitaliy Makkoveev wrote:
>>> Also, I like to have exclusive layer locks like `tcp_lock???,
>>
On Mon, Aug 08, 2022 at 12:47:07AM +0200, Alexander Bluhm wrote:
> On Mon, Aug 08, 2022 at 01:03:13AM +0300, Vitaliy Makkoveev wrote:
> > > I prefer the first idiom. If there is an error, do something. We
> > > should not change the style in opposite directio
On Tue, Aug 09, 2022 at 06:58:05PM +0200, Hrvoje Popovski wrote:
> Hi all,
>
> I've sysupgrade firewall from
> OpenBSD 7.2-beta (GENERIC.MP) #651: Tue Jul 26 23:11:26 MDT 2022
> to
> OpenBSD 7.2-beta (GENERIC.MP) #677: Mon Aug 8 18:58:49 MDT 2022
>
> and on console there was lot's of spalassert
The current (*pr_usrreq)() is not useful for sockets locking work. We
already have former PRU_ATTACH and PRU_DETACH splitted to the
(*pr_attach)() and (*pr_detach)() handlers. We don't want to add new
commands to (*pr_usrreq)() but introduce hew handlers to the 'protosw'
like (*pr_lock)() and
On Sat, Aug 06, 2022 at 12:19:45AM +0200, Alexander Bluhm wrote:
> On Sat, Aug 06, 2022 at 01:07:31AM +0300, Vitaliy Makkoveev wrote:
> > I thought you will introduce something like below. This does the
> > same but it has no heuristic under the hood.
> >
> > int
>
The latest diff iteration after guenther@'s feedback.
- The lock grabbing in ddb(4) is wrong, so don't grab it within
db_show_all_procs().
- In the dorefreshcreds() grab the lock only if uc != pr->ps_ucred. Also
move crfree() out of the lock.
- In the pgsigio() store call CANSIGIO() with
Thanks! ok mvs@
> On 31 Dec 2022, at 19:22, Scott Cheloha wrote:
>
> mvs@ is nudging me to realign the timeout.9 page with the state of the
> kernel.
>
> Here is my rewrite (again).
>
> There are some bits that I want to rework. The opening paragraph is
> especially clickety-clackety.
>
>
Since the interface is fully accessible after if_attach(),
if_counters_alloc() should be called before.
> +
> + if_attach(ifp);
> + if_alloc_sadl(ifp);
> + if_counters_alloc(ifp);
> +
On Mon, Jan 09, 2023 at 04:22:50PM +1000, David Gwynne wrote:
> this is basically pair(4) except at
501 - 600 of 774 matches
Mail list logo
