> 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
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)
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
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
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
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
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
> &
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
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
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
>
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:
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
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
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
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
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:
> >
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
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
>
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'
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
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 ?
>>
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
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 -
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
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
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
---
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,
`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 -
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
`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
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;
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
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
> 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
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
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/
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
> 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
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
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
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
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
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
> >
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
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
> ---
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:
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
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) 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
> 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()
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,
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
> On 25 Jun 2020, at 11:55, Martin Pieuchot wrote:
>
> On 24/06/20(Wed) 17:10, Vitaliy Makkoveev wrote:
>> While `mbuf' enqueued to `pipexinq' or `pipexoutq' it has the reference
>> to corresponding pipex(4) session as `ph_cookie'. `ph_cookie' is
>> accessed by
> On 25 Jun 2020, at 16:35, Christiano F. Haesbaert
> wrote:
>
> On Thu, 25 Jun 2020 at 14:06, Vitaliy Makkoveev
> wrote:
>>
>>
>>
>>> On 25 Jun 2020, at 11:55, Martin Pieuchot wrote:
>>>
>>> On 24/06/20(Wed) 17:10, Vita
On Thu, Jun 25, 2020 at 11:54:48AM +0200, Martin Pieuchot wrote:
> On 23/06/20(Tue) 16:21, Martin Pieuchot wrote:
> > On 23/06/20(Tue) 04:53, Jason A. Donenfeld wrote:
> > > On 6/23/20, Martin Pieuchot wrote:
> > > > On 23/06/20(Tue) 01:00, Jason A. Donenfeld wrote:
> > > >> You can crash a
While `mbuf' enqueued to `pipexinq' or `pipexoutq' it has the reference
to corresponding pipex(4) session as `ph_cookie'. `ph_cookie' is
accessed by pipexintr() and it's always defferent context from context
where we destroy session. `ph_cookie' is protected only while we destroy
session by
Updated diff.
OpenBSD uses 16 bit counter for allocate interface indexes. So we can't
store index in session and be sure if_get(9) returned `ifnet' is our
original `ifnet'.
Now each pipex(4) session has it's own reference to `ifnet'. Also pppoe
related sessions has the reference to it's
* be
overflowed. Not the interface count.
>
> On Thu, Jun 25, 2020, 18:55 Vitaliy Makkoveev
> wrote:
>
>> Updated diff.
>>
>> OpenBSD uses 16 bit counter for allocate interface indexes. So we can't
>> store index in session and be sure if_get(9) returned `ifne
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() has the races caused by context switch.
>
> Can you share a backtrace of such race? Where does the kernel panic?
>
This diff was inspired b
> On 26 Jun 2020, at 22:00, Klemens Nanni wrote:
>
> Those are global variables are (zero) initialised as such already and
> machine_init() is called only once upon startup.
>
> Feedback? OK?
>
>
> Index: machine.c
> ===
> RCS
> On 26 Jun 2020, at 23:12, Klemens Nanni wrote:
>
> On Fri, Jun 26, 2020 at 11:07:54PM +0300, Vitaliy Makkoveev wrote:
>> What about “pageshift = 0;” at usr.bin/top/machine.c:216 ?
> Could be removed as well but I left it in there intentionally to keep
> this block o
On Fri, Jun 26, 2020 at 09:15:38PM +0200, Martin Pieuchot wrote:
> On 26/06/20(Fri) 17:53, Vitaliy Makkoveev wrote:
> > On Fri, Jun 26, 2020 at 02:29:03PM +0200, Martin Pieuchot wrote:
> > > On 26/06/20(Fri) 12:35, Vitaliy Makkoveev wrote:
> > > > On Fri, Jun 26, 20
if_clone_create() has the races caused by context switch.
cut begin
if_clone_create(const char *name, int rdomain)
{
struct if_clone *ifc;
struct ifnet *ifp;
int unit, ret;
ifc = if_clone_lookup(name, ); /* [1] */
if (ifc == NULL)
Sorry, I found a memory leak. Updated diff below.
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.610
diff -u -p -r1.610 if.c
--- sys/net/if.c22 Jun 2020 09:45:13 - 1.610
+++
On Fri, Jun 26, 2020 at 02:29:03PM +0200, Martin Pieuchot wrote:
> On 26/06/20(Fri) 12:35, Vitaliy Makkoveev wrote:
> > On Fri, Jun 26, 2020 at 10:23:42AM +0200, Martin Pieuchot wrote:
> > > On 25/06/20(Thu) 19:56, Vitaliy Makkoveev wrote:
> > > > Updated diff.
&g
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
On Sat, Jun 27, 2020 at 12:41:29PM +0200, Martin Pieuchot wrote:
> On 27/06/20(Sat) 01:02, Vitaliy Makkoveev wrote:
> > On Fri, Jun 26, 2020 at 09:15:38PM +0200, Martin Pieuchot wrote:
> > > On 26/06/20(Fri) 17:53, Vitaliy Makkoveev wrote:
> > > > On Fri, Jun 26, 20
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
screenshot
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
sosplice(9) should provide EPROTONOSUPPORT error while we are splicing
sockets with different domains but there is not test for this case. Diff
below adds test for the case while we are thying to splice inet and unix
sockets. We can's splice unix sockets so there is no reason to test the
case for
On Tue, Jun 16, 2020 at 03:10:02PM +0200, Martin Pieuchot wrote:
> On 16/06/20(Tue) 06:18, Todd C. Miller wrote:
> > On Tue, 16 Jun 2020 12:48:58 +0200, Martin Pieuchot wrote:
> >
> > > The diff below implements DragonFly's approach of adding a new kind of
> > > filter, EVFILT_EXCEPT, to report
We installing `npppd-users' with uid:gid root:wheel and mode 0600
because it consists sensitive data but mode for npppd.conf is 0640.
npppd.conf can also have radius passwords and nothing requires to allow
it be readable by group. So set it's permissions to 0600.
Index: usr.sbin/npppd/Makefile
On Mon, Jun 22, 2020 at 02:57:53PM +0900, YASUOKA Masahiko wrote:
> The line in etc/mtree/special should be updated as well.
>
> npppd.conf type=file mode=0640 uname=root gname=wheel
>
> other than that, ok yasuoka
Thanks for pointing.
Now pipex(4) session can't be grabbed while going to be destroyed.
So `pppx_ifs' tree can't be broken by NET_LOCK() dances in
pppx_if_destroy() and I guess it's time to remove panic()'s from
pppx(4).
claudio@ pointed in [1] we can avoid two lookups while inserting `pxi'
into `pppx_ifs' so I
While pppac(4) destroy sessions by pipex_iface_fini() or by
pipex_ioctl() with PIPEXSMODE command, some sessions can be linked to
`state_list'. This case is not checked and sessions will never be
unlinked and `state_list' will be broken after session's memory freeing.
Diff below adds session
yasuoka@ privately pointed I was wrong about KASSERT(). I fixed my
diff. These checks are useless and I guess they make understanding
harder so I removed panic() from pppx_if_destoy() too.
Index: sys/net/if_pppx.c
===
RCS file:
> On 23 Jun 2020, at 10:00, Jason A. Donenfeld wrote:
>
> You can crash a system by running something like:
>
>for i in 1 2 3; do while true; do ifconfig bridge0 create& ifconfig
> bridge0 destroy& done& done
>
> This works with every type of interface I've tried. It appears that
>
On Fri, Jun 26, 2020 at 10:23:42AM +0200, Martin Pieuchot wrote:
> On 25/06/20(Thu) 19:56, Vitaliy Makkoveev wrote:
> > Updated diff.
> >
> > OpenBSD uses 16 bit counter for allocate interface indexes. So we can't
> > store index in session and be sure if_get
pppx_if_start() checks `IFF_RUNNING' bit to be sure `pxi' is consistent
but this bit is not cleared on `pxi' destroy. pppx_if_output() checks
`IFF_UP' bit for the same reason but this bit is always set and this
check is useless. pppac_output() checks `IFF_RUNNING' bit but
pppac_start() doesn't.
On Tue, Jun 23, 2020 at 01:00:06AM -0600, Jason A. Donenfeld wrote:
> You can crash a system by running something like:
>
> for i in 1 2 3; do while true; do ifconfig bridge0 create& ifconfig
> bridge0 destroy& done& done
>
> This works with every type of interface I've tried. It appears
> On 10 Jun 2020, at 17:34, Visa Hankala wrote:
>
> A while ago, finishdup() was changed to release fdplock before calling
> closef() to avoid potential lock order problems in the file close path.
> However, the dup* code can still invoke that path with fdplock held
> through FRELE(). That is
> On 8 Jun 2020, at 11:34, Martin Pieuchot wrote:
>
> On 29/05/20(Fri) 13:22, Vitaliy Makkoveev wrote:
>> This time pppx_add_session() has mixed initialisation order. It starts
>> to initialise pipex(4) session, then initialises `ifnet', then links
>> pipe
On Mon, Jun 08, 2020 at 12:49:05PM +0300, Vitaliy Makkoveev wrote:
>
>
> > On 8 Jun 2020, at 11:34, Martin Pieuchot wrote:
> >
> > On 29/05/20(Fri) 13:22, Vitaliy Makkoveev wrote:
> >> This time pppx_add_session() has mixed initialisation order. It starts
&g
ping?
Since 6.7-release npppd(8) uses pppac(4) instead of tun(4) but manual
page still has the reference to tun(4).
Diff below replaced `tun' by `pppac' in npppd(8) man page. Also `pppac'
added to npppd.conf(5).
Index: usr.sbin/npppd/npppd/npppd.8
> On 13 Jun 2020, at 10:04, Jason McIntyre wrote:
>
> On Sat, Jun 13, 2020 at 11:08:52AM +1000, David Gwynne wrote:
>>
>>
>>> On 13 Jun 2020, at 6:47 am, Jason McIntyre wrote:
>>>
>>> On Fri, Jun 12, 2020 at 09:53:33PM +0300, Vitaliy Makko
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
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/
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
---
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
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
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
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
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
> 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
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
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:
> >>
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
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:
>>
101 - 200 of 774 matches
Mail list logo
