On Sun, Sep 24, 2023 at 11:03:54PM +0300, Vitaliy Makkoveev wrote:
> Please test this diff, I have no midi(4) devices.
>
> midi(4) already uses `audio_lock' mutex(9) for filterops, but they are
> still kernel locked. Wipe out old selwakeup API and make them MP safe.
> knote_locked(9) will not
{
- char *cmd_name;
- char cmd_type;
-#define CMDT_CMD 0
-#define CMDT_VAR 1
-#define CMDT_SET 2
-#define CMDT_MDC 3
- int (*cmd_exec)(void);
-};
-
-struct cmd_state {
- char bootdev[BOOTDEVLEN]; /* device */
- char image[MAXPATHLEN - 16]; /* image */
- un
s/sys/kern/kqueue/kqueue-exec.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ regress/sys/kern/kqueue/kqueue-exec.c 14 Aug 2023 14:52:43 -
@@ -0,0 +1,113 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2023 Visa Hankala
+ *
+ * Permission to use, copy, modify, and distribute this soft
FreeBSD and NetBSD have variants of the kqueue(2) system call that
allow setting the close-on-exec flag on the returned file descriptor.
In general, I think it is good that the flag can be set atomically
for new descriptors. However, it seems to me that it is almost surely
a mistake if a kqueue
On Sat, Aug 12, 2023 at 02:40:31PM +0200, Martin Pieuchot wrote:
> So do we want to keep the existing requirement of being able to execute
> a thread on a CPU that has been removed from the scheduler? That's is
> what smr_flush() currently needs. I find it surprising but I can add
> that as a
On Sat, Aug 12, 2023 at 01:29:10PM +0200, Martin Pieuchot wrote:
> On 12/08/23(Sat) 10:57, Visa Hankala wrote:
> > On Fri, Aug 11, 2023 at 09:52:15PM +0200, Martin Pieuchot wrote:
> > > When stopping a machine, with "halt -p" for example, secondary CPUs are
> > &
On Fri, Aug 11, 2023 at 09:52:15PM +0200, Martin Pieuchot wrote:
> When stopping a machine, with "halt -p" for example, secondary CPUs are
> removed from the scheduler before smr_flush() is called. So there's no
> need for the SMR thread to peg itself to such CPUs. This currently
> isn't a
On Wed, Jul 05, 2023 at 09:39:00PM -0500, Scott Cheloha wrote:
> glxclk(4) has been compiled-but-disabled for over six months. It was
> disabled when loongson made the clockintr switch. Nobody has asked me
> to make it an intrclock option for loongson so I assume the mips64 CP0
> interrupt clock
Initialize stack-based mutexed using mtx_init(). This removes the need
of the NOWITNESS kludge and lets the lock checker do its job with these
mutexes.
At the moment, static initialization of locks inside functions does not
work correctly with WITNESS. A lock initializer sets up a struct that
On Thu, May 04, 2023 at 08:07:44PM -0700, Greg Steuck wrote:
> I'm debugging a non-trivial multithreaded unit test in the current
> version of lang/ghc. It runs into some kind of unexpected condition not
> handled well by GHC. I suspect we do something non-standard to cause
> this behavior. These
On Fri, Feb 10, 2023 at 02:56:21PM +, Visa Hankala wrote:
> This makes midi(4) event filter MP-safe.
>
> The logic is similar to audio(4). As knote(9) is safe to use
> at IPL_AUDIO, the deferring through soft interrupts is not needed
> any longer.
>
> In mididetach(), t
This makes midi(4) event filter MP-safe.
The logic is similar to audio(4). As knote(9) is safe to use
at IPL_AUDIO, the deferring through soft interrupts is not needed
any longer.
In mididetach(), the separate selwakeup() calls are covered by
klist_invalidate().
Could someone with actual
This makes log event filter MP-safe.
OK?
Index: kern/subr_log.c
===
RCS file: src/sys/kern/subr_log.c,v
retrieving revision 1.75
diff -u -p -r1.75 subr_log.c
--- kern/subr_log.c 2 Jul 2022 08:50:42 - 1.75
+++
Make knote(9) lock the knote list internally, and add knote_locked(9)
for the typical situation where the list is already locked.
Simplify the kqueue API a bit (and make room for the new function)
by dropping the KNOTE(9) macro. Its value is dubious, not least because
it is common to use proper
On Tue, Jan 31, 2023 at 09:50:26PM +0300, Vitaliy Makkoveev wrote:
> On Tue, Jan 31, 2023 at 06:00:45PM +0000, Visa Hankala wrote:
> > On Tue, Jan 31, 2023 at 12:44:47PM +0300, Vitaliy Makkoveev wrote:
> > > Since we have soalloc() to do common socket initialization, move the
&g
On Mon, Jan 30, 2023 at 08:34:29PM +0300, Vitaliy Makkoveev wrote:
> > On 30 Jan 2023, at 06:39, Visa Hankala wrote:
> >
> > Replace selwakeup() with KNOTE() in tun(4) and tap(4).
> >
> > This patch makes the tun(4) and tap(4) event filters MP-safe.
> >
On Tue, Jan 31, 2023 at 12:44:47PM +0300, Vitaliy Makkoveev wrote:
> Since we have soalloc() to do common socket initialization, move the
> rest within. I mostly need to do this because standalone socket's buffer
> locking require to introduce another klistops data for buffers and there
> is no
Replace selwakeup() with KNOTE() in tun(4) and tap(4).
This patch makes the tun(4) and tap(4) event filters MP-safe.
This is similar to the change that just got committed to pppac(4)
and pppx(4). However, tun(4) and tap(4) can be destroyed abruptly,
so klist_invalidate() has to be kept in
On Thu, Jan 26, 2023 at 09:51:14PM +0300, Vitaliy Makkoveev wrote:
> No reason to keep it, selinfo is just wrapper to klist. netstat(1) and
> libkvm use socket structure, but don't touch
> so_{snd,rcv}.sb_sel.si_note.
OK visa@
> Index: sys/kern/uipc_socket.c
>
On Thu, Jan 26, 2023 at 01:57:56AM +0300, Vitaliy Makkoveev wrote:
> On Wed, Jan 25, 2023 at 10:43:50PM +0300, Vitaliy Makkoveev wrote:
> > visa@, mpi@, I'm asking you to review, because you are involved in the
> > kevent(9) development.
> >
> > Hrvoje, if you want to test this diff, you need to
Do not re-insert the event counter to evcount_list in evcount_percpu().
Otherwise the list becomes corrupt when evcount_percpu() is called
after evcount_init_percpu().
OK?
As an extra, use percpu counters with mips64 clock and ipi interrupts.
Index: kern/subr_evcount.c
On Fri, Nov 18, 2022 at 11:03:06AM -0500, Dave Voutila wrote:
> That fixes booting and the Surface Keyboard is usable, but I'm getting
> spurious faults coming from retpoline out of filt_wseventdetach if I
> detach and reattach the Surface Keyboard multiple times while running
> Xorg.
>
> It's
On Wed, Nov 16, 2022 at 07:00:23AM -0600, Scott Cheloha wrote:
> On Mon, Nov 14, 2022 at 05:19:17PM +0000, Visa Hankala wrote:
> > I think this clockintr_init() should be in cp0_startclock(). This would
> > let other clock drivers do their own adjusting of the hz variables
>
On Sun, Nov 06, 2022 at 07:48:09PM +, Scott Cheloha wrote:
> This patch switches loongson and octeon to clockintr(9).
>
> It has survived several release builds and upgrades from the resulting
> bsd.rd images on my ER-4. The ER-4 doesn't have enough RAM to crunch a
> parallel release build.
On Thu, Nov 10, 2022 at 11:59:02PM +1000, David Gwynne wrote:
> On Thu, Nov 10, 2022 at 09:04:22PM +1000, David Gwynne wrote:
> > On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> > > I know what this is. The barrier at the end of if_idxmap_alloc is
> > > sleeping waiting for cpus
On Wed, Aug 31, 2022 at 04:48:37PM -0400, aisha wrote:
> I've added a patch which adds support for NOTE_{,U,M,N}SECONDS for
> EVFILT_TIMER in the kqueue interface.
It sort of makes sense to add an option to specify timeouts in
sub-millisecond precision. It feels complete overengineering to add
On Thu, Aug 18, 2022 at 02:33:55PM +, Miod Vallat wrote:
> > After about 92 hours, one machine showed cp0_raise_calls=622486 and
> > another 695892. cp0_raise_miss was zero on both of them. On two other
> > machines I had forgotten to allow ddb access from console and could
> > not check the
On Wed, Aug 17, 2022 at 11:42:50AM -0500, Scott Cheloha wrote:
> On Wed, Aug 17, 2022 at 01:30:29PM +0000, Visa Hankala wrote:
> > On Tue, Aug 09, 2022 at 09:54:02AM -0500, Scott Cheloha wrote:
> > > On Tue, Aug 09, 2022 at 02:03:31PM +, Visa Hankala wrote:
> > > &
On Tue, Aug 09, 2022 at 09:54:02AM -0500, Scott Cheloha wrote:
> On Tue, Aug 09, 2022 at 02:03:31PM +0000, Visa Hankala wrote:
> > On Mon, Aug 08, 2022 at 02:52:37AM -0500, Scott Cheloha wrote:
> > > One thing I'm still uncertain about is how glxclk fits into the
> > &
kqueue-based poll(2) and select(2) seem to work fairly well. Because of
this, the ktrace points that display the internal translated events do
not appear very valuable any longer. They clog up and make traces
difficult to read. I think it is time to remove the trace points.
OK?
Index:
Remove unneeded kern.nselcoll sysctl.
The last use of this sysctl in base was removed over two weeks ago.
Debian Code Search does not show any uses of the KERN_NSELCOLL macro.
OK?
Index: lib/libc/sys/sysctl.2
===
RCS file:
On Wed, Aug 10, 2022 at 11:08:06AM +0200, Claudio Jeker wrote:
> On Fri, Jul 01, 2022 at 04:03:21PM +0000, Visa Hankala wrote:
> > On Fri, Jul 01, 2022 at 09:59:11AM +0200, Claudio Jeker wrote:
> > > On Thu, Jun 30, 2022 at 03:46:35PM +, Visa Hankala wrote:
> > > &
On Mon, Aug 08, 2022 at 02:52:37AM -0500, Scott Cheloha wrote:
> One thing I'm still uncertain about is how glxclk fits into the
> loongson picture. It's an interrupt clock that runs hardclock() and
> statclock(), but the code doesn't do any logical masking, so I don't
> know whether or not I
On Sun, Jul 31, 2022 at 01:28:18PM -0500, Scott Cheloha wrote:
> Apparently mips64, i.e. octeon and loongson, has the same problem as
> powerpc/macppc and powerpc64. The timer interrupt is normally only
> logically masked, not physically masked in the hardware, when we're
> running at or above
On Sat, Jul 30, 2022 at 06:40:21PM +1000, Damien Miller wrote:
> On Fri, 29 Jul 2022, Theo de Raadt wrote:
>
> > The question is what _rs_random_u32() will do when it calls
> > _rs_stir_if_needed().
> >
> > There is one potential problem. lib/libcrypto/arc4random/*.h contains
> > portable
On Fri, Jul 29, 2022 at 06:56:08AM -0600, Theo de Raadt wrote:
> Visa Hankala wrote:
>
> > On Thu, Jul 28, 2022 at 11:00:12AM +1000, Damien Miller wrote:
> > > + rs->rs_count = REKEY_BASE;
> > > + /* rekey interval should not be predictable */
> > > + _
On Thu, Jul 28, 2022 at 11:00:12AM +1000, Damien Miller wrote:
> + rs->rs_count = REKEY_BASE;
> + /* rekey interval should not be predictable */
> + _rs_random_u32(_fuzz);
> + rs->rs_count += rekey_fuzz % REKEY_BASE;
The randomization looks good.
However, might it cause a problem
This diff puts more fields of struct vnode under splbio(). splbio()
looks necessary with the fields that are modified through the buffer
cache because the access can happen in an interrupt context.
Wrapping LIST_EMPTY() with splbio() is probably overzealous.
However, the added splbio() calls
Remove the obsolete "select collisions" count from vmstat(8) output.
Also, remove the reference of the now-nonexistent kernel variable
"nselcoll", and terminate the name list with a NULL as required by
kvm_nlist(3).
OK?
Index: vmstat.c
The index of a network interface is assigned in if_idxmap_insert().
ifq_init() and ifiq_init() use if_index before it has its final value.
As a consequence, interfaces tend to use net_tq(0) as their first
softnet task queue even though the other softnet task queues could be
used as well. To fix
On Thu, Jul 14, 2022 at 04:39:33AM +0300, Vitaliy Makkoveev wrote:
> It looks like sometimes the `unp_conn' doesn't reloaded in
> the "unp->unp_conn != unp2" check, and READ_ONCE() should prevent this.
Are you sure about the non-reloading of unp->unp_conn? I did a quick
look in the compiled
Replace selwakeup() with KNOTE() in audio(4).
KNOTE() can be used up to IPL_SCHED. IPL_SCHED is higher than IPL_AUDIO,
so the deferring through soft interrupts is no longer necessary.
In audio_detach(), the selwakeup() calls should not need replacing.
Any remaining kevent/poll/select waiters are
vldcp(4)'s read and write event filters have a discrepancy relative to
the old poll code. They should report non-activeness when the condition
(err == 0 && state == LDC_CHANNEL_UP && head != tail) is false. Now they
can return a stale value, causing a spurious wakeup of
kevent/poll/select. This
Add missing device_unref() calls to vldcpkqfilter().
The knote that vldcpkqfilter() sets up does not take a device reference.
OK?
Index: arch/sparc64/dev/vldcp.c
===
RCS file: src/sys/arch/sparc64/dev/vldcp.c,v
retrieving revision
Replace struct selinfo with direct use of struct klist in bpf, kqueue
and pipes. These subsystems no longer utilize selwakeup().
OK?
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.191
diff
Remove the leftovers of the old poll/select mechanism.
This includes the fields si_seltid and si_flags in struct selinfo.
They should now always be zero because nothing calls selrecord().
selwakeup() becomes a wrapper for KNOTE(). I do not want to change
it further in this patch. This code can be
On Sat, Jul 02, 2022 at 03:23:30PM +1000, Jonathan Gray wrote:
> a few more could be removed?
>
> arch/sh/dev/scif.c:scifpoll(dev_t dev, int events, struct proc *p)
>
> kern/tty_tty.c:cttypoll(dev_t dev, int events, struct proc *p)
> sys/tty.h:int cttypoll(dev_t, int, struct proc *);
On Fri, Jul 01, 2022 at 09:59:11AM +0200, Claudio Jeker wrote:
> On Thu, Jun 30, 2022 at 03:46:35PM +0000, Visa Hankala wrote:
> > On Thu, Jun 30, 2022 at 11:51:52AM +0200, Claudio Jeker wrote:
> > > After discussing this with mpi@ and jmatthew@ we came to the conclusion
Remove unused device poll functions.
This also removes unneeded includes of and
from the kernel. Some includes of are removed as well,
but another cleanup will come related to that header.
After this, most of the remnants of the old poll machinery
can be removed.
OK?
Index:
On Thu, Jun 30, 2022 at 11:51:52AM +0200, Claudio Jeker wrote:
> After discussing this with mpi@ and jmatthew@ we came to the conclusion
> that we need to smr_barrier() before refcnt_finalize() to ensure that no
> other CPU is between the SMR_TAILQ_FOREACH, refcnt_take() and
> smr_read_leave().
Remove the now-unused d_poll field from struct cdevsw.
This diff adjusts the various conf.{c,h} bits. To avoid making this
patch too unwieldy, I leave the removal of the device poll functions
for another patch.
(Compile-)tested on amd64, arm64, armv7, i386, loongson, macppc, octeon,
powerpc64,
Remove some switch(4) leftovers.
OK?
Index: etc/etc.hppa/MAKEDEV.md
===
RCS file: src/etc/etc.hppa/MAKEDEV.md,v
retrieving revision 1.68
diff -u -p -r1.68 MAKEDEV.md
--- etc/etc.hppa/MAKEDEV.md 11 Nov 2021 09:47:33 -
Remove unused VOP_POLL().
The patch cuts cttypoll()'s dependency on VOP_POLL(). cttypoll()
has been called through spec_poll() and is unused. The function
cannot be removed yet as the build expects the symbol.
(Next, remove d_poll from struct cdevsw.)
OK?
Index: share/man/man9/VOP_LOOKUP.9
The kernel can deadlock if it tries to allocate blocks for a quota data
file that is stored in the same filesystem that has the quotas enabled.
This happens because of recursion within the quota subsystem:
sleep_finish(8000225d16c0,1) at sleep_finish+0xfe
On Mon, Jun 20, 2022 at 07:07:14PM +0200, Anton Lindqvist wrote:
> On Mon, Jun 20, 2022 at 02:42:52PM +0000, Visa Hankala wrote:
> > On Sun, Jun 19, 2022 at 03:06:47PM +0200, Anton Lindqvist wrote:
> > > This allows the pluart baud rate to be changed. There's one poten
The taskq, timeout and SMR barrier routines require that the thing
that is being synchronized with is able to make progress. Consequently,
the callers of these routines must not hold locks that can prevent
that progress. The patch below documents this.
OK?
Index: smr_call.9
On Sun, Jun 19, 2022 at 03:06:47PM +0200, Anton Lindqvist wrote:
> This allows the pluart baud rate to be changed. There's one potential
> pitfall with this change as users will have the wrong baud rate in their
> /etc/ttys if not installed after revision 1.11 of dev/ic/pluart.c which
> landed
On Sun, Jun 19, 2022 at 11:05:38AM +0200, Jeremie Courreges-Anglas wrote:
> On Fri, Jun 17 2022, Jeremie Courreges-Anglas wrote:
> > On Thu, Jun 16 2022, Visa Hankala wrote:
> >> nfs_inactive() has a lock order reversal. When it removes the silly
> >> file, it lock
On Wed, Jun 15, 2022 at 07:30:09AM +0200, Anton Lindqvist wrote:
> pluart(4) does not report the correct baudrate for the hardware console
> but instead defaults to 38400. This in turn causes the same baudrate to
> end up in /etc/ttys during installation. Note that this is not a problem
> as of
nfs_inactive() has a lock order reversal. When it removes the silly
file, it locks the directory vnode while it already holds the lock
of the argument file vnode. This clashes for example with name lookups
where directory vnodes are locked before file vnodes.
The reversal can cause a deadlock
On Wed, Jun 08, 2022 at 06:50:18AM +0200, Anton Lindqvist wrote:
> On Sun, May 01, 2022 at 04:17:34PM +0000, Visa Hankala wrote:
> > On Sat, Apr 30, 2022 at 09:40:24AM +0200, Anton Lindqvist wrote:
> > > On Sun, Mar 13, 2022 at 04:17:07PM +0100, Mark Kettenis wrote:
> >
On Mon, Jun 06, 2022 at 06:47:32AM +1000, David Gwynne wrote:
> On Sun, Jun 05, 2022 at 03:57:39PM +0000, Visa Hankala wrote:
> > On Sun, Jun 05, 2022 at 12:27:32PM +0200, Martin Pieuchot wrote:
> > > On 05/06/22(Sun) 05:20, Visa Hankala wrote:
> > > > E
On Sun, Jun 05, 2022 at 12:27:32PM +0200, Martin Pieuchot wrote:
> On 05/06/22(Sun) 05:20, Visa Hankala wrote:
> > Encountered the following panic:
> >
> > panic: kernel diagnostic assertion "(p->p_flag & P_TIMEOUT) == 0" failed:
> > file "/usr
Encountered the following panic:
panic: kernel diagnostic assertion "(p->p_flag & P_TIMEOUT) == 0" failed: file
"/usr/src/sys/kern/kern_synch.c", line 373
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
423109 57118 55 0x3
On Tue, Feb 08, 2022 at 09:12:11AM +, Visa Hankala wrote:
> Now that poll(2) is based on kqueue, the old, non-MP-safe poll backend
> is not used any longer. Event sources can call KNOTE() directly instead
> of selwakeup().
>
> This diff does the KNOTE() conversion for pi
The NFS subsystem is not MP-safe yet. Take this into account
in the NFS server socket upcall by locking the kernel.
This might help with the NFS server hanging that was seen recently
as a result of the now-reverted selwakeup()-to-KNOTE() conversion.
Unfortunately, I have not been able to confirm
Remove unused struct fileops field fo_poll and callbacks.
(After this, VOP_POLL() is next in line for removal.)
OK?
Index: sys/dev/pci/drm/drm_linux.c
===
RCS file: src/sys/dev/pci/drm/drm_linux.c,v
retrieving revision 1.92
diff -u
On Sat, Apr 30, 2022 at 09:40:24AM +0200, Anton Lindqvist wrote:
> On Sun, Mar 13, 2022 at 04:17:07PM +0100, Mark Kettenis wrote:
> > > Date: Fri, 11 Mar 2022 07:53:13 +0100
> > > From: Anton Lindqvist
> > >
> > > On Tue, Mar 08, 2022 at 01:44:47PM +,
-user.c
diff -N regress/sys/kern/kqueue/kqueue-user.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ regress/sys/kern/kqueue/kqueue-user.c 30 Apr 2022 13:33:12 -
@@ -0,0 +1,189 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2022 Visa Hankala
+ *
+ * Permission to use, copy, modify
On Tue, Feb 08, 2022 at 09:12:11AM +, Visa Hankala wrote:
> Now that poll(2) is based on kqueue, the old, non-MP-safe poll backend
> is not used any longer. Event sources can call KNOTE() directly instead
> of selwakeup().
>
> This diff does the KNOTE() conversion for pi
On Thu, Apr 21, 2022 at 11:10:40PM +0200, Mark Kettenis wrote:
> > Date: Thu, 21 Apr 2022 22:17:31 +0200
> > From: Alexander Bluhm
> >
> > On Mon, Apr 18, 2022 at 08:33:06AM +, Visa Hankala wrote:
> > > I think the sanest solution is to add
On Mon, Mar 14, 2022 at 04:14:47PM +, Visa Hankala wrote:
> On Mon, Mar 14, 2022 at 02:01:07AM -0700, Philip Guenther wrote:
> > On Mon, Mar 14, 2022 at 12:47 AM Visa Hankala wrote:
> >
> > > On Sun, Mar 13, 2022 at 06:26:19PM -0700, Philip Guenther wrote:
> >
On Sun, Mar 27, 2022 at 03:36:20PM +0200, Sebastien Marie wrote:
> v_numoutput is a struct member of vnode which is used to keep track the
> number
> of writes in progress.
>
> in several function comments, it is marked as "Manipulates v_numoutput. Must
> be
> called at splbio()".
>
> So I
On Mon, Apr 11, 2022 at 07:14:46PM +0200, Martin Pieuchot wrote:
> Now that poll(2) & select(2) use the kqueue backend under the hood we
> can start retiring the old machinery.
>
> The diff below does not touch driver definitions, however it :
>
> - kills selrecord() & doselwakeup()
>
> - make
Make gpio(4) release the device reference that device_lookup() takes.
OK?
Index: dev/gpio/gpio.c
===
RCS file: src/sys/dev/gpio/gpio.c,v
retrieving revision 1.16
diff -u -p -r1.16 gpio.c
--- dev/gpio/gpio.c 6 Apr 2022 18:59:28
On Thu, Apr 07, 2022 at 07:55:11PM +0200, Alexander Bluhm wrote:
> On Wed, Mar 23, 2022 at 06:13:27PM +0100, Alexander Bluhm wrote:
> > In my opinion tracepoints give insight at minimal cost. It is worth
> > it to have it in GENERIC to make it easy to use.
>
> After release I want to revive the
Linux uses pseudo-attribute __read_mostly to tag variables that are read
frequently but written seldom. These variables are grouped together
at link time. This improves cache usage by reducing false sharing.
__read_mostly has been adopted by FreeBSD, DragonFly BSD and NetBSD.
The former two also
On Sat, Mar 19, 2022 at 12:10:11AM +0100, Alexander Bluhm wrote:
> On Thu, Mar 17, 2022 at 07:25:27AM +0000, Visa Hankala wrote:
> > On Thu, Mar 17, 2022 at 12:42:13AM +0100, Alexander Bluhm wrote:
> > > I would like to use btrace to debug refernce counting. The idea
> >
On Thu, Mar 17, 2022 at 06:16:51PM +0100, Alexander Bluhm wrote:
> On Thu, Mar 17, 2022 at 07:25:27AM +0000, Visa Hankala wrote:
> > On Thu, Mar 17, 2022 at 12:42:13AM +0100, Alexander Bluhm wrote:
> > > I would like to use btrace to debug refernce counting. The idea
> >
Use the refcnt API with struct plimit.
OK?
Index: kern/kern_resource.c
===
RCS file: src/sys/kern/kern_resource.c,v
retrieving revision 1.71
diff -u -p -r1.71 kern_resource.c
--- kern/kern_resource.c8 Feb 2021 10:51:01 -
On Thu, Mar 17, 2022 at 12:42:13AM +0100, Alexander Bluhm wrote:
> I would like to use btrace to debug refernce counting. The idea
> is to a a tracepoint for every type of refcnt we have. When it
> changes, print the actual object, the current counter and the change
> value.
> Do we want that
On Wed, Mar 16, 2022 at 11:09:12PM +0100, Alexander Bluhm wrote:
> On Tue, Mar 15, 2022 at 09:15:34AM +0000, Visa Hankala wrote:
> > However, some DEC Alpha CPUs have their data caches divided into cache
> > banks to improve bandwidth. These cache banks are relatively
> > in
Use the refcnt API with struct ucred.
OK?
Index: nfs/nfs_socket.c
===
RCS file: src/sys/nfs/nfs_socket.c,v
retrieving revision 1.139
diff -u -p -r1.139 nfs_socket.c
--- nfs/nfs_socket.c22 Feb 2022 01:15:02 - 1.139
+++
Use the refcnt API in bpf.
OK?
Index: net/bpf.c
===
RCS file: src/sys/net/bpf.c,v
retrieving revision 1.215
diff -u -p -r1.215 bpf.c
--- net/bpf.c 15 Feb 2022 08:43:50 - 1.215
+++ net/bpf.c 16 Mar 2022 15:42:05 -
@@
Make kqueue use the refcnt API.
OK?
Index: sys/kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.183
diff -u -p -r1.183 kern_event.c
--- sys/kern/kern_event.c 22 Feb 2022 01:15:01 -
On Tue, Mar 15, 2022 at 09:11:30AM +, Visa Hankala wrote:
> This patch adds a function for getting a snapshot of a reference
> counter. This will let code like crcopy() access the value in an
> API-observing way.
Here is a revised version.
Based on input from dlg@, the patch
This removes the data dependency consumer barrier from the atomic_load_*
functions. I think the intent was to keep these functions relaxed in
terms of CPU memory order.
This makes these functions more agreeable in code that assertions may
use, such as the suggested refcnt_read().
Removing the
This patch adds a function for getting a snapshot of a reference
counter. This will let code like crcopy() access the value in an
API-observing way.
OK?
Index: share/man/man9/refcnt_init.9
===
RCS file:
On Mon, Mar 14, 2022 at 02:01:07AM -0700, Philip Guenther wrote:
> On Mon, Mar 14, 2022 at 12:47 AM Visa Hankala wrote:
>
> > On Sun, Mar 13, 2022 at 06:26:19PM -0700, Philip Guenther wrote:
> > > On Sun, Mar 13, 2022 at 10:27 AM Visa Hankala wrote:
> > >
> &g
On Sun, Mar 13, 2022 at 06:26:19PM -0700, Philip Guenther wrote:
> On Sun, Mar 13, 2022 at 10:27 AM Visa Hankala wrote:
>
> > On Sun, Mar 13, 2022 at 04:29:44PM +0100, Mark Kettenis wrote:
> >
> ...
>
> > > Under what circumstances does memory ordering
On Sun, Mar 13, 2022 at 04:29:44PM +0100, Mark Kettenis wrote:
> > Date: Sun, 13 Mar 2022 12:47:13 +
> > From: Visa Hankala
> >
> > This makes the refcnt implementation issue memory barriers when
> > releasing references, splitting memory activity cleanly int
This makes the refcnt implementation issue memory barriers when
releasing references, splitting memory activity cleanly into preceding
and succeeding stages around refcnt 1->0 transition.
I think the while loop could be optimized a little by re-reading
r->r_refs just after sleep_finish(). That
This is a slightly tweaked version of the FRELE() memory barrier patch.
The barriers aim to provide clearer memory access behaviour around the
f_count 1->0 transition. With the barriers, the transition splits the
memory activity into preceding and succeeding stages that do not
overlap.
OK?
On Fri, Mar 11, 2022 at 11:51:31AM +0100, Alexander Bluhm wrote:
> On Fri, Mar 11, 2022 at 05:32:11AM +0000, Visa Hankala wrote:
> > On Thu, Mar 10, 2022 at 07:17:43PM +0100, Alexander Bluhm wrote:
> > > On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> >
On Thu, Mar 10, 2022 at 07:17:43PM +0100, Alexander Bluhm wrote:
> On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> > > Below is a patch that shows how to accomplish release semantics with
> > > the file and refcnt APIs. (The added memory barriers ensure that the
> > > CPU
On Thu, Mar 10, 2022 at 10:45:47AM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:05:54AM +0000, Visa Hankala wrote:
>
> Hello Visa,
>
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
>
> I've used atomi
On Wed, Mar 09, 2022 at 08:45:35PM +0100, Alexander Bluhm wrote:
> On Tue, Mar 08, 2022 at 04:55:56PM +0100, Alexander Bluhm wrote:
> > Once we had the discussion where we need the READ_ONCE() macro. As
> > modern C compiler has much freedom how to access memory, I came to
> > the conclusion that
On Wed, Mar 09, 2022 at 08:40:50AM +0100, Jeremie Courreges-Anglas wrote:
> On Tue, Mar 08 2022, Visa Hankala wrote:
> > This patch adds kernel stack trace saving for riscv64, for the benefit
> > of dt(4) and witness(4).
>
> Nice!
>
> > The unwinder is slow be
This patch adds kernel stack trace saving for riscv64, for the benefit
of dt(4) and witness(4). The unwinder is slow because of the symbol
lookup, but this can be tweaked later.
The limit variable prevents the unwinder from using user-controllable
register values. The limit has to reflect the
On Tue, Mar 08, 2022 at 08:04:36AM +0100, Anton Lindqvist wrote:
> On Mon, Mar 07, 2022 at 07:36:35AM +0000, Visa Hankala wrote:
> > I still think that checking TXFF and using the same code for both
> > SBSA and true PL011 UARTs would be the best choice. This would avoid
> >
1 - 100 of 396 matches
Mail list logo
