getsock() api modification

2015-04-21 Thread Vitaliy Makkoveev
Now fd_getfile() function returns unacquired struct file instance and the typical usage is: struct file *fp; if ((fp = fd_getfile(fpd, fd)) == NULL) return ENOENT; if (/* obtained fp is unacceptable */) return EERROR; FREF(fp);

Re: getsock() api modification

2015-04-30 Thread Vitaliy Makkoveev
On 30 Apr 2015, at 12:49, Martin Pieuchot m...@openbsd.org wrote: Your diff makes sense but sadly it is broken, could you send a diff that can be applied? Index: share/man/man9/file.9 === RCS file:

Re: getsock() api modification

2015-04-30 Thread Vitaliy Makkoveev
Mail.app removes spaces from line start :(

File reference count anomaly research and fixup

2015-05-06 Thread Vitaliy Makkoveev
Struct file has reference count f_count field. When f_count 0 file instance exists, when f_count becomes 0 file instance should be removed. It's simple but some strange magic exists. When file was created by falloc() it has f_count == 2. One additional FREF() call was done inside falloc(). After

dupfdopen() api modification

2015-05-07 Thread Vitaliy Makkoveev
In the not far future fd_getfile() will return the referenced file instance, so dupfdopen() should be modified for the same reasons that getsock() and getvnode(). The modified dupfdopen() receives a thread pointer instead of it's file descriptor table and of it's file descriptor for duplication.

Re: Make sysctl_file more smp friendly

2015-05-08 Thread Vitaliy Makkoveev
Unfortunately, in 2 cases this diff will increase needed variable for non existing files too. This is the fixed version. Index: sys/kern/kern_sysctl.c === RCS file: /cvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.284 diff -u

Re: Make sysctl_file more smp friendly

2015-05-08 Thread Vitaliy Makkoveev
I have questions about sysctl_file(): 1. Looks like sysctl_file() should do the same things for KERN_FILE_BYPID and KERN_FILE_BYUID cases. But pr-ps_textvp (vnode of executable) will be copied for KERN_FILE_BYPID case only. Is this copying missing for KERN_FILE_BYUID? 2. (arg -1) check looks be

Re: [patch] config(8) and KARL usage

2020-02-21 Thread Vitaliy Makkoveev
> On 19 Feb 2020, at 20:51, Martin Pieuchot wrote: > > On 19/02/20(Wed) 14:13, Vitaliy Makkoveev wrote: >> On Wed, Jan 17, 2018 at 11:40:24AM +0100, Martin Pieuchot wrote: >>> Hello Sebastien, >>> >>> On 17/01/18(Wed) 10:19, Sebastien Marie w

Re: [patch] config(8) and KARL usage

2020-02-19 Thread Vitaliy Makkoveev
On Wed, Jan 17, 2018 at 11:40:24AM +0100, Martin Pieuchot wrote: > Hello Sebastien, > > On 17/01/18(Wed) 10:19, Sebastien Marie wrote: > > [...] > > kernel modification is desirable in some cases, at least for disabling > > ulpt(4) when using cups with USB printer. > > Sorry to hijack your

pppx(4): kill useless rwlocks

2020-04-10 Thread Vitaliy Makkoveev
Subj. Index: net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.83 diff -u -p -r1.83 if_pppx.c --- net/if_pppx.c 10 Apr 2020 07:36:52 - 1.83 +++ net/if_pppx.c 10 Apr 2020 11:16:53

Re: pppx(4): kill useless rwlocks

2020-04-11 Thread Vitaliy Makkoveev
Drop this diff please.

pppx(4): kill pppx_ifs_lk

2020-04-11 Thread Vitaliy Makkoveev
It protects nothing. Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.83 diff -u -p -r1.83 if_pppx.c --- sys/net/if_pppx.c 10 Apr 2020 07:36:52 - 1.83 +++ sys/net/if_pppx.c 11 Apr

Re: pppx(4): kill pppx_ifs_lk

2020-04-11 Thread Vitaliy Makkoveev
it’s protects. > On 11 Apr 2020, at 16:59, Vitaliy Makkoveev wrote: > > It protects nothing. > > Index: sys/net/if_pppx.c > === > RCS file: /cvs/src/sys/net/if_pppx.c,v > retrieving revision 1.83 >

Re: pppx(4): prevent concurency with pppx_if_destroy()

2020-04-07 Thread Vitaliy Makkoveev
On Tue, Apr 07, 2020 at 04:43:55PM +0200, Martin Pieuchot wrote: > On 07/04/20(Tue) 17:14, Vitaliy Makkoveev wrote: > > As Claudio Jeker noticed, NET_LOCK() can release KERNEL_LOCK(). pppx(4) > > code has some NET_LOCK() dances which make it unsafe. [...] > > T

Re: pppx(4): kill forgotten splx(9) stuff

2020-04-07 Thread Vitaliy Makkoveev
On Tue, Apr 07, 2020 at 01:51:45PM +0300, Vitaliy Makkoveev wrote: > On Tue, Apr 07, 2020 at 11:54:01AM +0200, Claudio Jeker wrote: > > Unsure about this one here. I would prefer if the panic remained for now > > (mainly because of the XXXSMP NET_UNLOCK() dance just a

Re: pppx(4): prevent concurency with pppx_if_destroy()

2020-04-07 Thread Vitaliy Makkoveev
On Tue, Apr 07, 2020 at 06:38:11PM +0300, Vitaliy Makkoveev wrote: > On Tue, Apr 07, 2020 at 04:43:55PM +0200, Martin Pieuchot wrote: > > On 07/04/20(Tue) 17:14, Vitaliy Makkoveev wrote: > > > As Claudio Jeker noticed, NET_LOCK() can release KERNEL_LOCK(). pppx(4) > >

pppx(4): prevent concurency with pppx_if_destroy()

2020-04-07 Thread Vitaliy Makkoveev
As Claudio Jeker noticed, NET_LOCK() can release KERNEL_LOCK(). pppx(4) code has some NET_LOCK() dances which make it unsafe. Concurent thread can receive CPU and enter to pppx_if_destroy() while we dance with NET_LOCK(). The idea is to deny access to pxi at destruction stage. If pxi_if is removed

Re: pppx(4): prevent concurency with pppx_if_destroy()

2020-04-07 Thread Vitaliy Makkoveev
Forgot to release lock in pppx_del_session() error case... Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.81 diff -u -p -r1.81 if_pppx.c --- sys/net/if_pppx.c 7 Apr 2020 07:11:22 -

pppx(4): kill forgotten splx(9) stuff

2020-04-07 Thread Vitaliy Makkoveev
pppx_if containing tree and per pppx_dev list are protected by rwlock so these splx(9) related dances and commentaries are not actual. Also pxd_svcq protected by NET_LOCK(). Index: sys/net/if_pppx.c === RCS file:

Re: pppx(4): kill forgotten splx(9) stuff

2020-04-07 Thread Vitaliy Makkoveev
On Tue, Apr 07, 2020 at 11:54:01AM +0200, Claudio Jeker wrote: > Unsure about this one here. I would prefer if the panic remained for now > (mainly because of the XXXSMP NET_UNLOCK() dance just above). I wonder if the > order of this could not be modified so that the NET_LOCK is released after >

Re: pppx(4): prevent concurency with pppx_if_destroy()

2020-04-07 Thread Vitaliy Makkoveev
> On 7 Apr 2020, at 17:43, Martin Pieuchot wrote: > > On 07/04/20(Tue) 17:14, Vitaliy Makkoveev wrote: >> As Claudio Jeker noticed, NET_LOCK() can release KERNEL_LOCK(). pppx(4) >> code has some NET_LOCK() dances which make it unsafe. [...] > > The easiest

pipex(4) fix: check session existence before creation

2020-04-06 Thread Vitaliy Makkoveev
Deny to create pipex_session which is already exist. Newly created session will be placed to list head so the caller of pipex_*_lookup_session() will receive wrong session. Index: sys/net/if_pppx.c === RCS file:

Re: pipex(4) fix: check session existence before creation

2020-04-06 Thread Vitaliy Makkoveev
> On 6 Apr 2020, at 17:37, Claudio Jeker wrote: > > On Mon, Apr 06, 2020 at 07:54:20PM +0300, Vitaliy Makkoveev wrote: >> Deny to create pipex_session which is already exist. Newly created >> session will be placed to list head so the caller of >> pipex_*_lookup_s

pppx(4): kill needless check

2020-04-06 Thread Vitaliy Makkoveev
Just quick cleanup. Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.79 diff -u -p -r1.79 if_pppx.c --- sys/net/if_pppx.c 6 Apr 2020 12:31:30 - 1.79 +++ sys/net/if_pppx.c 6 Apr

Re: Simplify NET_LOCK() variations

2020-04-12 Thread Vitaliy Makkoveev
> On 12 Apr 2020, at 16:26, Martin Pieuchot wrote: > > The existing variations of the NET_LOCK() macros are confusing. We're > now all aware of this fact. So let's keep them simple to prevent future > mistakes :) > > The diff below reduces the current set of methods to the following: > >

Experiment with unlocking PF_UNIX sockets

2020-04-19 Thread Vitaliy Makkoveev
Diff below is _not_ for commit. It's just an experiment I wish to share. Socket layer is already protected by solock(). Inet sockets are protected by NET_LOCK() which is grabbed by solock(). All other sockets are still under KERNEL_LOCK(). My suggestion is to implement another lock, identical to

Re: pppx(4): prevent concurency with pppx_if_destroy()

2020-04-08 Thread Vitaliy Makkoveev
On Wed, Apr 08, 2020 at 09:51:45AM +0200, Martin Pieuchot wrote: > On 07/04/20(Tue) 19:58, Vitaliy Makkoveev wrote: > > > > > > > On 7 Apr 2020, at 17:43, Martin Pieuchot wrote: > > > > > > On 07/04/20(Tue) 17:14, Vitaliy Makkoveev wrote: > > >

Re: pppx(4): prevent concurency with pppx_if_destroy()

2020-04-08 Thread Vitaliy Makkoveev
On Wed, Apr 08, 2020 at 11:35:06AM +0200, Martin Pieuchot wrote: > On 08/04/20(Wed) 12:11, Vitaliy Makkoveev wrote: > > On Wed, Apr 08, 2020 at 09:51:45AM +0200, Martin Pieuchot wrote: > > [...] > > As I see (pseudo code): > > [...] > > So, I fixed this issue

ugen(4): wait everyone to finish i/o in ugen_detach()

2020-04-09 Thread Vitaliy Makkoveev
usb_detach_wait() will simply wait usb_detach_wakeup() for 60 sec. So ugen_detach() will continue to destroy device context before threads finish their io. Index: sys/dev/usb/ugen.c === RCS file: /cvs/src/sys/dev/usb/ugen.c,v

pppx(4) remove context switch from pppx_if_find()

2020-04-08 Thread Vitaliy Makkoveev
As mpi@ noticed malloc() with M_WAITOK can cause context switch too. I wish to drop concurency while RBT pppx_ifs is accessed. So, remove malloc() from pppx_if_find(). Looks like original code should do search in the same way, but it didn't. Index: sys/net/if_pppx.c

Re: pipex(4) man page fix

2020-04-02 Thread Vitaliy Makkoveev
On Thu, Apr 02, 2020 at 09:07:23AM +0200, Martin Pieuchot wrote: > On 29/03/20(Sun) 00:16, Vitaliy Makkoveev wrote: > > pipex not used with tun(4) > > It seems an oversight from the addition of the new pppac(4) driver. See > net/if_tun.c commits from January this year. >

Fix pipex(4) pipex_ioctl() access to not owned sessions (kernel crash too)

2020-04-02 Thread Vitaliy Makkoveev
pipex(4) has pipex_ioctl() interface for pipex_session related routines. pipex_ioctl() calls should be done with pipex_iface_contex, so any operations should be done with pipex_sessions owned by passed pipex_iface_contex. pipex_session check ownership is missing within pipex_ioctl() so anybody can

Re: Fix pipex(4) pipex_ioctl() access to not owned sessions (kernel crash too)

2020-04-02 Thread Vitaliy Makkoveev
Sorry, screenshot was from pached kernel. Screenshot from clean kernel included.

Re: Fix pipex(4) pipex_ioctl() access to not owned sessions (kernel crash too)

2020-04-04 Thread Vitaliy Makkoveev
On Sat, Apr 04, 2020 at 06:52:49PM +0200, Martin Pieuchot wrote: > On 02/04/20(Thu) 13:44, Vitaliy Makkoveev wrote: > > This diff add ownership checks to the rest pipex_ioctl() commands. A few > > words about pppx_get_closed(): since in-kernel timeout feature was > > disable

Prevent memory corruption by pipex_timer()

2020-03-27 Thread Vitaliy Makkoveev
Each pipex_session has timeout_sec field and if it is not 0, pipex_timer() can destroy pipex_session. Each pppx_if contents pipex_session. If userland creates pppx_if and pipex_session has timeout (for example, npppd.conf has idle-timeout option), pipex_timer() can destroy this pipex_session and

Re: Prevent memory corruption by pipex_timer()

2020-03-27 Thread Vitaliy Makkoveev
On Fri, Mar 27, 2020 at 03:16:54PM +0300, Vitaliy Makkoveev wrote: > On Fri, Mar 27, 2020 at 10:43:52AM +0100, Martin Pieuchot wrote: > > Do you have a backtrace for the memory corruption? Could you share it? > Yes. Apply path below, compile and run code, and when you had see >

Re: Prevent memory corruption by pipex_timer()

2020-03-27 Thread Vitaliy Makkoveev
On Fri, Mar 27, 2020 at 10:43:52AM +0100, Martin Pieuchot wrote: > Do you have a backtrace for the memory corruption? Could you share it? Yes. Apply path below, compile and run code, and when you had see "pipex_session ... killed" kill this code. Screenshot attached. STABLE-6.[56] are affected

Re: Dedulpicate pipex(4) and pppx(4) code

2020-04-01 Thread Vitaliy Makkoveev
Updated diff. The idea is to use already existing pipex API for pipex_session creation and destruction. pppx_if now holds a reference to pipex_session. Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving

Re: pipex(4) man page fix

2020-04-03 Thread Vitaliy Makkoveev
On Thu, Apr 02, 2020 at 05:06:30PM +0100, Iain R. Learmonth wrote: > Hi, > > On 02/04/2020 12:47, Vitaliy Makkoveev wrote: > > +.Xr pppax 4 , > > I guess you meant pppac here. > > Thanks, > Iain. > Thank

Re: Fix pipex(4) pipex_ioctl() access to not owned sessions (kernel crash too)

2020-04-03 Thread Vitaliy Makkoveev
On Fri, Apr 03, 2020 at 11:07:48AM +0200, Martin Pieuchot wrote: > On 02/04/20(Thu) 13:44, Vitaliy Makkoveev wrote: > > pipex(4) has pipex_ioctl() interface for pipex_session related routines. > > pipex_ioctl() calls should be done with pipex_iface_contex, so any > > oper

Dedulpicate pipex(4) and pppx(4) code

2020-03-28 Thread Vitaliy Makkoveev
pppx(4) has code copypasted from pipex(4). Patch below deduplicates it. Introduded pipex_session_setup() and pipex_session_destroy() functions. Original pipex_destroy_session() renamed to pipex_del_session() to be consistent with PIPEXDSESSION (Delete the specified session from the kernel).

pipex(4) man page fix

2020-03-28 Thread Vitaliy Makkoveev
pipex not used with tun(4) Index: share/man/man4/pipex.4 === RCS file: /cvs/src/share/man/man4/pipex.4,v retrieving revision 1.11 diff -u -p -r1.11 pipex.4 --- share/man/man4/pipex.4 18 Apr 2017 03:21:48 - 1.11 +++

Re: Prevent memory corruption by pipex_timer()

2020-03-27 Thread Vitaliy Makkoveev
On Fri, Mar 27, 2020 at 03:13:01PM +0100, Martin Pieuchot wrote: > On 27/03/20(Fri) 15:16, Vitaliy Makkoveev wrote: > > On Fri, Mar 27, 2020 at 10:43:52AM +0100, Martin Pieuchot wrote: > > > Do you have a backtrace for the memory corruption? Could you share it? > > Yes. A

Re: Prevent memory corruption by pipex_timer()

2020-03-31 Thread Vitaliy Makkoveev
I refactored pppx(4). The idea is to use pipex(4) as it was designed. No one holds pipex_session outside pipex(4) so pipex_timer() calls are safe. Unfortunately, this way gives some performance impact, because we need to call pipex_lookup_by_session_id() in some places. This impact will gone after

Re: Prevent memory corruption by pipex_timer()

2020-03-31 Thread Vitaliy Makkoveev
On Tue, Mar 31, 2020 at 05:23:46PM +0200, Martin Pieuchot wrote: > On 31/03/20(Tue) 16:48, Vitaliy Makkoveev wrote: > > I refactored pppx(4). The idea is to use pipex(4) as it was designed. > > No one holds pipex_session outside pipex(4) so pipex_timer() calls are > > safe. Un

Re: Prevent memory corruption by pipex_timer()

2020-03-31 Thread Vitaliy Makkoveev
On Tue, Mar 31, 2020 at 06:15:46PM +0200, Martin Pieuchot wrote: > On 31/03/20(Tue) 18:58, Vitaliy Makkoveev wrote: > > On Tue, Mar 31, 2020 at 05:23:46PM +0200, Martin Pieuchot wrote: > > > On 31/03/20(Tue) 16:48, Vitaliy Makkoveev wrote: > > > > I refactored pppx(

Re: Dedulpicate pipex(4) and pppx(4) code

2020-03-30 Thread Vitaliy Makkoveev
ping

Re: Dedulpicate pipex(4) and pppx(4) code

2020-04-02 Thread Vitaliy Makkoveev
On Thu, Apr 02, 2020 at 09:26:23AM +0200, Martin Pieuchot wrote: > Hello Vitaliy, > > On 01/04/20(Wed) 12:59, Vitaliy Makkoveev wrote: > > Updated diff. The idea is to use already existing pipex API for > > pipex_session creation and destruction. pppx_if now holds a reference

Re: Add missing #ifdefs to pppx_if_destroy()

2020-03-26 Thread Vitaliy Makkoveev
On Thu, Mar 26, 2020 at 11:56:27AM +0100, Martin Pieuchot wrote: > On 26/03/20(Thu) 13:34, Vitaliy Makkoveev wrote: > > Add missing #ifdefs to pppx_if_destroy() as it done in > > pipex_destroy_session(). Also remove unnecessary cast. > > What's the point of such #ifdef? I u

Add missing #ifdefs to pppx_if_destroy()

2020-03-26 Thread Vitaliy Makkoveev
Add missing #ifdefs to pppx_if_destroy() as it done in pipex_destroy_session(). Also remove unnecessary cast. Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.76 diff -u -p -r1.76 if_pppx.c

Fix pipex crash

2020-03-25 Thread Vitaliy Makkoveev
pipex_destroy_session should be called under NET_LOCK but if it called by this sequence: pppacclose -> pipex_iface_fini -> pipex_iface_stop -> pipex_destroy_session, NET_LOCK is missing and kernel crashes. pipex_iface_stop calls are protected by NET_LOCK, so it should be also protected within

Re: Add missing #ifdefs to pppx_if_destroy()

2020-03-26 Thread Vitaliy Makkoveev
On Thu, Mar 26, 2020 at 01:46:29PM +0100, Martin Pieuchot wrote: > Does the diff below works for you? Are you ok with the direction? Any > comment? Diff works for me, Except you missed switch in the and of pppx_add_session() and pipex_add_session(). Index: sys/net/if_pppx.c

pipex(4) cleanup: use LIST_FOERACH_SAFE() instead of manual rolling

2020-04-06 Thread Vitaliy Makkoveev
Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.111 diff -u -p -r1.111 pipex.c --- sys/net/pipex.c 6 Apr 2020 12:31:30 - 1.111 +++ sys/net/pipex.c 6 Apr 2020 12:58:31 - @@

proc.h: fix comment for proc's cached credentials

2020-04-24 Thread Vitaliy Makkoveev
Per thread cached credentials are accessed only by curproc. Curproc doesn't modify it's 'p_ucred' directly. It allocates new copy, then modyfies newcopy and replaces the old. So 'p_ucred' is owned by curproc. Index: sys/sys/proc.h

Re: [PATCH] pipex(4): rework PPP input

2020-05-19 Thread Vitaliy Makkoveev
Hello Sergey. I am not the developer, but I works in pipex(4) layer too. Also mpi@ wants I did rewiev for your diffs. On Mon, May 04, 2020 at 10:03:40PM +0300, Sergey Ryazanov wrote: > Split checks from frame accepting with header removing in the common > PPP input function. This should fix

Re: [PATCH] ppp(4): use common bpf filter hook

2020-05-19 Thread Vitaliy Makkoveev
I am OK with this diff. Also all pseudo interfaces except switch(4) do the same. On Mon, May 04, 2020 at 10:02:53PM +0300, Sergey Ryazanov wrote: > Use bpf filter hook from the common interface structure. This simplifies > the code by unifying it and prepare ppp(4) for pipex(4) support. > > Ok?

pppx(4): avoid direct usage of pxi owned session.

2020-05-14 Thread Vitaliy Makkoveev
Each `struct pppx_if' holds it's own `pipex_session' and this session is used directly within ifnet's related handlers pppx_if_start() and pppx_if_output(). pppx_if_destroy() at first destroys `pipex_session' and calls if_deatch() which can cause context switch. Hypothetically, pppx_if_start() or

fix pppx(4) with net/ifq.c rev 1.38

2020-05-20 Thread Vitaliy Makkoveev
I got splassert with pppx(4) and net/ifq.c rev 1.38 raised by NET_ASSERT_LOCKED() in netinet/ip_output.c:113 and underlaying routines. net/ifq.c rev 1.38 is not in snapshot yet so you need to checkout and build kernel to reproduce. dmesg begin splassert: ip_output: want 2 have 0

Re: [PATCH] pipex(4): rework PPP input

2020-05-20 Thread Vitaliy Makkoveev
On Wed, May 20, 2020 at 04:08:01AM +0300, Sergey Ryazanov wrote: > 2 Hi Vitaliy, > > On Tue, May 19, 2020 at 12:11 PM Vitaliy Makkoveev > wrote: > > On Mon, May 04, 2020 at 10:03:40PM +0300, Sergey Ryazanov wrote: > > > Split checks from frame accepting with he

Re: [PATCH] pipex(4): rework PPP input

2020-05-23 Thread Vitaliy Makkoveev
> On 23 May 2020, at 13:11, Sergey Ryazanov wrote: > > Hello, > > On Wed, May 20, 2020 at 10:13 PM Vitaliy Makkoveev > wrote: >> On Wed, May 20, 2020 at 04:08:01AM +0300, Sergey Ryazanov wrote: >>> On Tue, May 19, 2020 at 12:11 PM Vitaliy Makkoveev >

Re: fix pppx(4) with net/ifq.c rev 1.38

2020-05-23 Thread Vitaliy Makkoveev
> On 23 May 2020, at 12:54, Martin Pieuchot wrote: > > On 22/05/20(Fri) 13:25, Vitaliy Makkoveev wrote: >> On Fri, May 22, 2020 at 07:57:13AM +1000, David Gwynne wrote: >>> [...] >>> can you try the following diff? >>> >> >> I tested th

Re: fix pppx(4) with net/ifq.c rev 1.38

2020-05-22 Thread Vitaliy Makkoveev
On Fri, May 22, 2020 at 07:57:13AM +1000, David Gwynne wrote: > On Wed, May 20, 2020 at 05:42:35PM +0300, Vitaliy Makkoveev wrote: > > I got splassert with pppx(4) and net/ifq.c rev 1.38 raised by > > NET_ASSERT_LOCKED() in netinet/ip_output.c:113 and underlaying routines. > &g

Re: fix pppx(4) with net/ifq.c rev 1.38

2020-05-21 Thread Vitaliy Makkoveev
After net/ifq.c rev 1.38 was reverted pppac(4) still has this problem. pppac_output() called under NET_LOCK(). pppac_output() calls if_enqueue() which calls ifq_start(). But now ifq_start() can run pppac_input() directly under NET_LOCK() and also is can enqueue work and pppac_input() will be

pipex(4): kill NET_LOCK() in pipex_ioctl()

2020-05-27 Thread Vitaliy Makkoveev
pipex(4) is simultaneously protected by KERNEL_LOCK() and NET_LOCK() and the last is not required. I guess to start remove NET_LOCK(). Diff below drops NET_LOCK() in pipex_ioctl() and underlaying routines. At least this helps to kill unlock/lock mess in pppx_add_session() and pppx_if_destroy().

Re: [RFC] pppd: add pipex(4) L2TP control support

2020-05-26 Thread Vitaliy Makkoveev
> On 26 May 2020, at 11:31, Claudio Jeker wrote: > > [skip] > > Is pppd(8) still using K function declarations? Can we please add new > functions with ANSI declarations instead and convert the rest as well. > Also it looks like something strange is going on with indentation (just > look at

Re: [PATCH] pipex(4): rework PPP input

2020-05-26 Thread Vitaliy Makkoveev
> On 25 May 2020, at 22:04, Sergey Ryazanov wrote: > > Hello Vitaliy, > > On Sat, May 23, 2020 at 3:07 PM Vitaliy Makkoveev > wrote: >>> On 23 May 2020, at 13:11, Sergey Ryazanov wrote: >>> On Wed, May 20, 2020 at 10:13 PM Vitaliy Makkoveev >>&g

Re: pppx(4): avoid direct usage of pxi owned session.

2020-05-24 Thread Vitaliy Makkoveev
Sorry about delay. > On 20 May 2020, at 10:54, Martin Pieuchot wrote: > > On 14/05/20(Thu) 15:53, Vitaliy Makkoveev wrote: >> Each `struct pppx_if' holds it's own `pipex_session' and this session is >> used directly within ifnet's related handlers pppx_if_start() and >&g

pppx(4): kill useless rwlock `pppx_ifs_lk'

2020-05-25 Thread Vitaliy Makkoveev
`pppx_ifs_lk' used to protect `pppx_ifs' tree, But this tree is accessed under KERNL_LOCK() and there is no concurency. Also we don't sleep while holding this lock. So it's useless, kill it for simplification. Index: sys/net/if_pppx.c

pipex(4): document struct members locking

2020-05-25 Thread Vitaliy Makkoveev
This time it's not clean which lock is really required to protect pipex(4) data structures. In fact KERNL_LOCK() and NET_LOCK() are used simultaneously. It's time to document it. Only [k] used do mark mutable members due to NET_LOCK() looks be unnecesary and can be killed in future. Index:

Re: pipex(4): kill NET_LOCK() in pipex_ioctl()

2020-05-28 Thread Vitaliy Makkoveev
On Thu, May 28, 2020 at 12:26:39PM +0200, Martin Pieuchot wrote: > On 27/05/20(Wed) 11:54, Vitaliy Makkoveev wrote: > > pipex(4) is simultaneously protected by KERNEL_LOCK() and NET_LOCK() and > > the last is not required. I guess to start remove NET_LOCK(). Diff below >

unlock PF_UNIX sockets

2020-05-28 Thread Vitaliy Makkoveev
socket(2) layer is already protected by solock(). It grabs NET_LOCK() for inet{,6}(4) sockets, but all other sockets are still under KERNEL_LOCK(). I guess solock is already placed everythere it's required. Also `struct file' is already mp-safe. Diff below introduces rwlock `unp_lock'. It's

Re: pppx(4): prevent access to `pxi' being destroyed

2020-05-28 Thread Vitaliy Makkoveev
On Thu, May 28, 2020 at 12:14:43PM +0200, Martin Pieuchot wrote: > On 26/05/20(Tue) 16:12, Vitaliy Makkoveev wrote: > > `pppx_if' has `pxi_ready' field used to prevent access to incomplete > > `pxi'. But we don't prevent access to `pxi' which we destroy. > > pppx_if_destroy(

pppx(4): rework to be clese to pseudo-interfaces

2020-05-29 Thread Vitaliy Makkoveev
This time pppx_add_session() has mixed initialisation order. It starts to initialise pipex(4) session, then initialises `ifnet', then links pipex(4) session, then continue to initialize `ifnet'. pppx_add_session() can sleep and pppx_if_start() can start to work with unlinked pipex(4) session.

Re: pipex(4): kill NET_LOCK() in pipex_ioctl()

2020-05-29 Thread Vitaliy Makkoveev
On Fri, May 29, 2020 at 09:09:22AM +0200, Martin Pieuchot wrote: > On 28/05/20(Thu) 15:27, Vitaliy Makkoveev wrote: > > On Thu, May 28, 2020 at 12:26:39PM +0200, Martin Pieuchot wrote: > > > On 27/05/20(Wed) 11:54, Vitaliy Makkoveev wrote: > > > > pipex(

Re: unlock PF_UNIX sockets

2020-05-29 Thread Vitaliy Makkoveev
On Fri, May 29, 2020 at 08:48:14AM +0200, Martin Pieuchot wrote: > On 28/05/20(Thu) 14:59, Vitaliy Makkoveev wrote: > > socket(2) layer is already protected by solock(). It grabs NET_LOCK() > > for inet{,6}(4) sockets, but all other sockets are still under > > KERNEL_LOC

Re: fix pppx(4) with net/ifq.c rev 1.38

2020-05-30 Thread Vitaliy Makkoveev
> On 30 May 2020, at 09:40, David Gwynne wrote: > > On Mon, May 25, 2020 at 09:44:22AM +0200, Martin Pieuchot wrote: >> On 23/05/20(Sat) 15:38, Vitaliy Makkoveev wrote: >>>> On 23 May 2020, at 12:54, Martin Pieuchot wrote: >>>> On 22/05/20(Fri) 13:25

pppx(4): prevent access to `pxi' being destroyed

2020-05-26 Thread Vitaliy Makkoveev
`pppx_if' has `pxi_ready' field used to prevent access to incomplete `pxi'. But we don't prevent access to `pxi' which we destroy. pppx_if_destroy() can sleep so we can grab `pxi' which we already destroying by concurrent thread and cause use-after-free issue. I guess to use `pxi_ready' to prevent

Re: [PATCH] pipex(4): rework PPP input

2020-05-26 Thread Vitaliy Makkoveev
> On 27 May 2020, at 01:29, Sergey Ryazanov wrote: > > On Tue, May 26, 2020 at 12:07 PM Vitaliy Makkoveev > wrote: >>> On 25 May 2020, at 22:04, Sergey Ryazanov wrote: >>> On Sat, May 23, 2020 at 3:07 PM Vitaliy Makkoveev >>> wrote: >>>>

Re: Call FRELE() without fdplock in dup*(2)

2020-06-10 Thread Vitaliy Makkoveev
> 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

Re: pppx(4): rework to be clese to pseudo-interfaces

2020-06-08 Thread Vitaliy Makkoveev
> 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

Re: pppx(4): rework to be clese to pseudo-interfaces

2020-06-08 Thread Vitaliy Makkoveev
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

Re: pppx(4): rework to be clese to pseudo-interfaces

2020-06-09 Thread Vitaliy Makkoveev
On Tue, Jun 09, 2020 at 10:42:13AM +0200, Martin Pieuchot wrote: > > > > [skip] > > > > + pxi->pxi_ifcontext.ifnet_this = ifp; > > + pxi->pxi_ifcontext.pipexmode = PIPEX_ENABLED; > > + > > + error = pipex_init_session(session, req, >pxi_ifcontext); > > Can you make pipex_init_session() not

Re: pppx(4): rework to be clese to pseudo-interfaces

2020-06-03 Thread Vitaliy Makkoveev
ping?

npppd(8) man pages fix

2020-06-12 Thread Vitaliy Makkoveev
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

Re: npppd(8) man pages fix

2020-06-13 Thread Vitaliy Makkoveev
> 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

Re: pipex(4): use reference counters for `ifnet'

2020-06-25 Thread Vitaliy Makkoveev
> 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

Re: pipex(4): use reference counters for `ifnet'

2020-06-25 Thread Vitaliy Makkoveev
> 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

Re: [PATCH] net: prevent if_clone_destroy from racing with rest of stack

2020-06-25 Thread Vitaliy Makkoveev
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

pipex(4): use reference counters for `ifnet'

2020-06-24 Thread Vitaliy Makkoveev
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

Re: pipex(4): use reference counters for `ifnet'

2020-06-25 Thread Vitaliy Makkoveev
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

Re: pipex(4): use reference counters for `ifnet'

2020-06-25 Thread Vitaliy Makkoveev
* 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

Re: fix races in if_clone_create()

2020-06-26 Thread Vitaliy Makkoveev
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

Re: top: remove duplicate initialisation

2020-06-26 Thread Vitaliy Makkoveev
> 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

Re: top: remove duplicate initialisation

2020-06-26 Thread Vitaliy Makkoveev
> 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

Re: pipex(4): use reference counters for `ifnet'

2020-06-26 Thread Vitaliy Makkoveev
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

fix races in if_clone_create()

2020-06-26 Thread Vitaliy Makkoveev
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)

Re: fix races in if_clone_create()

2020-06-26 Thread Vitaliy Makkoveev
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 +++

Re: pipex(4): use reference counters for `ifnet'

2020-06-26 Thread Vitaliy Makkoveev
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

Re: fix races in if_clone_create()

2020-06-27 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: pipex(4): use reference counters for `ifnet'

2020-06-27 Thread Vitaliy Makkoveev
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

  1   2   >