wakeup_n() w/o DIAGNOSTIC fix

2021-09-09 Thread Martin Pieuchot
The check to avoid a panic for contented rwlock(9) should be outside of #ifdef DIAGNOSTIC. ok? Index: kern//kern_synch.c === RCS file: /cvs/src/sys/kern/kern_synch.c,v retrieving revision 1.177 diff -u -p -r1.177 kern_synch.c ---

Re: mutex(9): initialize some more mutexes before use?

2021-09-08 Thread Martin Pieuchot
On 07/09/21(Tue) 14:19, Patrick Wildt wrote: > Hi, > > I was playing around a little with the mutex code and found that on > arm64 there some uninitialized mutexes out there. > > I think the arm64 specific one is comparatively easy to solve. We > either initialize the mtx when we initialize the

Re: [please test] amd64: schedule clock interrupts against system clock

2021-09-07 Thread Martin Pieuchot
On 07/09/21(Tue) 21:47, Patrick Wildt wrote: > Am Tue, Sep 07, 2021 at 02:43:22PM +0200 schrieb Patrick Wildt: > > Am Mon, Sep 06, 2021 at 09:43:29PM +0200 schrieb Patrick Wildt: > > > Am Fri, Jul 30, 2021 at 07:55:29PM +0200 schrieb Alexander Bluhm: > > > > On Mon, Jul 26, 2021 at 08:12:39AM

Re: fix iwx(4) firmware loading during resume

2021-09-07 Thread Martin Pieuchot
On 07/09/21(Tue) 18:03, Stefan Sperling wrote: > On Tue, Sep 07, 2021 at 05:16:52PM +0200, Martin Pieuchot wrote: > > On 07/09/21(Tue) 15:48, Stefan Sperling wrote: > > > This patch makes iwx(4) resume reliably for me. > > > > > > There were missing splnet()

Re: fix iwx(4) firmware loading during resume

2021-09-07 Thread Martin Pieuchot
On 07/09/21(Tue) 15:48, Stefan Sperling wrote: > This patch makes iwx(4) resume reliably for me. > > There were missing splnet() calls which leads to an obvious race > between the interrupt handler and the code which triggers firmware > loading and then sleeps to wait for confirmation. > This

Re: Analyse of kernel lock contention

2021-09-07 Thread Martin Pieuchot
On 06/09/21(Mon) 17:30, Martin Pieuchot wrote: > [...] > 3) 2ytHD+make-j17+kqpoll_unlocked_arm64.svg > === This should be: 3) 2ytHD+googlemap_arm64.svg > The intend of this test is to expose where th

Re: Fix: tcp_output window calculation error

2021-09-05 Thread Martin Pieuchot
On 22/07/21(Thu) 15:03, Jan Klemkow wrote: > Hi, > > This calculation of the receive window has a logic error: > > If win is 0 it will be overwritten by (rcv_adv - rcv_nxt). Thus, win > will be (rcv_adv - rcv_nxt) even if its below (sb_hiwat / 4). Why is this a problem? > We could just remove

pmap & buffer cache dummy pagers

2021-09-02 Thread Martin Pieuchot
Diff below introduces two dummy pagers for subsystem that manipulate UVM objects that are 'special'. Those pagers will be used to enforce checks in functions that expect a lock to be held, like: KASSERT(obj == NULL || UVM_OBJ_IS_PMAP(obj) || rw_write_held(obj->vmobjlock));

i386 ioapic mtx not initialized

2021-09-02 Thread Martin Pieuchot
Seen with WITNESS, this has already been fixed in amd64, diff below backport the fix, ok? ioapic0 at mainbus0: apid 2 pa 0xfec0witness: lock_object uninitialized: 0xd8841440 Starting stack trace... witness_checkorder(f5547000,fec01000,fec0,d1820adc,d03fb01e) at witness_checkorder+0x85

Incorrect IPL when pool_get(9) is called under rwlock

2021-09-01 Thread Martin Pieuchot
syzkaller reported [0] the following lock ordering issue: db{0}> trace db_enter() at db_enter+0x18 sys/arch/amd64/amd64/db_interface.c:440 panic(82464b8f) at panic+0x177 sys/kern/subr_prf.c:202 witness_checkorder(82838c20,9,0) at witness_checkorder+0x11eb

Re: systat(1) counter overflow

2021-08-30 Thread Martin Pieuchot
On 13/07/21(Tue) 00:55, Anindya Mukherjee wrote: > On Sat, Jul 03, 2021 at 11:20:42AM +0100, Stuart Henderson wrote: > > On 2021/07/03 01:09, Anindya Mukherjee wrote: > > > Thanks for the discussion. This has been very illuminating. I have been > > > digging > > > around in /usr/src/ and ignoring

Kill SYSCALL_DEBUG

2021-08-30 Thread Martin Pieuchot
Now that dt(4) and btrace(8) are enabled by default and provide a nice and flexible way to debug syscalls on GENERIC kernels should we get rid of the SYSCALL_DEBUG mechanism? Note that the auto-generated kern/syscalls.c providing the `syscallnames' array is still needed to build btrace(8). ok?

Re: ucc(4): consumer control keyboard device driver

2021-08-18 Thread Martin Pieuchot
On 18/08/21(Wed) 17:50, Mark Kettenis wrote: > > Date: Tue, 17 Aug 2021 20:13:41 +0200 > > From: Anton Lindqvist > > > > Hi, > > > > Here's a new driver for USB HID Consumer Control keyboards. Such > > keyboard is a pseudo device which is used to expose audio and > > application launch keys. My

Re: Do not spin on the NET_LOCK() in kqueue

2021-08-02 Thread Martin Pieuchot
On 29/07/21(Thu) 15:36, Alexander Bluhm wrote: > > > New diff fixing a locking dance pointed out by visa@. > > Not tested this one yet. But here is a combination of all the > others. > > http://bluhm.genua.de/perform/results/2021-07-27T07:41:29Z/perform.html Thanks for testing. These tests

Re: Do not spin on the NET_LOCK() in kqueue

2021-07-29 Thread Martin Pieuchot
On 26/07/21(Mon) 09:23, Martin Pieuchot wrote: > On 26/07/21(Mon) 08:55, Martin Pieuchot wrote: > > On 21/07/21(Wed) 10:18, Martin Pieuchot wrote: > > > On 11/07/21(Sun) 14:45, Visa Hankala wrote: > > > > On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote

Re: new kqueue-based select(2) implementation

2021-07-26 Thread Martin Pieuchot
On 21/07/21(Wed) 09:19, Martin Pieuchot wrote: > On 23/06/21(Wed) 15:53, Alexander Bluhm wrote: > > On Wed, Jun 23, 2021 at 11:40:18AM +0200, Martin Pieuchot wrote: > > > Our previous attempt [0] to replace the current select(2) implementation > > > has been reverted du

Re: Do not spin on the NET_LOCK() in kqueue

2021-07-26 Thread Martin Pieuchot
On 26/07/21(Mon) 08:55, Martin Pieuchot wrote: > On 21/07/21(Wed) 10:18, Martin Pieuchot wrote: > > On 11/07/21(Sun) 14:45, Visa Hankala wrote: > > > On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote: > > > > One of the reasons for the drop of pe

Re: Do not spin on the NET_LOCK() in kqueue

2021-07-26 Thread Martin Pieuchot
On 21/07/21(Wed) 10:18, Martin Pieuchot wrote: > On 11/07/21(Sun) 14:45, Visa Hankala wrote: > > On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote: > > > One of the reasons for the drop of performances in the kqueue-based > > > poll/select is the fact tha

Re: Pass "socket *" to sballoc/sbfree & co

2021-07-25 Thread Martin Pieuchot
On 24/07/21(Sat) 11:43, Martin Pieuchot wrote: > Diff below adds an extra argument, a pointer to the socket corresponding > to the buffer given to: sballoc(), sbfree(), sbcompress(), sbcheck() and > sbdroprecord(). > > This pointer will be used to assert for or grab a

Pass "socket *" to sballoc/sbfree & co

2021-07-24 Thread Martin Pieuchot
Diff below adds an extra argument, a pointer to the socket corresponding to the buffer given to: sballoc(), sbfree(), sbcompress(), sbcheck() and sbdroprecord(). This pointer will be used to assert for or grab a per-socket lock. There is no functional change in this diff. Its goal is to

Kill sbinsertoob()

2021-07-24 Thread Martin Pieuchot
This function is unused, killing it means we need fewer refactoring to switch to a per-socket mutex serializing event notifications. ok? Index: kern/uipc_socket2.c === RCS file: /cvs/src/sys/kern/uipc_socket2.c,v retrieving revision

Re: Do not spin on the NET_LOCK() in kqueue

2021-07-21 Thread Martin Pieuchot
On 11/07/21(Sun) 14:45, Visa Hankala wrote: > On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote: > > One of the reasons for the drop of performances in the kqueue-based > > poll/select is the fact that kqueue filters are called up to 3 times > > per syscall a

Re: new kqueue-based select(2) implementation

2021-07-21 Thread Martin Pieuchot
On 23/06/21(Wed) 15:53, Alexander Bluhm wrote: > On Wed, Jun 23, 2021 at 11:40:18AM +0200, Martin Pieuchot wrote: > > Our previous attempt [0] to replace the current select(2) implementation > > has been reverted due to non-acceptable latency increase on sockets [1]. >

Re: forwarding in parallel ipsec workaround

2021-07-21 Thread Martin Pieuchot
On 20/07/21(Tue) 15:46, Alexander Bluhm wrote: > On Tue, Jul 20, 2021 at 02:26:02PM +0200, Alexander Bluhm wrote: > > > Note that having multiple threads competing for an exclusive rwlock will > > > generate unnecessary wakeup/sleep cycles every time the lock is released. > > > It is valuable to

Re: forwarding in parallel ipsec workaround

2021-07-21 Thread Martin Pieuchot
On 20/07/21(Tue) 14:26, Alexander Bluhm wrote: > On Tue, Jul 20, 2021 at 10:08:09AM +0200, Martin Pieuchot wrote: > > On 19/07/21(Mon) 17:53, Alexander Bluhm wrote: > > > Hi, > > > > > > I found why the IPsec workaround did not work. > > > > >

Re: forwarding in parallel ipsec workaround

2021-07-20 Thread Martin Pieuchot
On 19/07/21(Mon) 17:53, Alexander Bluhm wrote: > Hi, > > I found why the IPsec workaround did not work. > > At init time we set ifiq->ifiq_softnet = net_tq(ifp->if_index + > idx), but the workaround modifies net_tq() at runtime. Modifying > net_tq() at runtime is bad anyway as task_add() and

Re: Do not spin on the NET_LOCK() in kqueue

2021-07-10 Thread Martin Pieuchot
On 10/07/21(Sat) 21:53, Vitaliy Makkoveev wrote: > Hi, > > In filt_solisten_common() you touches `so_qlen’ only. It’s not > related to buffer and not protected by introduced `sb_mtx’ so > the solock() replacement in filt_solisten*() is wrong. > > However, in filt_solisten_common() you only

Do not spin on the NET_LOCK() in kqueue

2021-07-10 Thread Martin Pieuchot
One of the reasons for the drop of performances in the kqueue-based poll/select is the fact that kqueue filters are called up to 3 times per syscall and that they all spin on the NET_LOCK() for TCP/UDP packets. Diff below is a RFC for improving the situation. socket kqueue filters mainly check

Re: pthread_cond, futex(2) & ECANCELED

2021-07-10 Thread Martin Pieuchot
On 19/01/20(Sun) 14:44, Martin Pieuchot wrote: > On 18/01/20(Sat) 14:16, Martin Pieuchot wrote: > > When futex(2) got imported it didn't return ECANCELED. This was changed > > later with futex-based semaphores. > > > > This modification introduced a behavior cha

Re: gprof: Profiling a multi-threaded application

2021-07-10 Thread Martin Pieuchot
Hello Yuichiro, thanks for your work ! > On 2021/06/16 16:34, Yuichiro NAITO wrote: > > When I compile a multi-threaded application with '-pg' option, I always get > > no > > results in gmon.out. With bad luck, my application gets SIGSEGV while > > running. > > Because the buffer that holds

Re: Read/Write whole fusebufs

2021-07-09 Thread Martin Pieuchot
On 08/06/21(Tue) 23:32, Helg wrote: > Hello tech@ > > Due to the challenges of having a large diff reviewed I've had another > think about how I can break up the FUSE changes so that they are smaller > and easier to review. > > This is the first of these diffs. > > The current design uses a

Re: more MAKEDEV cleanup

2021-07-09 Thread Martin Pieuchot
On 05/04/21(Mon) 09:25, Miod Vallat wrote: > The following diff attempts to clean up a few loose ends in the current > MAKEDEV files: > > - remove no-longer applicable device definitions (MSCP and SMD disks, > this kind of thing). > - makes sure all platforms use the same `ramdisk' target for >

Re: netlock ktrace nfs

2021-07-04 Thread Martin Pieuchot
On 02/07/21(Fri) 15:01, Alexander Bluhm wrote: > On Fri, Jul 02, 2021 at 01:05:39PM +0200, Martin Pieuchot wrote: > > Looks good to me. Grabbing solock() after calling pledge_socket() in > > sys_connect(), like it is already done in sys_bind(), means it is ok > > to rea

Re: systat(1) counter overflow

2021-07-02 Thread Martin Pieuchot
On 01/07/21(Thu) 13:53, Anindya Mukherjee wrote: > Hi, > > I noticed that if I leave the system running for more than about a month, some > of the counters in the uvm view of systat(1) overflow and become negative. > This > is because the members of struct uvmexp in sys/uvm/uvmexp.h are ints.

Re: netlock ktrace nfs

2021-07-02 Thread Martin Pieuchot
On 01/07/21(Thu) 21:27, Alexander Bluhm wrote: > Hi, > > Writing ktrace files to NFS must no be done while holding the net > lock. accept(2) panics, connect(2) dead locks. Additionally copy > in or out must not hold the net lock as it may be a mmapped file > on NFS. > > - Simplify

Re: crypto kernel lock

2021-06-30 Thread Martin Pieuchot
On 21/06/21(Mon) 23:45, Alexander Bluhm wrote: > On Thu, Jun 17, 2021 at 03:19:11PM +0200, Alexander Bluhm wrote: > > On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote: > > > Could you annotate which field is being protected by the KERNEL_LOCK()? > > > >

Re: uao references & uao_swap_off() cleanup

2021-06-28 Thread Martin Pieuchot
On 23/06/21(Wed) 23:03, Jonathan Matthew wrote: > On Wed, Jun 23, 2021 at 09:37:10AM +0200, Martin Pieuchot wrote: > > On 16/06/21(Wed) 11:26, Martin Pieuchot wrote: > > > Diff below does two things: > > > > > > - Use atomic operations for incrementing/decremen

sparc64: enable dt(4) in GENERIC

2021-06-23 Thread Martin Pieuchot
Similar to what has been done on x86 & arm64, ok? Index: conf/GENERIC === RCS file: /cvs/src/sys/arch/sparc64/conf/GENERIC,v retrieving revision 1.316 diff -u -p -r1.316 GENERIC --- conf/GENERIC4 Feb 2021 16:25:39 -

new kqueue-based select(2) implementation

2021-06-23 Thread Martin Pieuchot
Our previous attempt [0] to replace the current select(2) implementation has been reverted due to non-acceptable latency increase on sockets [1]. This performance regression has been analysed and partially addressed thanks to bluhm@ and visa@. The cost of allocating/freeing 'knote' descriptors

Re: uao references & uao_swap_off() cleanup

2021-06-23 Thread Martin Pieuchot
On 16/06/21(Wed) 11:26, Martin Pieuchot wrote: > Diff below does two things: > > - Use atomic operations for incrementing/decrementing references of > anonymous objects. This allows us to manipulate them without holding > the KERNEL_LOCK(). > > - Rewrite the loop from u

Re: ipsec crypto kernel lock

2021-06-17 Thread Martin Pieuchot
On 16/06/21(Wed) 22:05, Alexander Bluhm wrote: > Hi, > > I have seen a kernel crash with while forwarding and encrypting > much traffic through OpenBSD IPsec gateways running iked. > > kernel: protection fault trap, code=0 > Stopped at aes_ctr_crypt+0x1e: addb$0x1,0x2e3(%rdi) > >

uao references & uao_swap_off() cleanup

2021-06-16 Thread Martin Pieuchot
Diff below does two things: - Use atomic operations for incrementing/decrementing references of anonymous objects. This allows us to manipulate them without holding the KERNEL_LOCK(). - Rewrite the loop from uao_swap_off() to only keep a reference to the next item in the list. This is

Re: ifnewlladdr spl

2021-06-16 Thread Martin Pieuchot
On 16/06/21(Wed) 14:26, David Gwynne wrote: > > > > On 16 Jun 2021, at 00:39, Martin Pieuchot wrote: > > > > On 15/06/21(Tue) 22:52, David Gwynne wrote: > >> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote: > >>>

Re: ifnewlladdr spl

2021-06-15 Thread Martin Pieuchot
On 15/06/21(Tue) 22:52, David Gwynne wrote: > On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote: > > On 10/06/21(Thu) 19:17, Alexander Bluhm wrote: > [...] > > > The in6_ functions need netlock. And driver SIOCSIFFLAGS ioctl > > > must n

Re: kq_lock is required when updating kn_status

2021-06-14 Thread Martin Pieuchot
On 14/06/21(Mon) 13:45, Visa Hankala wrote: > When a knote's kn_status is updated, it is necessary to lock the kqueue > that owns the knote, to ensure proper serialization. filt_proc() has > a mistake in this, and the following diff fixes it. The fix is here to ensure `kn_status' cannot be

Introduce UVM_OBJ_IS_AOBJ()

2021-06-14 Thread Martin Pieuchot
The diff below introduces a new macro to generalize the test currently present in uvm_km_pgremove(). It also uses it in new places to reduce the differences with NetBSD. This helps me shrink upcoming vmobjlock diff. ok? Index: uvm/uvm_aobj.c

Reaper & amaps

2021-06-14 Thread Martin Pieuchot
Now that operations on amaps are serialized using a per-map rwlock the KERNEL_LOCK() shouldn't be necessary to call amap_unref(). The diff below allows the reaper to do this operation before grabbing it. I haven't seen any relevant contention on the reaper in my profilings, so I don't expect any

Re: ifnewlladdr spl

2021-06-14 Thread Martin Pieuchot
On 10/06/21(Thu) 19:17, Alexander Bluhm wrote: > Hi, > > I have seen this crash trace on a 6.6 based system, but I think the > bug exists still in -current. It happened when an ixl(4) interface > was removed from trunk(4). > > uvm_fault(0xfd8739dc6558, 0x0, 0, 1) -> e > fatal page fault in

Kill SS_ASYNC

2021-06-01 Thread Martin Pieuchot
The socket flag SS_ASYNC is redundant with the socket buffer flag SB_ASYNC. Both are set & unset via FIOASYNC. So the diff below gets rid of SS_ASYNC. Checking states on socket buffers will help reduce the scope of the NET_LOCK() when we'll introduce a socket buffer lock. ok? Index:

Re: Add f_modify and f_process callbacks to socket filterops

2021-05-25 Thread Martin Pieuchot
On 20/05/21(Thu) 14:16, Visa Hankala wrote: > On Thu, May 20, 2021 at 11:35:32AM +0200, Martin Pieuchot wrote: > > On 18/05/21(Tue) 14:22, Visa Hankala wrote: > > > This diff adds f_modify and f_process callbacks to socket event filters. > > > As a result, socket event

Re: xhci early enumeration

2021-05-21 Thread Martin Pieuchot
On 21/05/21(Fri) 10:48, Patrick Wildt wrote: > Am Wed, May 19, 2021 at 07:15:50AM + schrieb Christian Ludwig: > > The usb(4) driver allows to enumerate the bus early during boot by > > setting its driver flags to 0x1 in UKC. This mechanism can enable a USB > > console keyboard early during

Re: Add f_modify and f_process callbacks to socket filterops

2021-05-20 Thread Martin Pieuchot
On 18/05/21(Tue) 14:22, Visa Hankala wrote: > This diff adds f_modify and f_process callbacks to socket event filters. > As a result, socket events are handled using the non-legacy paths in > filter_modify() and filter_process() of kern_event.c This a step toward > MP-safety. However, everything

Re: Use atomic op for UVM map refcount

2021-05-20 Thread Martin Pieuchot
On 19/05/21(Wed) 16:17, Mark Kettenis wrote: > > Date: Tue, 18 May 2021 13:24:42 +0200 > > From: Martin Pieuchot > > > > On 18/05/21(Tue) 12:07, Mark Kettenis wrote: > > > > Date: Tue, 18 May 2021 12:02:19 +0200 > > > > From: Martin Pieuc

Re: move copyout() in DIOCGETSTATES outside of NET_LOCK() and state_lcok

2021-05-20 Thread Martin Pieuchot
On 20/05/21(Thu) 03:23, Alexandr Nedvedicky wrote: > Hrvoje gave a try to experimental diff, which trades rw-locks in pf(4) > for mutexes [1]. Hrvoje soon discovered machine panics, when doing 'pfctl -ss' > The callstack looks as follows: > > [...] > specific to experimental diff [1]. However this

Re: Use atomic op for UVM map refcount

2021-05-18 Thread Martin Pieuchot
On 18/05/21(Tue) 12:07, Mark Kettenis wrote: > > Date: Tue, 18 May 2021 12:02:19 +0200 > > From: Martin Pieuchot > > > > This allows us to not rely on the KERNEL_LOCK() to check reference > > counts. > > > > Also reduces differences with NetBSD a

Use atomic op for UVM map refcount

2021-05-18 Thread Martin Pieuchot
This allows us to not rely on the KERNEL_LOCK() to check reference counts. Also reduces differences with NetBSD and shrink my upcoming `vmobjlock' diff. ok? Index: uvm/uvm_map.c === RCS file: /cvs/src/sys/uvm/uvm_map.c,v retrieving

Re: [External] : Re: parallel forwarding vs. bridges

2021-05-17 Thread Martin Pieuchot
On 17/05/21(Mon) 19:52, Alexandr Nedvedicky wrote: > [...] > I don't mind to trade pf_lock and pf_state_lock for mutexes, however > I see such step is kind of 'NO-OP'. We do have sufficient measure > currently, which is: keep NET_LOCK() as is. May be I'm not seeing > your idea/plan behind

Re: parallel forwarding vs. bridges

2021-05-17 Thread Martin Pieuchot
On 17/05/21(Mon) 16:24, Alexandr Nedvedicky wrote: > Hrvoje, > > managed to trigger diagnostic panics with diff [1] sent by bluhm@ > some time ago. The panic Hrvoje sees comes from ether_input() here: > > 414 > 415 /* > 416 * Third phase: bridge processing. > 417 *

uao_dropswap_range()

2021-05-17 Thread Martin Pieuchot
Diff below makes use of uao_dropswap_range() in uao_free() instead of duplicating it. This function has been imported from NetBSD along with TMPFS. I'd like to use it to reduce the difference with their tree and reduce the size of my upcoming `vmobjlock' diff. ok? Index: uvm/uvm_aobj.c

Re: running network stack forwarding in parallel

2021-05-17 Thread Martin Pieuchot
On 16/05/21(Sun) 15:56, Vitaliy Makkoveev wrote: > > > > On 14 May 2021, at 14:43, Martin Pieuchot wrote: > > > > On 13/05/21(Thu) 14:50, Vitaliy Makkoveev wrote: > >> On Thu, May 13, 2021 at 01:15:05PM +0200, Hrvoje Popovski wrote: > >>>

Re: running network stack forwarding in parallel

2021-05-14 Thread Martin Pieuchot
On 13/05/21(Thu) 14:50, Vitaliy Makkoveev wrote: > On Thu, May 13, 2021 at 01:15:05PM +0200, Hrvoje Popovski wrote: > > On 13.5.2021. 1:25, Vitaliy Makkoveev wrote: > > > It seems this lock order issue is not parallel diff specific. > > > > > > > > Yes, you are right ... it seemed familiar but

Re: ld.so: NULL dereference on corrupt library

2021-05-05 Thread Martin Pieuchot
On 04/05/21(Tue) 21:41, Klemens Nanni wrote: > On Thu, Apr 15, 2021 at 03:05:45PM +0200, Mark Kettenis wrote: > > > > [...] > > > > Hence, only access buckets in _dl_find_symbol_obj() if there are any; > > > > this fixes the crash and in fact allows me to play the song even when > > > >

Re: timeout_del_barrier(9): remove kernel lock

2021-05-04 Thread Martin Pieuchot
On 04/05/21(Tue) 01:10, Scott Cheloha wrote: > [...] > I want to run softclock() without the kernel lock. The way to go, I > think, is to first push the kernel lock down into timeout_run(), and > then to remove the kernel lock from each timeout, one by one. Grabbing and releasing the

Re: Stop/unstop process & xsig

2021-04-24 Thread Martin Pieuchot
On 24/04/21(Sat) 12:49, Mark Kettenis wrote: > > Date: Sat, 24 Apr 2021 12:23:17 +0200 > > From: Martin Pieuchot > > > > On 20/03/21(Sat) 13:25, Martin Pieuchot wrote: > > > Diff below refactors routines to stop/unstop processes and save the signal > >

Re: uvm_km_kmemalloc{,_pla}()

2021-04-24 Thread Martin Pieuchot
On 24/04/21(Sat) 12:25, Mark Kettenis wrote: > > Date: Sat, 24 Apr 2021 12:02:22 +0200 > > From: Martin Pieuchot > > > > Diff below merge the two allocators into one and remove unused > > alignment/boundary arguments. This is a small cleanup that helps >

Re: Stop/unstop process & xsig

2021-04-24 Thread Martin Pieuchot
On 20/03/21(Sat) 13:25, Martin Pieuchot wrote: > Diff below refactors routines to stop/unstop processes and save the signal > number which will/can be transmitted it in wait4(2). It does the following: > > - Move the "hack" involving P_SINTR to avoid grabbing the SCHED_

uvm_km_kmemalloc{,_pla}()

2021-04-24 Thread Martin Pieuchot
Diff below merge the two allocators into one and remove unused alignment/boundary arguments. This is a small cleanup that helps me keep track of the remaining allocators. ok? Index: arch/arm/arm/pmap7.c === RCS file:

km_alloc(9) for i386 pmap

2021-04-23 Thread Martin Pieuchot
Diff below convert the last uses of uvm_km_alloc(9) and uvm_km_zalloc(9) to km_alloc(9). One of the allocations below uses `kp_pageable' instead of `kp_zero' because the mapping for `pm_pdir_intel' is lost when PAE is enabled and need to be re-established when a fault happens. This is consistent

Re: dt(4) ifdef sysctl

2021-04-22 Thread Martin Pieuchot
On 22/04/21(Thu) 20:19, Alexander Bluhm wrote: > Hi, > > sysctl witnesswatch gives an error message if the feature is not > compiled into the kernel. I think dt(4) allowdt should do the same. > > sysctl: kern.allowdt: value is not available > > This removes a bit of unused code from ramdisk

Unlock top part of uvm_fault()

2021-04-22 Thread Martin Pieuchot
Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for both amd64 and sparc64. That means the kernel lock will only be taken for lower faults and some amap/anon code will now run without it. I'd be interested to have this tested and see how much does that impact the build time

Re: [External] : Re: running network stack forwarding in parallel

2021-04-22 Thread Martin Pieuchot
On 22/04/21(Thu) 15:08, Mark Kettenis wrote: > > Date: Thu, 22 Apr 2021 14:43:24 +0200 > > From: Alexandr Nedvedicky > > > > Hello, > > > > On Thu, Apr 22, 2021 at 01:09:34PM +0200, Alexander Bluhm wrote: > > > On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote: > > > > r620-1#

tmpfs & UVM aobj

2021-04-22 Thread Martin Pieuchot
uao_shrink() and uao_grow() are only used by TMPFS, ok to place them under an #ifdef? This save some bytes on RAMDISKs. Index: uvm/uvm_aobj.c === RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v retrieving revision 1.94 diff -u -p -r1.94

Re: ld.so: NULL dereference on corrupt library

2021-04-15 Thread Martin Pieuchot
On 14/04/21(Wed) 18:33, Klemens Nanni wrote: > A bogus libvorbisenc.so.3.1 causes ld.so(1) to crash on my Pinebook Pro > which saw a few NVMe/power related panics: > > $ ogg123 song62.ogg > Segmentation fault (core dumped) > > $ egdb -q ogg123 ogg123.core

Re: uvm_page_physload: use km_alloc(9)

2021-04-15 Thread Martin Pieuchot
On 13/04/21(Tue) 02:05, Alexander Bluhm wrote: > On Mon, Mar 22, 2021 at 11:50:00AM +0100, Mark Kettenis wrote: > > > Date: Mon, 22 Mar 2021 11:29:52 +0100 > > > From: Martin Pieuchot > > > > > > Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok? &

Re: [OpenBSD -current] Change event timer in main loop with kqueue

2021-03-30 Thread Martin Pieuchot
On 21/03/21(Sun) 11:27, Visa Hankala wrote: > On Sat, Feb 27, 2021 at 01:36:29PM +, Visa Hankala wrote: > > The kernel does not reschedule the timer when the user changes the > > timeout period. The new period will take effect only after the current > > period has expired. This is not

UAO_USES_SWHASH()

2021-03-29 Thread Martin Pieuchot
Introduce a new macro, UAO_USES_SWHASH() and use it to reduce the diff with NetBSD. Also change some space into tabs for the same reason. ok? Index: uvm/uvm_aobj.c === RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v retrieving revision

UVM return(val)

2021-03-23 Thread Martin Pieuchot
Diff below convert multiple "return(val)" and "return (val)" to "return val". I only changed those that help decrease the size of the diff with NetBSD or didn't change anything. ok? Index: uvm/uvm_amap.c === RCS file:

uvm_page_physload: use km_alloc(9)

2021-03-22 Thread Martin Pieuchot
Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok? Index: uvm/uvm_page.c === RCS file: /cvs/src/sys/uvm/uvm_page.c,v retrieving revision 1.155 diff -u -p -r1.155 uvm_page.c --- uvm/uvm_page.c 19 Jan 2021 13:21:36 -

malloc: use km_alloc(9) for kmemusage

2021-03-22 Thread Martin Pieuchot
Diff below convert a use of uvm_km_zalloc(9) to km_alloc(9), this memory is never released, ok? Index: kern/kern_malloc.c === RCS file: /cvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.144 diff -u -p -r1.144 kern_malloc.c ---

witness: skip first frame when saving stacktraces

2021-03-22 Thread Martin Pieuchot
The top frame is always `witness_checkorder', at least on amd64. Diff below makes use of stacktrace_save_at() to skip it. Previous output: lock order ">lock"(rwlock) -> ">am_lock"(rwlock) first seen at: #0 witness_checkorder+0x4d7 [/home/os/openbsd/sys/sys/stacktrace.h:0] #1

Re: fork(2), PT_ATTACH & SIGTRAP

2021-03-21 Thread Martin Pieuchot
On 21/03/21(Sun) 13:42, Mark Kettenis wrote: > > Date: Sat, 20 Mar 2021 13:10:17 +0100 > > From: Martin Pieuchot > > > > On SP systems, like bluhm@'s armv7 regression machine, the kern/ptrace2 > > test is failing due to a subtle behavior. Diff below makes it pass.

Stop/unstop process & xsig

2021-03-20 Thread Martin Pieuchot
Diff below refactors routines to stop/unstop processes and save the signal number which will/can be transmitted it in wait4(2). It does the following: - Move the "hack" involving P_SINTR to avoid grabbing the SCHED_LOCK() recursively inside proc_stop(). - Introduce proc_unstop(), the

kern_sig.c: use uppercase for defines

2021-03-20 Thread Martin Pieuchot
ok? Index: kern/kern_sig.c === RCS file: /cvs/src/sys/kern/kern_sig.c,v retrieving revision 1.278 diff -u -p -r1.278 kern_sig.c --- kern/kern_sig.c 12 Mar 2021 10:13:28 - 1.278 +++ kern/kern_sig.c 20 Mar 2021

fork(2), PT_ATTACH & SIGTRAP

2021-03-20 Thread Martin Pieuchot
On SP systems, like bluhm@'s armv7 regression machine, the kern/ptrace2 test is failing due to a subtle behavior. Diff below makes it pass. http://bluhm.genua.de/regress/results/2021-03-19T15%3A17%3A02Z/logs/sys/kern/ptrace2/make.log The failing test does a fork(2) and the parent issues a

Re: uvm: sync some comments with NetBSD

2021-03-19 Thread Martin Pieuchot
On 18/03/21(Thu) 16:49, Mark Kettenis wrote: > > Date: Thu, 18 Mar 2021 09:26:14 +0100 > > From: Martin Pieuchot > > > > Diff below only touches comments in sys/uvm. It reverts the commit from > > 2014 that turned three line comments into one line comment

uvm: sync some comments with NetBSD

2021-03-18 Thread Martin Pieuchot
Diff below only touches comments in sys/uvm. It reverts the commit from 2014 that turned three line comments into one line comments and sync some more block with NetBSD -current. This helps reducing the diff with NetBSD. ok? Index: uvm/uvm_addr.c

Re: Read `ps_single' once

2021-03-09 Thread Martin Pieuchot
On 08/03/21(Mon) 12:37, Claudio Jeker wrote: > On Mon, Mar 08, 2021 at 12:11:54PM +0100, Martin Pieuchot wrote: > [...] > > This diff targets a specific problem which is to make sure `ps_single' > > dereferences are coherent if this value is being modified w/o KERNEL_LOCK

Re: Read `ps_single' once

2021-03-08 Thread Martin Pieuchot
On 08/03/21(Mon) 11:57, Claudio Jeker wrote: > On Mon, Mar 08, 2021 at 11:06:44AM +0100, Martin Pieuchot wrote: > > On 05/03/21(Fri) 11:30, Martin Pieuchot wrote: > > > On 04/03/21(Thu) 11:45, Mark Kettenis wrote: > > > > > Date: Thu, 4 Mar 2021 11:19:23 +010

Re: single_thread_clear() w/o KERNEL_LOCK()

2021-03-08 Thread Martin Pieuchot
On 04/03/21(Thu) 10:44, Martin Pieuchot wrote: > single_thread_clear() manipulates the same data structures as > single_thread_set() and, as such, doesn't need the KERNEL_LOCK(). > > However cursig() does need some sort of serialization to ensure that > per-process data structur

Re: Read `ps_single' once

2021-03-08 Thread Martin Pieuchot
On 05/03/21(Fri) 11:30, Martin Pieuchot wrote: > On 04/03/21(Thu) 11:45, Mark Kettenis wrote: > > > Date: Thu, 4 Mar 2021 11:19:23 +0100 > > > From: Martin Pieuchot > > > > > > On 04/03/21(Thu) 11:01, Mark Kettenis wrote: > > > > > Date:

Re: Kill SINGLE_PTRACE

2021-03-05 Thread Martin Pieuchot
On 04/03/21(Thu) 12:25, Claudio Jeker wrote: > On Thu, Mar 04, 2021 at 11:06:21AM +0100, Martin Pieuchot wrote: > > [...] > > The comment documents what sibling threads are supposed to do once the > > current one has called single_thread_set() with a given SINGLE_* option. >

Re: Read `ps_single' once

2021-03-05 Thread Martin Pieuchot
On 04/03/21(Thu) 11:45, Mark Kettenis wrote: > > Date: Thu, 4 Mar 2021 11:19:23 +0100 > > From: Martin Pieuchot > > > > On 04/03/21(Thu) 11:01, Mark Kettenis wrote: > > > > Date: Thu, 4 Mar 2021 10:54:48 +0100 > > > > From: Patrick Wildt > >

Re: Read `ps_single' once

2021-03-04 Thread Martin Pieuchot
On 04/03/21(Thu) 11:01, Mark Kettenis wrote: > > Date: Thu, 4 Mar 2021 10:54:48 +0100 > > From: Patrick Wildt > > > > Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis: > > > > Date: Thu, 4 Mar 2021 10:34:24 +0100 > > > > From: Martin

Re: Kill SINGLE_PTRACE

2021-03-04 Thread Martin Pieuchot
On 04/03/21(Thu) 10:36, Claudio Jeker wrote: > On Thu, Mar 04, 2021 at 10:28:50AM +0100, Martin Pieuchot wrote: > > SINGLE_PTRACE has almost the same semantic as SINGLE_SUSPEND. The > > difference is that there's no need to wait for other threads to be > > parked. > &

single_thread_clear() w/o KERNEL_LOCK()

2021-03-04 Thread Martin Pieuchot
single_thread_clear() manipulates the same data structures as single_thread_set() and, as such, doesn't need the KERNEL_LOCK(). However cursig() does need some sort of serialization to ensure that per-process data structures like signals, flags and traced-signum stay consistent. So the diff

Read `ps_single' once

2021-03-04 Thread Martin Pieuchot
Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can change the value of `ps_single' while one of its siblings might be dereferencing it. To prevent inconsistencies in the code executed by sibling thread, the diff below makes sure `ps_single' is dereferenced only once in various

Kill SINGLE_PTRACE

2021-03-04 Thread Martin Pieuchot
SINGLE_PTRACE has almost the same semantic as SINGLE_SUSPEND. The difference is that there's no need to wait for other threads to be parked. Diff below changes single_thread_set() to be explicit when waiting is required. This allows us to get rid of SINGLE_PTRACE now and soon to use

Re: uvm: modify `uvmexp.swpgonly' atomically

2021-03-03 Thread Martin Pieuchot
On 24/02/21(Wed) 11:33, Martin Pieuchot wrote: > As soon as the upper part of the page fault handler is executed w/o > KERNEL_LOCK(), uvm_anfree_list() will also be executed without it. > > To not corrupt the value of `uvmexp.swpgonly' counter, use atomic > operations to mod

Merge issignal() and CURSIG()

2021-03-02 Thread Martin Pieuchot
t/rw/msleep(9) functions call CURSIG() which needs the KERNEL_LOCK(). To remove this requirement I'd like to start by merging CURSIG() with its underlying function issignal(). The goal of this merge is to avoid accessing shared value like `ps_siglist' multiple times. The diff below moves the

uvm: modify `uvmexp.swpgonly' atomically

2021-02-24 Thread Martin Pieuchot
As soon as the upper part of the page fault handler is executed w/o KERNEL_LOCK(), uvm_anfree_list() will also be executed without it. To not corrupt the value of `uvmexp.swpgonly' counter, use atomic operations to modify it. ok? Index: uvm/uvm_anon.c

  1   2   3   4   5   6   7   8   9   10   >