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:
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
> 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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
> >
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_
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
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
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
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)
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
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
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
> 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
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
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
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 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 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
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) 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
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
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:
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
>
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
> &
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).
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 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 -
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
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
---
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 ?
>>
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
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
> >
&
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
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
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
>
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 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:
> >
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
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 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
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
> 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 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 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
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
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
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
---
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/
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
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 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
> >
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
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 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
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 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:
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 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 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,
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
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
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 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 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_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;
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.
> 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
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
> 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()
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
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.
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) 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 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
`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
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,
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
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 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 - 100 of 211 matches
Mail list logo
