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:
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
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
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
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#
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
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
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?
&
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
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
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:
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 -
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
---
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
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.
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
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
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
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
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
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
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
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
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:
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.
>
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
> >
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
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() 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
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
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
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
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
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
On 17/02/21(Wed) 11:56, Martin Pieuchot wrote:
> Diff below adds anon locking to the page daemon. It will become
> necessary to guarantee exclusive access to an anon as soon as the
> KERNEL_LOCK() is removed from the fault handler.
Anyone? This should have been part of the already
Page faults on vnode-backed objects commonly end up calling VOP_READ(9)
or VOP_WRITE(9) to go through the buffer cache. This implies grabbing
an inode lock after any UVM locking.
On the other hand changing the size of a vnode results in entering UVM,
generally via calling uvm_vnp_setsize() with
On 23/02/21(Tue) 00:24, Mark Kettenis wrote:
> > Date: Mon, 22 Feb 2021 10:10:21 +0100
> > From: Martin Pieuchot
> >
> > On 16/02/21(Tue) 11:20, Martin Pieuchot wrote:
> > > Start by moving `pgo_fault' handler outside of uvm_fault_lower().
> > >
> &
Similar refactoring to what has been done for the upper part of the fault
handler, ok?
Index: uvm/uvm_fault.c
===
RCS file: /cvs/src/sys/uvm/uvm_fault.c,v
retrieving revision 1.115
diff -u -p -r1.115 uvm_fault.c
--- uvm/uvm_fault.c
On 16/02/21(Tue) 11:20, Martin Pieuchot wrote:
> Start by moving `pgo_fault' handler outside of uvm_fault_lower().
>
> If a page has a backing object that prefer to handler to fault itself
> the locking will be different, so keep it under KERNEL_LOCK() for the
> moment and make i
Diff below adds anon locking to the page daemon. It will become
necessary to guarantee exclusive access to an anon as soon as the
KERNEL_LOCK() is removed from the fault handler.
Comments? Oks?
Index: uvm/uvm_pdaemon.c
===
RCS
Start by moving `pgo_fault' handler outside of uvm_fault_lower().
If a page has a backing object that prefer to handler to fault itself
the locking will be different, so keep it under KERNEL_LOCK() for the
moment and make it separate from the rest of uvm_fault_lower().
ok?
Index:
On 15/02/21(Mon) 16:58, Visa Hankala wrote:
> On Mon, Feb 15, 2021 at 11:37:45AM +0100, Martin Pieuchot wrote:
> > Diagnostic function rw_enter_diag() should be called before
> > WITNESS_CHECKORDER() to have proper locking/debugging information.
> >
> > In the case
On 15/02/21(Mon) 11:47, Martin Pieuchot wrote:
> Diff below includes non-functional changes:
>
> - Sync comments with NetBSD including locking details.
> - Remove superfluous parenthesis and spaces.
> - Add brackets, even if questionable, to reduce diff with NetBSD
> - Us
Diff below includes non-functional changes:
- Sync comments with NetBSD including locking details.
- Remove superfluous parenthesis and spaces.
- Add brackets, even if questionable, to reduce diff with NetBSD
- Use for (;;) instead of while(1)
- Rename a variable from 'result' into 'error'.
-
Diagnostic function rw_enter_diag() should be called before
WITNESS_CHECKORDER() to have proper locking/debugging information.
In the case of 'locking against myself' it is currently impossible
to know where the lock has been previously acquired. Diff below fixes
that, ok?
Index:
Diff below extends the scope of the SCHED_LOCK() to no longer require
the KERNEL_LOCK() when iterating over `ps_thread'. This is enough to
make progress without having to introduce new mechanism.
ok?
Index: kern/kern_exit.c
===
RCS
On 09/02/21(Tue) 20:35, Marcus Glocker wrote:
> jca@ has recently committed a change to video(4) to allow the same
> process to do multiple opens on the same video device to satisfy
> certain applications, and start to go in to the V4L2 "1.1.4 Multiple
> Opens" specification direction as described
On 02/02/21(Tue) 10:45, Claudio Jeker wrote:
> On Mon, Feb 01, 2021 at 04:25:47PM +0100, Martin Pieuchot wrote:
> > On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> > > Diff below aims to simplify the API to put a thread on a sleep queue and
> > >
On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> Diff below aims to simplify the API to put a thread on a sleep queue and
> reduce it to the following:
>
> sleep_setup();
> /* check condition or release lock */
> sleep_finish();
>
> It is motiv
On 23/01/21(Sat) 12:22, Denis Fondras wrote:
> Le Sat, Jan 09, 2021 at 06:50:50PM +0100, Denis Fondras a écrit :
> > This diff place the user-set source address outside of struct art_root and
> > make
> > the code more readable (to me).
> >
> > Based on a concept by mpi@
Comments below.
> >
On 23/01/21(Sat) 21:59, Vitaliy Makkoveev wrote:
> Hello.
>
> According the code `ifaddr’ struct has `ifa_refcnt’ field. Also it seems `ifa’
> could exist while corresponding `ifp’ was destroyed. Is this true for `rt’
> case? Should `ifa_refcnt' be bumped while you return `ifa’?
What is stored
On 16/01/21(Sat) 16:10, Greg Steuck wrote:
> Marcus Glocker writes:
> > There are a few threads going on related to problems with ugen(4) and
> > uhidev(4) devices on xhci(4). This is related to the issue patrick@
> > already explained; while ehci(4) can save the last data toggle state,
> >
On 02/01/21(Sat) 21:54, Vitaliy Makkoveev wrote:
> This allows us to unlock getppid(2). Also NetBSD, DragonflyBSD and OSX
> do the same.
Seems the way to go, two comments below.
> Index: kern/exec_elf.c
> ===
> RCS file:
Diff below moves `access_type' to the context structure passed down to
the various routines and fix a regression introduced in a previous
refactoring.
`access_type' is overwritten for wired mapping and the value of
`enter_prot' is used instead.
ok?
Index: uvm/uvm_fault.c
On 31/12/20(Thu) 22:35, Mark Kettenis wrote:
> > Date: Wed, 30 Dec 2020 11:19:41 -0300
> > From: Martin Pieuchot
> >
> > Diff below adds some locking to UVM's amap & anon data structures that
> > should be enough to get the upper part of the fault
Diff below adds some locking to UVM's amap & anon data structures that
should be enough to get the upper part of the fault handler out of the
KERNEL_LOCK().
This diff doesn't unlock the fault handler, I'd suggest to do this in a
later step on an arch by arch basis.
This is a port of what exists
On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> Diff below aims to simplify the API to put a thread on a sleep queue and
> reduce it to the following:
>
> sleep_setup();
> /* check condition or release lock */
> sleep_finish();
>
> It is motiv
On 23/12/20(Wed) 18:24, Mark Kettenis wrote:
> Diff below switches the i386 pmap to use the modern km_alloc(9)
> functions and uses IPL_VM for the pmap pool, following the example of
> amd64.
Diff below is the one I sent you last year. It has an "#if notyet"
around the allocation that generates
On 26/12/20(Sat) 18:23, Mark Kettenis wrote:
> [...]
> NetBSD and Solaris both provide SIMPLEQ_* and STAILQ_*. I'm not sure
> removing one in favour of the other is helpful.
It would be helpful to provide both set of macros for some time to ease
the transition/conversion.
Then we can decide if
On 22/12/20(Tue) 23:43, Mark Kettenis wrote:
> > Date: Mon, 21 Dec 2020 16:46:32 -0300
> > From: Martin Pieuchot
> >
> > During a page fault multiples counters are updated. They fall into two
> > categories "fault counters" and "global statistics
On 23/12/20(Wed) 07:18, Visa Hankala wrote:
> This fixes a recent regression in kqueue_scan() where the function can
> mistakenly return EWOULDBLOCK.
>
> Currently, kqueue_scan() does one more scan attempt after a timeout.
> Usually, this gives no new events and the function bails out through
>
On 21/12/20(Mon) 16:45, Visa Hankala wrote:
> There is a slight inconsistency in klist_invalidate(). If the knote is
> already in the event queue and has flag EV_ONESHOT, kqueue_scan() will
> not invoke the newly set f_event. In this case, the kevent(2) system
> call will return the knote's
During a page fault multiples counters are updated. They fall into two
categories "fault counters" and "global statistics" both of which are
currently represented by int-sized fields inside a global: `uvmexp'.
Diff below makes use of the per-CPU counters_inc(9) API to make sure no
update is lost
On 20/12/20(Sun) 20:55, Mark Kettenis wrote:
> > Date: Sat, 19 Dec 2020 18:07:41 -0300
> > From: Martin Pieuchot
> >
> > On 18/12/20(Fri) 08:04, Todd C. Miller wrote:
> > > On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote:
> > >
> > &g
On 18/12/20(Fri) 08:04, Todd C. Miller wrote:
> On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote:
>
> > Anyway, your analysis is right. When a kernel thread wants to use
> > pmap_extract(9) on a userland pmap, it needs to lock pm_apte_mtx to
> > prevent another thread from simultaniously
On 17/12/20(Thu) 23:16, Mark Kettenis wrote:
> > Date: Thu, 17 Dec 2020 18:56:52 -0300
> > From: Martin Pieuchot
> >
> > On 16/12/20(Wed) 22:49, Greg Steuck wrote:
> > > I just hit this while booting an i386-current in vmd. The source tree is
>
On 16/12/20(Wed) 22:49, Greg Steuck wrote:
> I just hit this while booting an i386-current in vmd. The source tree is
> synced to "Remove the assertion in uvm_km_pgremove()."
>
> I enabled WITNESS on top of GENERIC. Naturally, GENERIC-Dec15 snap works.
>
> Anybody else see this so I know it's
On 16/12/20(Wed) 23:23, Claudio Jeker wrote:
> On Wed, Dec 16, 2020 at 04:50:42PM -0300, Martin Pieuchot wrote:
> > [...]
> > Why did we choose to use a variable over NULL? Any technical reason?
>
> The sleep subsytem requires a non-NULL value for ident. Changing this
>
On 16/12/20(Wed) 12:50, Scott Cheloha wrote:
> On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 15 Dec 2020 13:32:22 +0100
> > > From: Claudio Jeker
> > >
> > > On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote:
> > > > Hi,
> > > >
> > > > I'd like to
On 15/12/20(Tue) 17:23, Visa Hankala wrote:
> On Tue, Dec 15, 2020 at 07:46:01AM -0300, Martin Pieuchot wrote:
> > @@ -636,43 +651,59 @@ dopselect(struct proc *p, int nd, fd_set
> > if (sigmask)
> > dosigsuspend(p, *sigmask &~ sigcantmask);
> &
On 15/12/20(Tue) 16:30, Mark Kettenis wrote:
> > Date: Tue, 15 Dec 2020 12:15:30 -0300
> > From: Martin Pieuchot
> >
> > When the first thread of multimedia/mpv exits after having played a video
> > with the "gpu" (default) output, the programs receives a
When the first thread of multimedia/mpv exits after having played a video
with the "gpu" (default) output, the programs receives a SIGSEV when it
tries to execute one of its destructor:
void
_rthread_tls_destructors(pthread_t thread)
{
[...]
for (i = 0; i <
On 11/12/20(Fri) 17:37, Visa Hankala wrote:
> This patch extends struct klist with a callback descriptor and
> an argument. The main purpose of this is to let the kqueue subsystem
> assert when a klist should be locked, and operate the klist lock
> in klist_invalidate().
Lovely!
> Access to a
On 11/12/20(Fri) 19:17, Scott Cheloha wrote:
> Here's another sleep that doesn't need lbolt.
>
> The idea here is to call apm_periodic_check() once a second.
> We can do that without lbolt.
>
> Is there some other address that would be more appropriate for this
> thread to sleep on? It doesn't
On 11/12/20(Fri) 19:07, Scott Cheloha wrote:
> I'd like to remove lbolt from the kernel. I think having it in the
> kernel complicates otherwise simple code.
Decoupling code is IMHO a good thing. I like this move.
> We can start with sdmmc(4).
>
> The goal in sdmmc_io_function_enable() is
On 12/12/20(Sat) 11:29, Visa Hankala wrote:
> On Fri, Dec 11, 2020 at 09:35:59AM -0300, Martin Pieuchot wrote:
> > On 10/12/20(Thu) 09:59, Martin Pieuchot wrote:
> > > All previous kqueue refactoring have been committed, here's a final diff
> > > to modify the internal i
On 08/12/20(Tue) 14:39, Visa Hankala wrote:
> On Mon, Dec 07, 2020 at 03:25:00PM -0300, Martin Pieuchot wrote:
> > Simple diff below to add the rw_lock_held() as well as a read & write
> > version.
> >
> > This allows us to reduce the difference with NetBSD in
On 11/12/20(Fri) 12:52, Mark Kettenis wrote:
> > Date: Thu, 10 Dec 2020 16:13:22 -0600
> > From: Scott Cheloha
> >
> > Hi,
> >
> > We looked at removing the ticks from subr_pool.c a while back but it
> > got shelved. That may or may not have been my fault. I don't
> > remember.
> >
> >
On 10/12/20(Thu) 09:59, Martin Pieuchot wrote:
> All previous kqueue refactoring have been committed, here's a final diff
> to modify the internal implementation of {p,}select(2) to query kqfilter
> handlers instead of poll ones.
>
> {p,}poll(2) are left untouched to ease
On 10/12/20(Thu) 21:40, Alexandre Ratchov wrote:
> On Thu, Dec 10, 2020 at 05:27:16PM +0100, Marcus Glocker wrote:
> > Hi All,
> >
> > I recently started to play around with uvideo(4) and uaudio(4) on my
> > amd64 iMacs. There I quickly noticed regular freezes when streaming
> > USB video or
On 10/12/20(Thu) 18:47, Mark Kettenis wrote:
> [...]
> Sensor drivers that are "good citizens" should probably continue to
> use the sensor thread. Butfor things like asmc(4) that handle a
> largish bundle of sensors, a separate thread would be fine. And I
> suspect that thread could run
On 08/12/20(Tue) 22:55, Jonathan Matthew wrote:
> On Mon, Dec 07, 2020 at 03:15:50PM -0300, Martin Pieuchot wrote:
> > Getting a page from the fault handler might require poking at some
> > swap-related states.
> >
> > These are not in the hot-path of the fault handler
All previous kqueue refactoring have been committed, here's a final diff
to modify the internal implementation of {p,}select(2) to query kqfilter
handlers instead of poll ones.
{p,}poll(2) are left untouched to ease the transition.
Here's what I said in the original mail back in May [0]:
> The
On 08/12/20(Tue) 22:55, Jonathan Matthew wrote:
> On Mon, Dec 07, 2020 at 03:15:50PM -0300, Martin Pieuchot wrote:
> > Getting a page from the fault handler might require poking at some
> > swap-related states.
> >
> > These are not in the hot-path of the fault handler
Diff below aims to simplify the API to put a thread on a sleep queue and
reduce it to the following:
sleep_setup();
/* check condition or release lock */
sleep_finish();
It is motivated by my work to sleep the SCHED_LOCK() but might as well
prevent/fix some bugs.
The
On 08/12/20(Tue) 11:45, Mark Kettenis wrote:
> > Date: Mon, 7 Dec 2020 14:18:41 -0300
> > From: Martin Pieuchot
> [,..]
> > Index: kern/kern_event.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_event.
Diff below rewrites uvm_fault() using a loop.
I added a KERNEL_LOCK/UNLOCK() dance around the part that won't be
unlocked soon to illustrate where this is going.
ok?
Index: uvm/uvm_fault.c
===
RCS file:
Simple diff below to add the rw_lock_held() as well as a read & write
version.
This allows us to reduce the difference with NetBSD in UVM by adding the
following checks:
KASSERT(rw_write_held(amap->am_lock));
ok?
Index: sys/rwlock.h
Getting a page from the fault handler might require poking at some
swap-related states.
These are not in the hot-path of the fault handler so for the moment
just assert that the KERNEL_LOCK() is held or grab it if the function
might be called from an future unlocked path.
ok?
Index:
Diff below adds a per-thread kqueue that will be initialized during the
first select(2) or poll(2) syscall and freed upon exit.
Along with this queue a per-thread serial number is used to check the
integrity of events enqueued during a given syscall. This could also
later be used to perform lazy
On 05/12/20(Sat) 22:34, Jonathan Matthew wrote:
> On Fri, Dec 04, 2020 at 10:03:46AM -0300, Martin Pieuchot wrote:
> > On 04/12/20(Fri) 12:01, Jonathan Matthew wrote:
> > > On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > > > [...]
> &
On 30/11/20(Mon) 17:23, Martin Pieuchot wrote:
> On 30/11/20(Mon) 17:06, Visa Hankala wrote:
> > On Mon, Nov 30, 2020 at 01:28:14PM -0300, Martin Pieuchot wrote:
> > > I plan to commit this in 3 steps, to ease a possible revert:
> > > - kevent(2) refactoring
> &
On 04/12/20(Fri) 12:01, Jonathan Matthew wrote:
> On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > [...]
> > Could you try the diff below that only call smr_barrier() for multi-
> > threaded processes with threads still in the list. I guess this also
&g
On 02/12/20(Wed) 14:22, jungle Boogie wrote:
> Hi All,
>
> Getting this kernel panic on my machine with the latest amd64 snapshot
> (13:13 timestamp)
>
> ddb{1}> bt
> spllower(821b8cb4) at spllower+0x21
> single_thread_check_locked(80002030,0) at
> single_thread_check_locked+0x
On 01/12/20(Tue) 18:23, Mark Kettenis wrote:
> > Date: Tue, 1 Dec 2020 13:18:59 -0300
> > From: Martin Pieuchot
> >
> > On 01/12/20(Tue) 15:18, Mark Kettenis wrote:
> > > > Date: Tue, 1 Dec 2020 11:08:50 -0300
> > > > From: Martin Pieuchot
>
On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > [...]
> > > Did you run a make build with that smr_barrier() in it and checked that it
> > &
On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> [...]
> Did you run a make build with that smr_barrier() in it and checked that it
> does not cause a slow down? I am sceptical, smr_barrier() is a very slow
> construct which introduces large delays and should be avoided whenever
> possible.
I did
On 01/12/20(Tue) 15:18, Mark Kettenis wrote:
> > Date: Tue, 1 Dec 2020 11:08:50 -0300
> > From: Martin Pieuchot
> >
> > As recently pointed out by jmatthew@ these need the lock as well, ok?
>
> No. These pages are "unmanaged" and therefore the
As recently pointed out by jmatthew@ these need the lock as well, ok?
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.137
diff -u -p -r1.137 uvm_km.c
--- uvm/uvm_km.c23 May 2020 06:15:09
On 01/12/20(Tue) 21:47, Jonathan Matthew wrote:
> On Tue, Dec 01, 2020 at 10:31:43AM +0100, Claudio Jeker wrote:
> > On Mon, Nov 30, 2020 at 07:10:47PM -0300, Martin Pieuchot wrote:
> > > Every multi-threaded process keeps a list of threads in `ps_threads'.
> > > This li
201 - 300 of 2703 matches
Mail list logo
