Re: uvm: __inline -> inline

2020-09-22 Thread Vitaliy Makkoveev
ok mvs > On 22 Sep 2020, at 10:15, Martin Pieuchot wrote: > > Spell inline correctly, also reduce the diff with NetBSD for uvm_amap.c > and uvm_fault.c. > > ok? > > Index: uvm/uvm_addr.c > === > RCS file:

Re: pppoe: move softc list out of NET_LOCK() into new pppoe lock

2020-09-13 Thread Vitaliy Makkoveev
Hello Klemens. pppoe(4) input path and pppoe(4) config path (I mean clone/destroy) is always different context. Your diff introduces the new lock which protects `pppoe_softc_list’ list but what should protect `sc’ you got from this list after you released `pppoe_lock’? I mean this dereference is

Re: incorrect result from getppid for ptraced processes

2020-09-05 Thread Vitaliy Makkoveev
> On 5 Sep 2020, at 03:22, Philip Guenther wrote: > > On Fri, Sep 4, 2020 at 2:59 PM Mateusz Guzik wrote: > >> On 9/5/20, Philip Guenther wrote: >>> On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote: >>> >>>> On 9/4/20, Vitaliy Makkoveev

Re: incorrect result from getppid for ptraced processes

2020-09-04 Thread Vitaliy Makkoveev
On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: > getppid blindly follows the parent pointer and reads the pid. > > The problem is that ptrace reparents the traced process, so in > particular if you gdb -p $something, the target proc will start seeing > gdb instead of its actual

pipex(4)/ppp{ac,x}(4): don't include "net/netisr.h"

2020-08-28 Thread Vitaliy Makkoveev
It's not needed here. Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.102 diff -u -p -r1.102 if_pppx.c --- sys/net/if_pppx.c 27 Aug 2020 10:47:52 - 1.102 +++ sys/net/if_pppx.c 28

pppx(4)/pipex(4): use per cpu counters with ifnet

2020-08-28 Thread Vitaliy Makkoveev
pppac(4) uses per cpu counters for collect `ifnet' statistics, but in pipex(4) layer this `ifnet' still uses `if_data'. Also pppx(4) doesn't use per cpu counters but `if_data'. I propose to use per cpu counters for pppx(4) and pipex(4) to avoid interface statistics collecting mix. Also this will

Re: Make pipex more common for pppac and pppx

2020-08-24 Thread Vitaliy Makkoveev
On Thu, Aug 20, 2020 at 02:32:57PM +0900, YASUOKA Masahiko wrote: Hello. I pointed some comments inline. > Hi, > > Thank you for your comments. > > On Mon, 17 Aug 2020 00:15:08 +0300 > Vitaliy Makkoveev wrote: > > I like your idea to kill `pipex_iface_contex

Re: sppp: add size to free() calls

2020-08-22 Thread Vitaliy Makkoveev
Yeah, we override both of 'auth->name' and 'auth->secret’. Since there is the only difference against your previous diff and the only place where you touch them I have no objections. > On 22 Aug 2020, at 18:00, Klemens Nanni wrote: > > On Sat, Aug 22, 2020 at 02:32:17PM +0200, Klemens Nanni

Re: sppp: add size to free() calls

2020-08-22 Thread Vitaliy Makkoveev
ok mvs@ > On 22 Aug 2020, at 15:32, Klemens Nanni wrote: > > Another round, this time obvious sizes which are in immediate scope of > the free() call, e.g. right below the malloc() call. > > This leaves only a few selected free() calls with size zero in > if_spppsubr.c due to the fact that

Re: *_clone_create: leave default ifq_maxlen handling to ifq_init()

2020-08-21 Thread Vitaliy Makkoveev
On Fri, Aug 21, 2020 at 11:05:56PM +0200, Klemens Nanni wrote: > Creating a cloned interface requires attaching it in the end, that's how > it works. > > All clonable interfaces start with a fresh softc structure that all > zeros after allocation due to malloc(9)'s M_ZERO flag. > > After driver

Re: Enable EVFILT_EXCEPT

2020-08-21 Thread Vitaliy Makkoveev
ok mvs@ > On 21 Aug 2020, at 10:32, Martin Pieuchot wrote: > > The kqueue-based poll(2) backend is still a WIP due to regressions in > the kqueue layer. In the meantime should we expose EVFILT_EXCEPT to > userland? The diff below should be enough to allow userland apps to > use the new code

Re: pppoe: add sizes to free() calls

2020-08-20 Thread Vitaliy Makkoveev
ok mvs@ > On 20 Aug 2020, at 17:12, Klemens Nanni wrote: > > On Thu, Aug 20, 2020 at 03:33:17PM +0200, Klemens Nanni wrote: >> These are straight forward as we either maintain a size variable all the >> way or can reuse strlen() for free() just like it's done during malloc(). >> >> One

Re: pppoe: add sizes to free() calls

2020-08-20 Thread Vitaliy Makkoveev
> On 20 Aug 2020, at 16:33, Klemens Nanni wrote: > > These are straight forward as we either maintain a size variable all the > way or can reuse strlen() for free() just like it's done during malloc(). > > One exception is freeing the softc structure, which is fixed in size; > `ifconfig pppoe1

Re: Remove unnecessary field from struct msgbuf

2020-08-18 Thread Vitaliy Makkoveev
ok mvs@ > On 16 Aug 2020, at 14:35, Visa Hankala wrote: > > The msg_bufl field of struct msgbuf is written but never read. The value > was used by kernfs which is no longer present, so the code could be > cleaned up a little by removing the field. > > On some systems the message buffer data

Re: Remove unnecessary field from struct msgbuf

2020-08-16 Thread Vitaliy Makkoveev
The diff looks good for me. I’ll recompile system with your diff tomorrow. > On 16 Aug 2020, at 14:35, Visa Hankala wrote: > > The msg_bufl field of struct msgbuf is written but never read. The value > was used by kernfs which is no longer present, so the code could be > cleaned up a little by

Re: pppoe: start without kernel lock

2020-08-16 Thread Vitaliy Makkoveev
On Sun, Aug 16, 2020 at 08:44:07PM +0200, Klemens Nanni wrote: > On Sun, Aug 16, 2020 at 07:04:46PM +0200, Klemens Nanni wrote: > > Make sppp(4)/pppoe(4) use the ifq API to send packets outside the big > > lock. > > > > As far as I understand, pppoe_output() does not require NET_LOCK() since > >

Re: pppac(4): destroy sessions the same way as pppx(4) does

2020-08-16 Thread Vitaliy Makkoveev
On Sat, Aug 15, 2020 at 02:01:52PM +0900, YASUOKA Masahiko wrote: > On Wed, 12 Aug 2020 12:26:22 +0300 > Vitaliy Makkoveev wrote: > > We destroy pppx(4) related sessions while we performing PIPEXDSESSION > > command. But with pppac(4) we set session's state to > > PIPEX_

Re: Make pipex more common for pppac and pppx

2020-08-16 Thread Vitaliy Makkoveev
On Sat, Aug 15, 2020 at 05:42:06PM +0900, YASUOKA Masahiko wrote: > Let me update the diff. A bug found by the test. > Hello Yasuoka. I like your idea to kill `pipex_iface_context'. I had trying to keep it by myself and this was wrong way. Could you rework your diff to be against the recent

Re: pipex "idle-timeout" work with pppx(4).

2020-08-12 Thread Vitaliy Makkoveev
On Wed, Aug 12, 2020 at 09:07:15PM +0900, YASUOKA Masahiko wrote: > Hi, > > On Wed, 12 Aug 2020 12:38:39 +0300 > Vitaliy Makkoveev wrote: > > We don't need to mark pppx(4) sessions because there is no special cases > > for them. We just need to kill pppx(4) rela

Re: pppx(4): move ifnet out of KERNEL_LOCK()

2020-08-12 Thread Vitaliy Makkoveev
Updated to the recent source. The diff is OK'ed by yasuoka@. Also I did what mpi@ requested. Should I still wait? Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.100 diff -u -p -r1.100

Re: pipex "idle-timeout" work with pppx(4).

2020-08-12 Thread Vitaliy Makkoveev
On Wed, Aug 12, 2020 at 11:17:29AM +0900, YASUOKA Masahiko wrote: > On Tue, 11 Aug 2020 23:06:45 +0300 > Vitaliy Makkoveev wrote: > > We removed `pipex{in,out}q'. So now we can destroy pppac(4) session just > > like we do in pppx(4) case. Also there is no reason to all

pppac(4): destroy sessions the same way as pppx(4) does

2020-08-12 Thread Vitaliy Makkoveev
We destroy pppx(4) related sessions while we performing PIPEXDSESSION command. But with pppac(4) we set session's state to PIPEX_STATE_CLOSE_WAIT2 and we wait garbage collector to do destruction. We removed `pipex{in,out}q'. So we can safe destroy session in any time. I propose to make pppac(4)

Re: pipex "idle-timeout" work with pppx(4).

2020-08-11 Thread Vitaliy Makkoveev
On Wed, Aug 12, 2020 at 01:36:38AM +0900, YASUOKA Masahiko wrote: > > my diff is to make pppx(4) have the same "idle-timeout" > functionality. I strongly think pppx(4) must have the same > functionalities of pppac(4) because I don't see any reason to have > any difference between pppx(4) and

Re: pipex "idle-timeout" work with pppx(4).

2020-08-11 Thread Vitaliy Makkoveev
On Wed, Aug 12, 2020 at 12:37:13AM +0900, YASUOKA Masahiko wrote: > Hi, > > On Mon, 10 Aug 2020 16:30:27 +0300 > Vitaliy Makkoveev wrote: > > On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote: > >> On Sun, 9 Aug 2020 20:03:50 +0300 > >> Vitaliy

ppp{ac,x}(4): interface statistics fix.

2020-08-11 Thread Vitaliy Makkoveev
We count outgoing packets twice (nothing but icmp echo request/reply): obsd-test# netstat -I pppac0 NameMtu Network Address Ipkts IfailOpkts Ofail Colls pppac0 65532 878 0 1756 0 0 pppac0 65532 10.0.0.1/32 10.0.0.1 878 0 1756

Re: pipex "idle-timeout" work with pppx(4).

2020-08-10 Thread Vitaliy Makkoveev
> On 10 Aug 2020, at 19:53, Vitaliy Makkoveev wrote: > > We are doing all wrong :) > > We can just unlink pppx(4) related session from `pipex_session_list' if > it's time expired. But since this unlinked session is still exists in > pppx(4) layer we can access th

Re: pipex "idle-timeout" work with pppx(4).

2020-08-10 Thread Vitaliy Makkoveev
nd On Mon, Aug 10, 2020 at 04:30:27PM +0300, Vitaliy Makkoveev wrote: > On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote: > > Hi, > > > > Thank you for your review. > > > > On Sun, 9 Aug 2020 20:03:50 +0300 > > Vitaliy Makkoveev

Re: pipex "idle-timeout" work with pppx(4).

2020-08-10 Thread Vitaliy Makkoveev
On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote: > Hi, > > Thank you for your review. > > On Sun, 9 Aug 2020 20:03:50 +0300 > Vitaliy Makkoveev wrote: > > On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote: > >> You propose to unl

Re: pfsync: start without kernel lock

2020-08-09 Thread Vitaliy Makkoveev
On Sun, Aug 09, 2020 at 08:53:04PM +0200, Klemens Nanni wrote: > On Sun, Aug 09, 2020 at 06:42:07PM +0300, Vitaliy Makkoveev wrote: > > Does `IFXF_MPSAFE' bit assume that pfsyncioctl() should not rely to > > kernel lock and pfsync(4) related data structures already have their own

Re: pipex "idle-timeout" work with pppx(4).

2020-08-09 Thread Vitaliy Makkoveev
On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote: > Hello Yasuoka. > > You propose to unlink pppx(4) related session which reached timeout. I'm > ok with this direction. But I see no reason to rework _get_closed() > routines. > > in pppac(4) case it's as

Re: pfsync: start without kernel lock

2020-08-09 Thread Vitaliy Makkoveev
On Sun, Aug 09, 2020 at 02:33:01PM +0200, Klemens Nanni wrote: > mvs's vnet(4) diff reminded me of pfsync(4). > > This works on my my pair of amd64 firewalls. > > Feedback? OK? > Does `IFXF_MPSAFE' bit assume that pfsyncioctl() should not rely to kernel lock and pfsync(4) related data

Re: pipex "idle-timeout" work with pppx(4).

2020-08-09 Thread Vitaliy Makkoveev
Hello Yasuoka. You propose to unlink pppx(4) related session which reached timeout. I'm ok with this direction. But I see no reason to rework _get_closed() routines. in pppac(4) case it's assumed what if session is not yet destroyed by garbage collector, it will be destroyed while we performing

vether(4): move `ifnet' out of KERNEL_LOCK()

2020-08-08 Thread Vitaliy Makkoveev
vether(4) is pretty dummy. Nothing denies it to be `IFXF_MPSAFE'. Index: sys/net/if_vether.c === RCS file: /cvs/src/sys/net/if_vether.c,v retrieving revision 1.33 diff -u -p -r1.33 if_vether.c --- sys/net/if_vether.c 28 Jul 2020

Re: describe 'idle-timeout' exception in npppd.conf man page

2020-08-08 Thread Vitaliy Makkoveev
I did audit for "idle-timeout" option. On Sat, Aug 08, 2020 at 08:49:24PM +0900, YASUOKA Masahiko wrote: > On Fri, 7 Aug 2020 22:19:05 +0300 > Vitaliy Makkoveev wrote: > > Some times ago we disabled in-kernel timeout for pppx(4) related > > pipex(4) sessions. We di

Re: pppac(4) move ifnet out of KERNEL_LOCK()

2020-08-08 Thread Vitaliy Makkoveev
Another update. The whole "while ((m = ifq_dequeue(ifq)) != NULL)" wrapped by netlock as it was made for pppx(4). This is to exclude per-packet lock/unlock in output path. Index: sys/net/if_pppx.c === RCS file:

Re: describe 'idle-timeout' exception in npppd.conf man page

2020-08-08 Thread Vitaliy Makkoveev
On Sat, Aug 08, 2020 at 08:49:24PM +0900, YASUOKA Masahiko wrote: > On Fri, 7 Aug 2020 22:19:05 +0300 > Vitaliy Makkoveev wrote: > > Some times ago we disabled in-kernel timeout for pppx(4) related > > pipex(4) sessions. We did this for prevent use after free issue caused >

Re: describe 'idle-timeout' exception in npppd.conf man page

2020-08-07 Thread Vitaliy Makkoveev
On Fri, Aug 07, 2020 at 09:29:13PM +0100, Jason McIntyre wrote: > On Fri, Aug 07, 2020 at 10:19:05PM +0300, Vitaliy Makkoveev wrote: > > Some times ago we disabled in-kernel timeout for pppx(4) related > > pipex(4) sessions. We did this for prevent use after free issue caused > &

describe 'idle-timeout' exception in npppd.conf man page

2020-08-07 Thread Vitaliy Makkoveev
Some times ago we disabled in-kernel timeout for pppx(4) related pipex(4) sessions. We did this for prevent use after free issue caused by pipex_timer [1]. By default "idle-timeout" is not set in npppd.conf(5) and I guess this is reason for we forgot to describe this exception in npppd.conf(5).

Re: pppx(4): move ifnet out of KERNEL_LOCK()

2020-08-06 Thread Vitaliy Makkoveev
On Thu, Aug 06, 2020 at 01:25:14PM +0200, Martin Pieuchot wrote: > On 05/08/20(Wed) 12:50, Vitaliy Makkoveev wrote: > > pipex(4) and pppx(4) are ready to became a little bit more MP capable. > > Diff below moves pppx(4) related `ifnet' out of KERNEL_LOCK(). > > Ni

Remove unused netisr defines

2020-08-05 Thread Vitaliy Makkoveev
Remove defines for netisr bits which are not used anymore. Index: sys/net/netisr.h === RCS file: /cvs/src/sys/net/netisr.h,v retrieving revision 1.52 diff -u -p -r1.52 netisr.h --- sys/net/netisr.h4 Aug 2020 09:32:05 -

Re: Don't check pointers against 0

2020-08-05 Thread Vitaliy Makkoveev
ok mvs > On 5 Aug 2020, at 23:49, Marcus Glocker wrote: > > Reported by Peter J. Philipp. > > OK? > > > Index: sys/netinet/udp_usrreq.c > === > RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v > retrieving revision 1.260 > diff -u

Re: pppac(4) move ifnet out of KERNEL_LOCK()

2020-08-05 Thread Vitaliy Makkoveev
A little update. I use `ifq' passed to pppac_start() instead of `ifp->if_snd' for consistency reason. Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.98 diff -u -p -r1.98 if_pppx.c ---

Re: bugs in bridge ( netlock ? )

2020-08-05 Thread Vitaliy Makkoveev
I guess it’s know issue caused by ifioctl() races. > On 5 Aug 2020, at 19:06, Sven F. wrote: > > On Wed, Aug 5, 2020 at 9:14 AM Sven F. wrote: >> >> Never seen before crash ( 6. 7 stable ) >> >> My devices run a lot of things in, load is easily 4 >> which is good for breaking lock code ? >>

pppac(4) move ifnet out of KERNEL_LOCK()

2020-08-05 Thread Vitaliy Makkoveev
The same as for pppx(4). pipex(4) and pppac(4) are ready to became a little bit more MP capable. Diff below moves pppac(4) related `ifnet' out of KERNEL_LOCK(). The wakeup(9) and selwakeup() are not require KERNEL_LOCK() so this assertion was wrong and can be dropped. Also we detach `ifnet'

pppx(4): move ifnet out of KERNEL_LOCK()

2020-08-05 Thread Vitaliy Makkoveev
pipex(4) and pppx(4) are ready to became a little bit more MP capable. Diff below moves pppx(4) related `ifnet' out of KERNEL_LOCK(). Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.98 diff

Re: pipex(4): kill pipexintr()

2020-08-04 Thread Vitaliy Makkoveev
On Tue, Aug 04, 2020 at 01:53:55PM +0900, YASUOKA Masahiko wrote: > On Mon, 3 Aug 2020 23:36:09 +0300 > Vitaliy Makkoveev wrote: > > On Tue, Aug 04, 2020 at 01:26:14AM +0900, YASUOKA Masahiko wrote: > >> Comments? > > > > You introduce `cookie' as > > &

Re: pipex(4): kill pipexintr()

2020-08-03 Thread Vitaliy Makkoveev
On Tue, Aug 04, 2020 at 01:26:14AM +0900, YASUOKA Masahiko wrote: > On Sat, 1 Aug 2020 18:52:27 +0300 > Vitaliy Makkoveev wrote: > > On Sat, Aug 01, 2020 at 07:44:17PM +0900, YASUOKA Masahiko wrote: > >> I'm not sure when it is broken, in old versions, it was assumed

Re: pipex(4): kill pipexintr()

2020-08-01 Thread Vitaliy Makkoveev
On Sat, Aug 01, 2020 at 07:44:17PM +0900, YASUOKA Masahiko wrote: > Hi, > > I'm not sure when it is broken, in old versions, it was assumed the > pipex queues are empty when pipex_iface_stop() is called. The problem > mvs@ found is the assumption is not true any more. > > pipex has a mechanism

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
On Fri, Jul 31, 2020 at 10:25:48PM +0200, Martin Pieuchot wrote: > On 31/07/20(Fri) 21:58, Vitaliy Makkoveev wrote: > > [...] > > What denies us to move pipex(4) under it's own lock? > > Such question won't lead us anywhere. It assumes it makes sense to move >

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
Well, since pipexintr() killing was rejected, I propose to implement reference counters to protect pipex(4) session itself. Diff below does this. Index: sys/net/if_ethersubr.c === RCS file: /cvs/src/sys/net/if_ethersubr.c,v

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
On Fri, Jul 31, 2020 at 08:26:22PM +0200, Martin Pieuchot wrote: > On 31/07/20(Fri) 12:15, Vitaliy Makkoveev wrote: > > On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote: > > > On Thu, 30 Jul 2020 22:43:10 +0300 > > > Vitaliy Makkoveev wrote: > >

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote: > On Thu, 30 Jul 2020 22:43:10 +0300 > Vitaliy Makkoveev wrote: > > On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote: > >> On Thu, 30 Jul 2020 15:34:09 +0300 > >> Vitaliy Makkoveev

Re: pipex(4): kill pipexintr()

2020-07-30 Thread Vitaliy Makkoveev
On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote: > On Thu, 30 Jul 2020 15:34:09 +0300 > Vitaliy Makkoveev wrote: > > On Thu, Jul 30, 2020 at 09:13:46PM +0900, YASUOKA Masahiko wrote: > >> Hi, > >> > >> sys/net/if_ethersubr.c: > >>

Re: pipex(4): kill pipexintr()

2020-07-30 Thread Vitaliy Makkoveev
On Thu, Jul 30, 2020 at 09:13:46PM +0900, YASUOKA Masahiko wrote: > Hi, > > sys/net/if_ethersubr.c: > 372 void > 373 ether_input(struct ifnet *ifp, struct mbuf *m) > (snip) > 519 #if NPPPOE > 0 || defined(PIPEX) > 520 case ETHERTYPE_PPPOEDISC: > 521 case ETHERTYPE_PPPOE: > 522

pipex(4): kill pipexintr()

2020-07-29 Thread Vitaliy Makkoveev
Now pipex(4) is fully covered by NET_LOCK() and this is documented. But we still have an issue with pipex(4) session itself and I guess it's time to fix it. We have `pipexinq' and `pipexoutq' mbuf(9) queues to store mbufs. Each mbuf(9) passed to these queues stores the pointer to corresponding

Re: NET_LOCK and trunk detach

2020-07-28 Thread Vitaliy Makkoveev
> On 29 Jul 2020, at 00:09, sven falempin wrote: > > On Tue, Jul 28, 2020 at 4:42 PM Vitaliy Makkoveev wrote: >> >> On Tue, Jul 28, 2020 at 04:10:01PM -0400, sven falempin wrote: >>> Hello, >>> >>> I am running some trunk interfaces in a mult

Re: NET_LOCK and trunk detach

2020-07-28 Thread Vitaliy Makkoveev
On Tue, Jul 28, 2020 at 04:10:01PM -0400, sven falempin wrote: > Hello, > > I am running some trunk interfaces in a multi core environment, > it's a slightly modified version, i have a few NET_ASSERT_LOCKED(); > suspecting some multi core shenanigans, which i guess was confirmed: > (unsure the

Re: pipex(4): document global data locks

2020-07-28 Thread Vitaliy Makkoveev
On Tue, Jul 28, 2020 at 10:26:53AM +0200, Martin Pieuchot wrote: > On 17/07/20(Fri) 17:04, Vitaliy Makkoveev wrote: > > Subj. Also add NET_ASSERT_LOCKED() to pipex_{link,unlink,rele}_session() > > to be sure they called under NET_LOCK(). > > pipex_rele_session() is

Re: pipex_iface_fini() release multicast session under NET_LOCK()

2020-07-28 Thread Vitaliy Makkoveev
On Tue, Jul 28, 2020 at 10:23:08AM +0200, Martin Pieuchot wrote: > On 17/07/20(Fri) 16:29, Vitaliy Makkoveev wrote: > > We are going to lock the whole pipex(4) by NET_LOCK(). So move > > `multicast_session' freeing undet NET_LOCK() too. > > pipex_iface_fini() should

pipex(4): document global data locks

2020-07-17 Thread Vitaliy Makkoveev
Subj. Also add NET_ASSERT_LOCKED() to pipex_{link,unlink,rele}_session() to be sure they called under NET_LOCK(). Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.120 diff -u -p -r1.120 pipex.c

ppp{ac,x}(4): document locks

2020-07-17 Thread Vitaliy Makkoveev
Subj. Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.97 diff -u -p -r1.97 if_pppx.c --- sys/net/if_pppx.c 17 Jul 2020 08:57:27 - 1.97 +++ sys/net/if_pppx.c 17 Jul 2020 13:51:14

pipex_iface_fini() release multicast session under NET_LOCK()

2020-07-17 Thread Vitaliy Makkoveev
We are going to lock the whole pipex(4) by NET_LOCK(). So move `multicast_session' freeing undet NET_LOCK() too. Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.120 diff -u -p -r1.120 pipex.c ---

Re: Add missing `IFXF_CLONED' to pseudo-interfaces

2020-07-17 Thread Vitaliy Makkoveev
ping? > On 10 Jul 2020, at 14:59, Vitaliy Makkoveev wrote: > > Some pseudo interfaces have missing `IFXF_CLONED' flag. Diff below fixes > this. > > Index: sys/net/if_ppp.c > === > RCS file: /cvs/src/sys/net

Re: Add missing `IFXF_CLONED' to pseudo-interfaces

2020-07-17 Thread Vitaliy Makkoveev
anyone? On Fri, Jul 10, 2020 at 02:59:55PM +0300, Vitaliy Makkoveev wrote: > Some pseudo interfaces have missing `IFXF_CLONED' flag. Diff below fixes > this. > > Index: sys/net/if_ppp.c > === > RCS file: /cvs/src/

pipex(4): use interface indexes (if_get(9)) instead of pointers

2020-07-16 Thread Vitaliy Makkoveev
Interface index 0 is never associated with interface descriptor. So we can assign this value to session's interface index before destroy corresponding `ifnet'. It's safe to use indexes instead of pointers to `ifnet' in pipex(4). Index: sys/net/if_pppx.c

Re: pppac(4): fix races in pppacopen()

2020-07-13 Thread Vitaliy Makkoveev
Forget please about previous diff. Except ac_ioctl() the only function which can have race with pppacclose() is pppacopen(), but since `sc' is still linked to `pppac_devs' list we can't reopen dying `sc'. So the only race is pppacopen() vs pppacopen(). We only need to malloc(9) before

Re: pppac(4): fix races in pppacopen()

2020-07-13 Thread Vitaliy Makkoveev
On Mon, Jul 13, 2020 at 09:39:38AM +0200, Martin Pieuchot wrote: > On 11/07/20(Sat) 23:51, Vitaliy Makkoveev wrote: > > [...] > > The way you suggest to go is to introduce rwlock and serialize > > pppacopen() and pppacclose(). This is bad idea because we will sleep > >

Re: fix races in if_clone_create()

2020-07-13 Thread Vitaliy Makkoveev
On Mon, Jul 13, 2020 at 12:52:15PM +0300, Vitaliy Makkoveev wrote: > On Mon, Jul 13, 2020 at 09:53:44AM +0200, Martin Pieuchot wrote: > > On 06/07/20(Mon) 15:44, Vitaliy Makkoveev wrote: > > > > On 6 Jul 2020, at 12:17, Martin Pieuchot wrote: > > > > Asse

Re: Add missing `IFXF_CLONED' to pseudo-interfaces

2020-07-13 Thread Vitaliy Makkoveev
ping? On Fri, Jul 10, 2020 at 02:59:55PM +0300, Vitaliy Makkoveev wrote: > Some pseudo interfaces have missing `IFXF_CLONED' flag. Diff below fixes > this. > > Index: sys/net/if_ppp.c > === > RCS file: /cvs/src/

Re: fix races in if_clone_create()

2020-07-13 Thread Vitaliy Makkoveev
On Mon, Jul 13, 2020 at 09:53:44AM +0200, Martin Pieuchot wrote: > On 06/07/20(Mon) 15:44, Vitaliy Makkoveev wrote: > > > On 6 Jul 2020, at 12:17, Martin Pieuchot wrote: > > > Assertions and documentation are more important than preventing races > > > because

Re: softraid_crypto: add size to free call

2020-07-12 Thread Vitaliy Makkoveev
ok mvs@ > On 13 Jul 2020, at 01:22, Klemens Nanni wrote: > > On Sun, Jul 12, 2020 at 10:31:49PM +0300, Vitaliy Makkoveev wrote: >> I like to have "sizeof(*omi)" in corresponding malloc(9) too. >> >> cut begin >> 827

Re: softraid_crypto: add size to free call

2020-07-12 Thread Vitaliy Makkoveev
On Sun, Jul 12, 2020 at 08:51:08PM +0200, Klemens Nanni wrote: > While omi->omi_som seems variable in size, omi is only ever allocated > with one size and softraid.c uses the same size for free(9) as well. > > Tested with cryto softraid and keydisk. > > Feedback? OK? > > > Index:

Re: wg: fix build without pf

2020-07-12 Thread Vitaliy Makkoveev
On Sun, Jul 12, 2020 at 07:44:47PM +0200, Klemens Nanni wrote: OK mvs@ > Feedback? OK? > > > Index: sys/net/if_wg.c > === > RCS file: /cvs/src/sys/net/if_wg.c,v > retrieving revision 1.9 > diff -u -p -r1.9 if_wg.c > ---

Re: pppac(4): fix races in pppacopen()

2020-07-11 Thread Vitaliy Makkoveev
On Sat, Jul 11, 2020 at 10:11:03AM +0200, Martin Pieuchot wrote: > On 10/07/20(Fri) 14:38, Vitaliy Makkoveev wrote: > > On Fri, Jul 10, 2020 at 01:22:40PM +0200, Martin Pieuchot wrote: > > > On 10/07/20(Fri) 14:07, Vitaliy Makkoveev wrote: > > > > We have some races i

Re: pipex(4): kill pipexintr()

2020-07-11 Thread Vitaliy Makkoveev
On Fri, Jul 10, 2020 at 10:54:44AM +0200, Martin Pieuchot wrote: > On 07/07/20(Tue) 01:01, Vitaliy Makkoveev wrote: > > On Mon, Jul 06, 2020 at 08:47:23PM +0200, Martin Pieuchot wrote: > > > On 06/07/20(Mon) 19:23, Vitaliy Makkoveev wrote: > > > > > On 6 Jul 2020,

Add missing `IFXF_CLONED' to pseudo-interfaces

2020-07-10 Thread Vitaliy Makkoveev
Some pseudo interfaces have missing `IFXF_CLONED' flag. Diff below fixes this. Index: sys/net/if_ppp.c === RCS file: /cvs/src/sys/net/if_ppp.c,v retrieving revision 1.114 diff -u -p -r1.114 if_ppp.c --- sys/net/if_ppp.c24 Jun

Re: pppac(4): fix races in pppacopen()

2020-07-10 Thread Vitaliy Makkoveev
On Fri, Jul 10, 2020 at 01:22:40PM +0200, Martin Pieuchot wrote: > On 10/07/20(Fri) 14:07, Vitaliy Makkoveev wrote: > > We have some races in pppac(4) > > 1. malloc(9) can sleep so we must check `sc' presence after malloc(9) > > Makes sense. > > > 2. we ca

pppac(4): fix races in pppacopen()

2020-07-10 Thread Vitaliy Makkoveev
We have some races in pppac(4) 1. malloc(9) can sleep so we must check `sc' presence after malloc(9) 2. we can sleep between `sc' insertion to `sc_entry' list and `sc_pipex_iface' initialization. Concurrent pppacioctl() can touch this incomplete `sc'. Index: sys/net/if_pppx.c

Re: pppx_if_output() don't lock `pppx_devs_lk'

2020-07-10 Thread Vitaliy Makkoveev
On Fri, Jul 10, 2020 at 10:45:54AM +0200, Martin Pieuchot wrote: > On 08/07/20(Wed) 12:05, Vitaliy Makkoveev wrote: > > `pppx_devs_lk' used to protect `pxd_entry' list. We lock `pppx_devs_lk' > > in pppx_if_output() to be sure `pxd' is not destroyed by concurrent > > pppxclo

Re: remove compat macros IFQ_ENQUEUE, IFQ_DEQUEUE and IFQ_LEN

2020-07-10 Thread Vitaliy Makkoveev
> On 10 Jul 2020, at 12:13, Patrick Wildt wrote: > > Hi, > > this is a rather mechanical diff, done using vim and some regex, > to remove and replace IFQ_ENQUEUE, IFQ_DEQUEUE and IFQ_LEN. > > There are more, but I didn't want the diff to get too big. I'll > do that after this one is

pppx_if_output() don't lock `pppx_devs_lk'

2020-07-08 Thread Vitaliy Makkoveev
`pppx_devs_lk' used to protect `pxd_entry' list. We lock `pppx_devs_lk' in pppx_if_output() to be sure `pxd' is not destroyed by concurrent pppxclose() but it's useless. We destroy all corresponding `pxi' before `pxd' and `ifnet's are already detached. Index: sys/net/if_pppx.c

pppx(4): do not collect entropy?

2020-07-07 Thread Vitaliy Makkoveev
pppac(4) related `ifnet' has `IFXF_CLONED' set. I guess this was done because we don't collect entropy from pseudo interfaces: cut begin void if_input_process(struct ifnet *ifp, struct mbuf_list *ml) { struct mbuf *m; if (ml_empty(ml)) return;

Re: userland clock_gettime proof of concept

2020-07-06 Thread Vitaliy Makkoveev
Sorry for late reaction. At least VirtualBox based virtual machines started to panic with the recent kernel. I reverted your diff and panics stopped. Screenshot attached.

Re: userland clock_gettime proof of concept

2020-07-06 Thread Vitaliy Makkoveev
> On 5 Jul 2020, at 20:31, Paul Irofti wrote: > > On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote: >> >> >> În 3 iulie 2020 17:55:25 EEST, Mark Kettenis a >> scris: Date: Fri, 3 Jul 2020 15:13:22 +0200 From: Robert Nagy On 02/07/20 00:31 +0100, Stuart

Re: pipex(4): kill pipexintr()

2020-07-06 Thread Vitaliy Makkoveev
On Mon, Jul 06, 2020 at 08:47:23PM +0200, Martin Pieuchot wrote: > On 06/07/20(Mon) 19:23, Vitaliy Makkoveev wrote: > > > On 6 Jul 2020, at 17:36, Martin Pieuchot wrote: > > [...] > > Unfortunately you can’t be sure about NET_LOCK() status while you are > > in p

Re: pipex(4): kill pipexintr()

2020-07-06 Thread Vitaliy Makkoveev
> On 6 Jul 2020, at 17:36, Martin Pieuchot wrote: > > On 06/07/20(Mon) 16:42, Vitaliy Makkoveev wrote: >> [...] >> pipex(4) is simultaneously locked by NET_LOCK() and KERNEL_LOCK() but >> with two exceptions: >> >> 1. As you pointed pipex_pppoe_input()

pipex(4) prevent `old_session_keys' memory leak

2020-07-06 Thread Vitaliy Makkoveev
Before session freeing pipex_rele_session() will check and release `old_session_keys' if necessary. So use it instead of pool_put(9) within pipex_destroy_session(). Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v

Re: pipex(4): kill pipexintr()

2020-07-06 Thread Vitaliy Makkoveev
On Mon, Jul 06, 2020 at 10:59:17AM +0200, Martin Pieuchot wrote: > On 01/07/20(Wed) 22:42, Vitaliy Makkoveev wrote: > > pipex(4) has 2 mbuf queues: `pipexinq' and `pipexoutq'. When mbuf passed > > to pipex it goes to one of these queues and pipexintr() will be > > sche

Re: fix races in if_clone_create()

2020-07-06 Thread Vitaliy Makkoveev
> On 6 Jul 2020, at 12:17, Martin Pieuchot wrote: > > On 01/07/20(Wed) 00:02, Vitaliy Makkoveev wrote: >> On Tue, Jun 30, 2020 at 03:48:22PM +0300, Vitaliy Makkoveev wrote: >>> On Tue, Jun 30, 2020 at 12:08:03PM +0200, Martin Pieuchot wrote: >>>> On 29

Re: pipex(4): kill pipexintr()

2020-07-03 Thread Vitaliy Makkoveev
ping? > On 1 Jul 2020, at 22:42, Vitaliy Makkoveev wrote: > > pipex(4) has 2 mbuf queues: `pipexinq' and `pipexoutq'. When mbuf passed > to pipex it goes to one of these queues and pipexintr() will be > scheduled to process them. pipexintr() called from `netisr' context.

Re: fix races in if_clone_create()

2020-07-03 Thread Vitaliy Makkoveev
ping? > On 1 Jul 2020, at 00:02, Vitaliy Makkoveev wrote: > > On Tue, Jun 30, 2020 at 03:48:22PM +0300, Vitaliy Makkoveev wrote: >> On Tue, Jun 30, 2020 at 12:08:03PM +0200, Martin Pieuchot wrote: >>> On 29/06/20(Mon) 11:59, Vitaliy Makkoveev wrote: >>

pipex(4): kill pipexintr()

2020-07-01 Thread Vitaliy Makkoveev
pipex(4) has 2 mbuf queues: `pipexinq' and `pipexoutq'. When mbuf passed to pipex it goes to one of these queues and pipexintr() will be scheduled to process them. pipexintr() called from `netisr' context. It's true for pppac(4) but for pppx(4) only incoming mbufs go to `pipexinq. Outgoing mbufs

Re: fix races in if_clone_create()

2020-06-30 Thread Vitaliy Makkoveev
On Tue, Jun 30, 2020 at 03:48:22PM +0300, Vitaliy Makkoveev wrote: > On Tue, Jun 30, 2020 at 12:08:03PM +0200, Martin Pieuchot wrote: > > On 29/06/20(Mon) 11:59, Vitaliy Makkoveev wrote: > > > [...] > > > I reworked tool for reproduce. Now I avoided fork()/exec() rout

pipex(4): kill unused declaration

2020-06-30 Thread Vitaliy Makkoveev
`udpcksum' declared but not used in net/pipex.c, so kill it Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.116 diff -u -p -r1.116 pipex.c --- sys/net/pipex.c 22 Jun 2020 09:38:15 -

Re: fix races in if_clone_create()

2020-06-30 Thread Vitaliy Makkoveev
On Tue, Jun 30, 2020 at 12:08:03PM +0200, Martin Pieuchot wrote: > On 29/06/20(Mon) 11:59, Vitaliy Makkoveev wrote: > > [...] > > I reworked tool for reproduce. Now I avoided fork()/exec() route and it > > takes couple of minutes to take panic on 4 cores. Also some scr

Re: if_delgroup(): Add size to free(9) call

2020-06-30 Thread Vitaliy Makkoveev
On Tue, Jun 30, 2020 at 04:11:59AM +0200, Klemens Nanni wrote: > Interface groups are allocated as follows: > > struct ifg_group * > if_creategroup(const char *groupname) > { > struct ifg_group*ifg; > > if ((ifg = malloc(sizeof(*ifg), M_TEMP,

Re: fix races in if_clone_create()

2020-06-29 Thread Vitaliy Makkoveev
On Mon, Jun 29, 2020 at 04:27:50PM +0200, Hrvoje Popovski wrote: > On 29.6.2020. 10:59, Vitaliy Makkoveev wrote: > > I reworked tool for reproduce. Now I avoided fork()/exec() route and it > > takes couple of minutes to take panic on 4 cores. Also some screenshots > > atta

Re: fix races in if_clone_create()

2020-06-29 Thread Vitaliy Makkoveev
On Sat, Jun 27, 2020 at 12:10:24PM +0200, Martin Pieuchot wrote: > On 27/06/20(Sat) 00:35, Vitaliy Makkoveev wrote: > > On Fri, Jun 26, 2020 at 09:12:16PM +0200, Martin Pieuchot wrote: > > > On 26/06/20(Fri) 16:56, Vitaliy Makkoveev wrote: > > > > if_clone_create() h

Re: fix races in if_clone_create()

2020-06-29 Thread Vitaliy Makkoveev
screenshot

Re: fix races in if_clone_create()

2020-06-29 Thread Vitaliy Makkoveev
On Sat, Jun 27, 2020 at 12:10:24PM +0200, Martin Pieuchot wrote: > On 27/06/20(Sat) 00:35, Vitaliy Makkoveev wrote: > > On Fri, Jun 26, 2020 at 09:12:16PM +0200, Martin Pieuchot wrote: > > > On 26/06/20(Fri) 16:56, Vitaliy Makkoveev wrote: > > > > if_clone_create() h

  1   2   3   >