Re: pvbus: pass M_ZERO properly

2022-12-07 Thread Vitaliy Makkoveev
ok mvs@ > On 8 Dec 2022, at 05:35, YASUOKA Masahiko wrote: > > This is obvious. M_ZERO must be for 3rd argument. > > ok? > > Index: sys/dev/pv/pvbus.c > === > RCS file: /cvs/src/sys/dev/pv/pvbus.c,v > retrieving revision 1.25 >

Re: Unlock in6_ioctl_get() aka. SIOCGIF{DSTADDR,NETMASK,AFLAG,ALIFETIME}_IN6

2022-11-30 Thread Vitaliy Makkoveev
ok mvs@ > On 30 Nov 2022, at 20:50, Klemens Nanni wrote: > > First the right address is picked from the net lock protected if_addrlist. > Then all ioctls just copy out the address, nothing requires the kernel lock. > > SIOCGIFDSTADDR_IN6 checks the net lock protected if_flags, >

Re: Document 'uidinfo' structure locks

2022-12-07 Thread Vitaliy Makkoveev
> On 7 Dec 2022, at 18:10, Alexander Bluhm wrote: > > On Thu, Dec 01, 2022 at 09:50:47PM +0300, Vitaliy Makkoveev wrote: > > You could also document these globals with [I] in kern_proc.c > > LIST_HEAD(uihashhead, uidinfo) *uihashtbl; > u_long uihash; /

Move SS_CANTRCVMORE and SS_RCVATMARK to corresponding SBS_*

2022-12-11 Thread Vitaliy Makkoveev
This continues previous "Introduce `sb_state' and move SS_CANTSENDMORE..." diff. Move socket's SS_CANTRCVMORE and SS_RCVATMARK bits to socket's `so_rcv' buffer state bits. Moved separately of SS_CANTSENDMORE to make review and check easier. As with previous diff, left remaining SS_ bits as is.

Re: Move SS_CANTRCVMORE and SS_RCVATMARK to corresponding SBS_*

2022-12-11 Thread Vitaliy Makkoveev
On Sun, Dec 11, 2022 at 07:55:44PM -0700, Theo de Raadt wrote: > The problem you have introduced is that so_state is copied from sockets > to a sysctl record, where it also shows up as so_state. > > At least fstat(8) looks at this field, and uses the old SS_CANTSENDMORE > bit you have deleted.

Move solock() down to pru_connect2 handlers

2022-12-09 Thread Vitaliy Makkoveev
Only unix(4) sockets have pru_connect2() support. This movement makes soconnect2() just pru_connect2() wrapper and removes "persocket" logic from this path. Since the pru_*() request handlers are the separate functions, this doesn't introduce locking inconsistency to the pcb layer. Also, we

Re: Document 'uidinfo' structure locks

2022-12-06 Thread Vitaliy Makkoveev
ping > On 1 Dec 2022, at 21:50, Vitaliy Makkoveev wrote: > > Index: sys/sys/proc.h > === > RCS file: /cvs/src/sys/sys/proc.h,v > retrieving revision 1.335 > diff -u -p -r1.335 proc.h > --- sys/sys/proc.h

Re: Introduce per-sockbuf `sb_state' to use it with SS_CANTSENDMORE

2022-12-17 Thread Vitaliy Makkoveev
On Sat, Dec 17, 2022 at 11:42:14AM -0700, Theo de Raadt wrote: > Vitaliy Makkoveev wrote: > > > The reworked diff for `so_snd' SS_CANTSENDMORE state bit. As proposed by > > deraadt@, SS_CANTSENDMORE definition left as is, but used with newly > > introduced socket'

Introduce per-sockbuf `sb_state' to use it with SS_CANTSENDMORE

2022-12-17 Thread Vitaliy Makkoveev
Sorry for previous tree breakage. The reworked diff for `so_snd' SS_CANTSENDMORE state bit. As proposed by deraadt@, SS_CANTSENDMORE definition left as is, but used with newly introduced socket's buffer state `sb_state'. `sb_state' ored with original `so_state' when socket's data exported to the

Re: Introduce per-sockbuf `sb_state' to use it with SS_CANTSENDMORE

2022-12-17 Thread Vitaliy Makkoveev
On Sat, Dec 17, 2022 at 11:58:32AM -0700, Theo de Raadt wrote: > Sure something like that is also OK. > > So the previous breakage happened because you wanted a name change so > that bits-into-wrong variable would not happen, but you didn't realize the > namespace stretched into userland. > > So

Re: Use `ps_mtx' mutex(9) to protect `ps_ucred' and unlock setuid(2), ...

2022-12-17 Thread Vitaliy Makkoveev
On Sat, Dec 03, 2022 at 08:45:52PM +0300, Vitaliy Makkoveev wrote: > On Thu, Dec 01, 2022 at 10:50:03PM +0300, Vitaliy Makkoveev wrote: > > On Thu, Dec 01, 2022 at 11:28:59AM -0800, Philip Guenther wrote: > > > On Thu, Dec 1, 2022 at 10:31 AM Vitaliy Makko

Introduce SBL_WAIT and SLB_NOINTR sblock() flags

2022-12-21 Thread Vitaliy Makkoveev
The first one replaces malloc(9) related M_NOWAIT and M_WAITOK flags we use with sblock() to wait for lock if not immediately available. The second one proposed to use if the lock awaiting should be uninterruptible. It affects on sblock() behaviour for this call, instead of SB_NOINTR flag which

Re: Use `ps_mtx' mutex(9) to protect `ps_ucred' and unlock setuid(2), ...

2022-12-03 Thread Vitaliy Makkoveev
On Thu, Dec 01, 2022 at 10:50:03PM +0300, Vitaliy Makkoveev wrote: > On Thu, Dec 01, 2022 at 11:28:59AM -0800, Philip Guenther wrote: > > On Thu, Dec 1, 2022 at 10:31 AM Vitaliy Makkoveev wrote: > > ... > > > > > --- sys/sys/sysctl.h7 Nov 2022 14:25:44 -

Introduce `sb_state' and move SS_CANTSENDMORE to SBS_CANTSENDMORE

2022-12-09 Thread Vitaliy Makkoveev
This time, socket's buffer lock requires solock() to be held. I'm working on standalone socket's buffer locking, and I want to commit some bits. I mean SS_CANTSENDMORE and SS_CANTRCVMORE socket's state bits, which I want to turn into per buffer state. The diff below introduces per buffer

Re: nd6: Replace net lock with DAD specific adress list lock

2022-12-10 Thread Vitaliy Makkoveev
The netlock removal within nd6_dad_timer() is wrong. It protects `ifa’, `ia6’ and ip6 output path. > On 10 Dec 2022, at 15:16, Klemens Nanni wrote: > > nd6_nbr.c's static list of IPs to perform Duplicate Address Detection on > is protected by the too broad exclusive net lock. > > Switch

Don't bzero() dp->dad_timer_ch within nd6_dad_start()

2022-12-10 Thread Vitaliy Makkoveev
It's not required because `dp' was just allocated with M_ZERO flag. Index: sys/netinet6/nd6_nbr.c === RCS file: /cvs/src/sys/netinet6/nd6_nbr.c,v retrieving revision 1.138 diff -u -p -r1.138 nd6_nbr.c --- sys/netinet6/nd6_nbr.c

Re: Remove unused experimental ICMP6 redirect low water bits

2022-12-10 Thread Vitaliy Makkoveev
ok mvs@ > On 11 Dec 2022, at 01:46, Klemens Nanni wrote: > > Dead since introduction in 2001 with icmp6.c r1.31: >implement upper limit to icmp6 redirects (experimental, turned off) >negative value to {mtudisc,redirect}_{hi,lo}wat will turn off the > limitation. >sync with kame. >

Re: splassert on boot

2022-11-23 Thread Vitaliy Makkoveev
On Wed, Nov 23, 2022 at 02:59:05PM -0500, David Hill wrote: > Hello - > > I am seeing splasserts on boot (before kern.splassert=2 can be set) with > -current. > > > > spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800 SO-DIMM > isa0 at pcib0 > isadma0 at isa0 > vga0 at isa0 port 0x3b0/48

Re: Let nd6_if{at,de}tach() be void and take an ifp argument

2022-11-23 Thread Vitaliy Makkoveev
> On 24 Nov 2022, at 00:47, Claudio Jeker wrote: > > On Wed, Nov 23, 2022 at 02:54:08PM +, Klemens Nanni wrote: >> Do it like the rest of at/detach routines which modify a struct ifnet >> pointer without returning anything. >> >> OK? >> >> diff --git a/sys/net/if.c b/sys/net/if.c >> index

Re: Inline useless ND_IFINFO() macro

2022-11-23 Thread Vitaliy Makkoveev
On Wed, Nov 23, 2022 at 02:56:27PM +, Klemens Nanni wrote: > A single cast-free struct pointer dereference needs no indirection. > ND_IFINFO() is under _KERNEL. > > OK? > ok mvs@ > diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c > index 1924c36c813..d6ccfd3a272 100644 > ---

Re: Push kernel lock into in6_ioctl()

2022-11-23 Thread Vitaliy Makkoveev
On Wed, Nov 23, 2022 at 08:46:41AM +, Klemens Nanni wrote: > Mechanical move that "unlocks" the errno(2) cases. > > This is another step towards more read-only interface ioctls running > with the shared net lock alone. > > Feedback? OK? > Could this be merged with the following non

Re: Let nd6_if{at,de}tach() be void and take an ifp argument

2022-11-23 Thread Vitaliy Makkoveev
On Wed, Nov 23, 2022 at 02:54:08PM +, Klemens Nanni wrote: > Do it like the rest of at/detach routines which modify a struct ifnet > pointer without returning anything. > > OK? > ok mvs@ > diff --git a/sys/net/if.c b/sys/net/if.c > index c30d7e30e4f..3cb8bbf9176 100644 > --- a/sys/net/if.c

Re: Remove unused struct ifnet's *if_afdata[] and struct domain's dom_if{at,de}tach()

2022-11-23 Thread Vitaliy Makkoveev
On Wed, Nov 23, 2022 at 11:09:31AM +, Klemens Nanni wrote: > On Wed, Nov 23, 2022 at 11:04:55AM +, Klemens Nanni wrote: > > > I don't mind them to be two commits but please share both of them at the > > > same time. Because they should hit the tree at the same time. Changing > > > header

Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Vitaliy Makkoveev
On Tue, Nov 22, 2022 at 11:25:55AM +0100, Claudio Jeker wrote: > On Tue, Nov 22, 2022 at 09:25:08AM +, Stuart Henderson wrote: > > Need to query (and set $if, which might be used in route commands etc) I > > think. > > > > I would prefer if people took a step back from configuring

Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Vitaliy Makkoveev
On Thu, Nov 24, 2022 at 01:34:30PM +, Stuart Henderson wrote: > On 2022/11/24 14:36, Vitaliy Makkoveev wrote: > > On Wed, Nov 23, 2022 at 09:36:28PM -0700, Theo de Raadt wrote: > > > Theo de Raadt wrote: > > > > > > > > The other, that if both exist,

Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Vitaliy Makkoveev
On Wed, Nov 23, 2022 at 09:36:28PM -0700, Theo de Raadt wrote: > Theo de Raadt wrote: > > > > The other, that if both exist, > > > /etc/hostname.$if will override /etc/hostname.$lladdr. > > > > We do need to decide which one is priority, and document that. > > > > I am still unsure which is

Re: lladdr support for netstart/hostname.if

2022-11-22 Thread Vitaliy Makkoveev
On Tue, Nov 22, 2022 at 06:28:31AM -0700, Theo de Raadt wrote: > Vitaliy Makkoveev wrote: > > > On Tue, Nov 22, 2022 at 11:25:55AM +0100, Claudio Jeker wrote: > > > On Tue, Nov 22, 2022 at 09:25:08AM +, Stuart Henderson wrote: > > > > Need to query (and set

Re: lladdr support for netstart/hostname.if

2022-11-24 Thread Vitaliy Makkoveev
> On 24 Nov 2022, at 19:20, Theo de Raadt wrote: > >> I like to exclude pseudo devices. The pseudo device list is immutable, >> so we need to get only once during /etc/netstart. > > Why do we need to excluse them? > > The users will learn when to use this, and when not to. > So, I can't use

The next step of netlock removal from pppx(4)

2022-11-20 Thread Vitaliy Makkoveev
Kernel lock is always taken when we do access to `pxd_pxis' lists and `pppx_ifs' tree, so rely on it instead of netlock. The search in `pppx_ifs' tree has no context switch. We also have no context switch between the `pxi' free unit search and tree insertion. Use reference counters to make `pxi'

Re: Unlock getsockopt(2)

2022-11-29 Thread Vitaliy Makkoveev
On Mon, Nov 28, 2022 at 08:38:02PM +0300, Vitaliy Makkoveev wrote: > Subj. > > At sockets layer we touch only per-socket data, which is solock() > protected(). > > At protocol layer, unix(4) and key management sockets have no > (*pr_ctloutput)() handlers. route_ctloutp

Re: Unlock nd6_ioctl(), push kernel lock into in6_ioctl_get()

2022-11-29 Thread Vitaliy Makkoveev
: > > On Wed, Nov 23, 2022 at 03:39:54PM +0300, Vitaliy Makkoveev wrote: >> Could this be merged with the following non "Mechanical move" diff? > > Here's a rebased and cleaned up diff. > > Feedback? Objection? OK? > > --- > Neighbour Discovery informat

Re: Unlock nd6_ioctl(), push kernel lock into in6_ioctl_{get,change_ifaddr}()

2022-11-30 Thread Vitaliy Makkoveev
On Wed, Nov 30, 2022 at 12:24:32AM +, Klemens Nanni wrote: > On Wed, Nov 30, 2022 at 02:25:46AM +0300, Vitaliy Makkoveev wrote: > > I like to have current "error =" notation for both mrt6_ioctl() > > and in6_ioctl() within in6_control(). > > Alri

Unlock getsockopt(2)

2022-11-28 Thread Vitaliy Makkoveev
Subj. At sockets layer we touch only per-socket data, which is solock() protected(). At protocol layer, unix(4) and key management sockets have no (*pr_ctloutput)() handlers. route_ctloutput() touches only per socket data, which is solock() protected. inet{,6} globals are protected by netlock,

Re: nd6: Statically initialise DAD list, remove obsolete dad_init

2022-11-27 Thread Vitaliy Makkoveev
ok mvs@ > On 27 Nov 2022, at 23:29, Klemens Nanni wrote: > > On Sun, Nov 27, 2022 at 11:12:30PM +0300, Vitaliy Makkoveev wrote: >> dad_init should go away too. > > Thanks for pointing out the obvious. > --- > The list of IPv6 addresses to perfom Duplicate Address

Re: nd6: Clean up DAD initialisation

2022-11-27 Thread Vitaliy Makkoveev
dad_init should go away too. > On 27 Nov 2022, at 21:18, Klemens Nanni wrote: > > The list of IPv6 addresses to perfom Duplicate Address Detection on is > entirely static to nd6_nbr.c incl. its state vars with the exception of > ip6_dad_pending aka. the net.inet6.ip6.dad_pending sysctl(2). > >

Use `ps_mtx' mutex(9) to protect `ps_ucred' and unlock setuid(2), ...

2022-12-01 Thread Vitaliy Makkoveev
..., setgid(2), setgroups(2), setreuid(2), setregid(2), sys_setegid(2), sys_seteuid(2), setresuid(2), setresgid(2). These syscalls do the same: they overwrite `ps_ucred' by newly allocated credentials structure, so unlock them all. Unlocked chgproccnt() call is safe, because `uidinfolk'

Document 'uidinfo' structure locks

2022-12-01 Thread Vitaliy Makkoveev
Index: sys/sys/proc.h === RCS file: /cvs/src/sys/sys/proc.h,v retrieving revision 1.335 diff -u -p -r1.335 proc.h --- sys/sys/proc.h 23 Nov 2022 11:00:27 - 1.335 +++ sys/sys/proc.h 1 Dec 2022 18:48:47 - @@

Re: Use `ps_mtx' mutex(9) to protect `ps_ucred' and unlock setuid(2), ...

2022-12-01 Thread Vitaliy Makkoveev
On Thu, Dec 01, 2022 at 11:28:59AM -0800, Philip Guenther wrote: > On Thu, Dec 1, 2022 at 10:31 AM Vitaliy Makkoveev wrote: > ... > > > --- sys/sys/sysctl.h7 Nov 2022 14:25:44 - 1.231 > > +++ sys/sys/sysctl.h1 Dec 2022 18:15:06 - > > @@ -587,7 +58

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Vitaliy Makkoveev
On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote: > > On 19 Jan 2023, at 01:39, 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: > >

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Vitaliy Makkoveev
On Thu, Jan 19, 2023 at 10:40:52AM +0100, Jan Klemkow wrote: > On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote: > > On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote: > > > > On 19 Jan 2023, at 01:39, Jan Klemkow wrote: > > > > &

Re: refactor mbuf parsing on driver level

2023-01-17 Thread Vitaliy Makkoveev
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: > > Hi, > > > > we have several drivers which have to parse the content of mbufs. This > > diff suggest a central parsing function for

Re: refactor mbuf parsing on driver level

2023-01-17 Thread Vitaliy Makkoveev
On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote: > Hi, > > 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(4) because it was easy to

Re: refactor mbuf parsing on driver level

2023-01-19 Thread Vitaliy Makkoveev
> On 19 Jan 2023, at 23:17, Jan Klemkow wrote: > > On Thu, Jan 19, 2023 at 02:55:29PM +0300, Vitaliy Makkoveev wrote: >> On Thu, Jan 19, 2023 at 10:40:52AM +0100, Jan Klemkow wrote: >>> On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote: >>>>

Re: refactor mbuf parsing on driver level

2023-01-24 Thread Vitaliy Makkoveev
; > > 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

Move SS_ISSENDING flag to `sb_state'

2023-01-23 Thread Vitaliy Makkoveev
It should belong to send buffer as the SS_CANTSENDMORE flag. Index: sys/kern/uipc_socket.c === RCS file: /cvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.295 diff -u -p -r1.295 uipc_socket.c --- sys/kern/uipc_socket.c 22

Remove "sb == >so_rcv || sb == >so_snd" assertion from sb_notify() and sbspace()

2023-01-23 Thread Vitaliy Makkoveev
It's overkilling. Index: sys/sys/socketvar.h === RCS file: /cvs/src/sys/sys/socketvar.h,v retrieving revision 1.116 diff -u -p -r1.116 socketvar.h --- sys/sys/socketvar.h 22 Jan 2023 12:05:44 - 1.116 +++ sys/sys/socketvar.h

Re: refactor mbuf parsing on driver level

2023-01-24 Thread Vitaliy Makkoveev
> 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

Move SS_CANTRCVMORE and SS_RCVATMARK bits from `so_state' to `sb_state' of receive buffer

2023-01-21 Thread Vitaliy Makkoveev
As it was done for SS_CANTSENDMORE bit. The SS_CANTRCVMORE and SS_RCVATMARK definition kept as is, but now these bits belongs to the `sb_state' of receive buffer. `sb_state' ored with `so_state' when socket data exporting to the userland. Index: sys/kern/kern_sysctl.c

Replace selwakeup() with KNOTE(9) in pppx(4) and pppac(4) layers

2023-01-25 Thread Vitaliy Makkoveev
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:

Re: Replace selwakeup() with KNOTE(9) in pppx(4) and pppac(4) layers

2023-01-25 Thread Vitaliy Makkoveev
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". >

Re: refactor mbuf parsing on driver level

2023-01-26 Thread Vitaliy Makkoveev
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

Re: Replace selwakeup() with KNOTE(9) in pppx(4) and pppac(4) layers

2023-01-26 Thread Vitaliy Makkoveev
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 involved in

Replace selinfo structure by klist in sockbuf

2023-01-26 Thread Vitaliy Makkoveev
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

Push solock() down to sogetopt()

2023-01-27 Thread Vitaliy Makkoveev
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

Push solock() down to sosetopt()

2023-01-30 Thread Vitaliy Makkoveev
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

Re: Replace selwakeup() with KNOTE() in tun(4) and tap(4)

2023-01-30 Thread Vitaliy Makkoveev
> 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

Re: Do not call (*pr_ctloutput)() after success sosplice()

2023-01-30 Thread Vitaliy Makkoveev
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()

Re: npppd(8): remove "pipex" option

2023-01-31 Thread Vitaliy Makkoveev
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 &quo

Move duplicating initialization to soalloc()

2023-01-31 Thread Vitaliy Makkoveev
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

Remove pre netlock era rudiments from sosplice() and somove()

2023-01-27 Thread Vitaliy Makkoveev
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

Check SB_SPLICE flag within isspliced() and issplicedback() macros

2023-01-27 Thread Vitaliy Makkoveev
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)"

Do not call (*pr_ctloutput)() after success sosplice()

2023-01-28 Thread Vitaliy Makkoveev
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:

npppd(8): remove "pipex" option

2023-01-29 Thread Vitaliy Makkoveev
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

Re: Move SS_CANTRCVMORE and SS_RCVATMARK bits from `so_state' to `sb_state' of receive buffer

2023-01-22 Thread Vitaliy Makkoveev
On Sun, Jan 22, 2023 at 12:44:35AM +0100, Alexander Bluhm wrote: > > > @@ -1632,13 +1634,13 @@ somove(struct socket *so, int wait) > > pru_rcvd(so); > > > > /* Receive buffer did shrink by len bytes, adjust oob. */ > > - state = so->so_state; > > - so->so_state &=

ipsec(4): remove unused `ipsec_policy_head' all policies list

2023-01-20 Thread Vitaliy Makkoveev
We link all policies to this list, but don't use it for any purpose. Index: sys/net/pfkeyv2.c === RCS file: /cvs/src/sys/net/pfkeyv2.c,v retrieving revision 1.255 diff -u -p -r1.255 pfkeyv2.c --- sys/net/pfkeyv2.c 8 Jan 2023

Re: refactor mbuf parsing on driver level

2023-01-18 Thread Vitaliy Makkoveev
> On 19 Jan 2023, at 01:39, 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 mbufs. This >>&g

pflow(4): make `so' dereference safe

2022-11-04 Thread Vitaliy Makkoveev
Each pflow(4) interface has associated socket, referenced as sc->so. We set this socket in pflowioctl() which is called with both kernel and net locks held. In the pflow_output_process() task we do sc->so dereference, which is protected by kernel lock. But the sosend(), called deeper by

Split `uipc_dgram_usrreqs' out from `uipc_usrreqs'

2022-11-05 Thread Vitaliy Makkoveev
guenther@ proposed to split out handlers for SOCK_DGRAM unix(4) sockets from SOCK_STREAM and SOCK_SEQPACKET. The diff below introduces `uipc_dgram_usrreqs' to store pointers to dgram specific handlers. The dgram pru_shutdown and pru_send handlers were splitted to uipc_dgram_shutdown() and

Re: push kernel lock inside ifioctl_get()

2022-11-08 Thread Vitaliy Makkoveev
No reason to keep kernel lock around if_clone_list() call. > On 8 Nov 2022, at 20:27, Klemens Nanni wrote: > > On Tue, Nov 08, 2022 at 08:04:16PM +0300, Vitaliy Makkoveev wrote: >> The `if_cloners’ list is immutable. You don't need kernel lock >> around if_clone_list() c

Re: Document ifc_list immutability

2022-11-08 Thread Vitaliy Makkoveev
ok > On 8 Nov 2022, at 21:38, Klemens Nanni wrote: > > On Tue, Nov 08, 2022 at 09:34:36PM +0300, Vitaliy Makkoveev wrote: >>> On 8 Nov 2022, at 21:26, Klemens Nanni wrote: >>> >>> On Tue, Nov 08, 2022 at 09:18:47PM +0300, Vitaliy Makkoveev wrote: >>

Re: Document ifc_list immutability

2022-11-08 Thread Vitaliy Makkoveev
> On 8 Nov 2022, at 21:08, Klemens Nanni wrote: > > Now properly. How about a single comment block at the top instead of > repeating it for every struct? > > You forgot to mark [I] `if_cloners’ within net/if.c. > diff --git a/sys/net/if_var.h b/sys/net/if_var.h > index

Re: Document ifc_list immutability

2022-11-08 Thread Vitaliy Makkoveev
> On 8 Nov 2022, at 21:26, Klemens Nanni wrote: > > On Tue, Nov 08, 2022 at 09:18:47PM +0300, Vitaliy Makkoveev wrote: >>> On 8 Nov 2022, at 21:08, Klemens Nanni wrote: >>> >>> Now properly. How about a single comment block at the top instead

Re: push kernel lock inside ifioctl_get()

2022-11-08 Thread Vitaliy Makkoveev
The `if_cloners’ list is immutable. You don't need kernel lock around if_clone_list() call. > case SIOCIFGCLONERS: > + KERNEL_LOCK(); > error = if_clone_list((struct if_clonereq *)data); > + KERNEL_UNLOCK(); > return (error); With this

Re: pflow(4): make `so' dereference safe

2022-11-10 Thread Vitaliy Makkoveev
ping... On Fri, Nov 04, 2022 at 10:04:35PM +0300, Vitaliy Makkoveev wrote: > Each pflow(4) interface has associated socket, referenced as sc->so. We > set this socket in pflowioctl() which is called with both kernel and net > locks held. In the pflow_output_process() task we do sc->

Re: pppx(4): decrease netlock pressure in pppxioctl()

2022-11-09 Thread Vitaliy Makkoveev
ping... On Tue, Nov 01, 2022 at 03:16:02PM +0300, Vitaliy Makkoveev wrote: > Push netlock down to pppx_add_session(). The 'pppx_if' structure has > the `pxi_ready' member to prevent access to incomplete `pxi', so we > don't need to hold netlock during all initialisation process. This

Merge uipc_bind() with unp_bind()

2022-11-14 Thread Vitaliy Makkoveev
uipc_bind() only calls unp_bind(). Also it is the only caller of unp_bind(). Index: sys/kern/uipc_usrreq.c === RCS file: /cvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.192 diff -u -p -r1.192 uipc_usrreq.c ---

Turn sowriteable(), sballoc() and sbfree() macro to inline functions

2022-11-14 Thread Vitaliy Makkoveev
We have soreadable() already presented as inline function, but corresponding sowriteable() is still macro. Also it's no reason to keep sballoc() and sbfree() as macro. Index: sys/sys/protosw.h === RCS file:

Re: Merge uipc_bind() with unp_bind()

2022-11-14 Thread Vitaliy Makkoveev
On Mon, Nov 14, 2022 at 09:28:34AM +, Klemens Nanni wrote: > On Mon, Nov 14, 2022 at 12:11:46PM +0300, Vitaliy Makkoveev wrote: > > uipc_bind() only calls unp_bind(). Also it is the only caller of > > unp_bind(). > > For *_bind() alone this looks like zapping

Re: Turn sowriteable(), sballoc() and sbfree() macro to inline functions

2022-11-14 Thread Vitaliy Makkoveev
On Mon, Nov 14, 2022 at 12:00:28PM +, Klemens Nanni wrote: > On Mon, Nov 14, 2022 at 02:14:27PM +0300, Vitaliy Makkoveev wrote: > > We have soreadable() already presented as inline function, but > > corresponding sowriteable() is still macro. Also it's no reason to k

Re: Push kernel lock into pru_control()

2022-11-14 Thread Vitaliy Makkoveev
> On 10 Nov 2022, at 13:54, Klemens Nanni wrote: > > Purely mechanical, then in6_control() and in_control() can be pushed > further individually. > > Feedback? OK? SS_PRIV is immutable, no reason to check it with kernel lock held. > --- > sys/kern/sys_socket.c | 2 -- > sys/netinet/in.c |

pppx(4): decrease netlock pressure in pppxioctl()

2022-11-01 Thread Vitaliy Makkoveev
Push netlock down to pppx_add_session(). The 'pppx_if' structure has the `pxi_ready' member to prevent access to incomplete `pxi', so we don't need to hold netlock during all initialisation process. This removes potential PR_WAITOK/M_WAITOK allocations impact on packet processing. Also this

Re: Move duplicating initialization to soalloc()

2023-01-31 Thread Vitaliy Makkoveev
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's buf

Re: Replace selwakeup() with KNOTE() in tun(4) and tap(4)

2023-01-31 Thread Vitaliy Makkoveev
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). > >

Re: npppd(8): remove "pipex" option

2023-02-01 Thread Vitaliy Makkoveev
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

Re: knote(9) and knote_locked(9)

2023-02-02 Thread Vitaliy Makkoveev
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)

Re: panic: ffs_valloc: dup alloc

2023-03-17 Thread Vitaliy Makkoveev
> 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.

Re: syslogd udp remote logging eacces

2023-03-16 Thread Vitaliy Makkoveev
> 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

Re: arp: initialise global list

2023-03-02 Thread Vitaliy Makkoveev
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 >

Re: Push solock() down to sosetopt()

2023-02-16 Thread Vitaliy Makkoveev
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 ca

if_detach(): move rtm_ifannounce(IFAN_DEPARTURE) outside netlock

2023-02-16 Thread Vitaliy Makkoveev
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

Re: Push solock() down to sosetopt()

2023-02-16 Thread Vitaliy Makkoveev
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

Re: Push solock() down to sosetopt()

2023-02-17 Thread Vitaliy Makkoveev
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 ca

Re: Call sysctl_ifnames() with shared netlock

2023-04-17 Thread Vitaliy Makkoveev
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

Re: Call sysctl_source() with shared netlock

2023-04-17 Thread Vitaliy Makkoveev
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_

Re: Call sysctl_source() with shared netlock

2023-04-20 Thread Vitaliy Makkoveev
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/

Re: Remove kernel lock from ifa_ifwithaddr()

2023-04-18 Thread Vitaliy Makkoveev
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@ > > >

Re: Call sysctl_source() with shared netlock

2023-04-18 Thread Vitaliy Makkoveev
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

Introduce `rtlabel_mtx' mutex(9) ...

2023-04-24 Thread Vitaliy Makkoveev
... 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

Push kernel lock deep down to sys_sysctl()

2023-04-21 Thread Vitaliy Makkoveev
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

Remove kernel lock from rtfree(9)

2023-04-26 Thread Vitaliy Makkoveev
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

<    2   3   4   5   6   7   8   >