There's no need to get the `bif' pointer again, we already got it from
the list :)
ok?
diff --git sys/net/if_bridge.c sys/net/if_bridge.c
index 22f67c39dca..838f6d32886 100644
--- sys/net/if_bridge.c
+++ sys/net/if_bridge.c
@@ -770,7 +770,6 @@ bridge_output(struct ifnet *ifp, struct mbuf *m, stru
On 25/02/19(Mon) 14:52, Nils Frohberg wrote:
> Hi,
>
> as mentioned previously, I'm looking into axen(4). While searching
> for the cause of a panic (fixed since, thanks mpi@) I started to
> rewrite parts of the driver. References were mainly the FreeBSD and
> Linux drivers.
Please try to isolate
On 20/03/18(Tue) 18:24, Martin Pieuchot wrote:
> On 26/02/18(Mon) 17:52, Martin Pieuchot wrote:
> > On 20/10/17(Fri) 11:50, Martin Pieuchot wrote:
> > > On 14/10/17(Sat) 22:07, Philip Guenther wrote:
> > > >
> > > > The diff below adds proctre
On 13/03/19(Wed) 00:41, Ulf Brosziewski wrote:
> The standard method of scrolling in X is tailored to mouse wheels and
> proceeds in coarse steps. Wheel events are mapped to button events, and on
> receiving such an event, an application moves the view of its data by some
> fixed distance - usuall
On 24/03/19(Sun) 20:16, Lawrence Teo wrote:
> This diff modifies divert_packet() to increment the divs_errors counter
> on if_get failure so that users will be aware of it via netstat(1).
If if_get(9) fails that means the interface no longer exists. Is it an
error? Or a delayed free? Did we wri
When a bridge is not in RUNNING state packets are simply enqueued on the
interface. But since the introduction of bridge_ifenqueue() they are
accounted as being sent through the bridge. Diff below fixes that by
calling if_enqueue() directly.
ok?
Index: net/if_bridge.c
==
I'm mostly interested in indicating that when we have a valid reference
to an `ifp', obtained via if_get(9), it is safe to dereference if_softc.
ok?
Index: net/if_var.h
===
RCS file: /cvs/src/sys/net/if_var.h,v
retrieving revision 1
Diff below removes the KERNEL_LOCK() from bridge(4)'s output fast-path.
To do so, it redefines the ifp <-> bridge relationship. Currently every
interface in a bridge(4) contains a pointer to that bridge's port. This
relationship is guaranteed to be valid as long as the KERNEL_LOCK() is
held. We
On 21/04/19(Sun) 16:45, Martin Pieuchot wrote:
> Diff below removes the KERNEL_LOCK() from bridge(4)'s output fast-path.
>
> To do so, it redefines the ifp <-> bridge relationship. Currently every
> interface in a bridge(4) contains a pointer to that bridge's p
On 01/05/19(Wed) 16:35, David Gwynne wrote:
> i originally came at this from the other side, where i wanted to run
> kqueue_enqueue and _dequeue without the KERNEL_LOCK, but that implied
> making kqueue_scan use the mutex too, which allowed the syscall to
> become less locked.
>
> it assumes that
On 27/04/19(Sat) 21:55, Nathanael Rensen wrote:
> The diff below speeds up ld.so library intialisation where the dependency
> tree is broad and deep, such as samba's smbd which links over 100 libraries.
>
> See for example https://marc.info/?l=openbsd-misc&m=155007285712913&w=2
>
> See https://ma
On 27/04/19(Sat) 21:45, Nathanael Rensen wrote:
> The diff below speeds up ld.so library loading where the dependency tree
> is broad and deep, such as samba's smbd which links over 100 libraries.
>
> See for example https://marc.info/?l=openbsd-misc&m=155007285712913&w=2
>
> The timings below a
Diff below pushes the KERNEL_LOCK() further down into bridge(4).
With it bridge_enqueue() now only takes the lock for rules. Rules could
easily be protected by a mutex but I wanted to keep this change small.
The list of interface and span interfaces are now using SMR list.
Removing a `bif' from
All the places using KASSERT(9) include and not libkern.h.
Shouldn't we recommend that?
Index: KASSERT.9
===
RCS file: /cvs/src/share/man/man9/KASSERT.9,v
retrieving revision 1.1
diff -u -p -r1.1 KASSERT.9
--- KASSERT.9 19 Apr 201
On 08/05/19(Wed) 17:09, Martin Pieuchot wrote:
> Diff below pushes the KERNEL_LOCK() further down into bridge(4).
>
> With it bridge_enqueue() now only takes the lock for rules. Rules could
> easily be protected by a mutex but I wanted to keep this change small.
>
> The lis
Document which fields are protected by the SCHED_LOCK(), ok?
Index: sys/proc.h
===
RCS file: /cvs/src/sys/sys/proc.h,v
retrieving revision 1.263
diff -u -p -r1.263 proc.h
--- sys/proc.h 6 Jan 2019 12:59:45 - 1.263
+++ sys/p
On 10/05/19(Fri) 10:50, Martin Pieuchot wrote:
> On 08/05/19(Wed) 17:09, Martin Pieuchot wrote:
> > Diff below pushes the KERNEL_LOCK() further down into bridge(4).
> >
> > With it bridge_enqueue() now only takes the lock for rules. Rules could
> > easily be protected
As discussed in the hackroom. If a thread cross the tick boundary at
which schedclock() is executed while spinning do not account for such
time as "being running".
This has two benefits:
- reduce possible contention on the SCHED_LOCK() when many threads are
spinning on the KERNEL_LOCK()
selwakeup() does a filtered wakeup because all threads waiting in
poll(2) or select(2) are blocking on the same wait channel.
The wakeup is currently implemented by first grabbing a reference
to a thread via tfind(). This makes removing the KERNEL_LOCK()
complicated because we need to ensure the
People started complaining that the SCHED_LOCK() is contended. Here's a
first round at reducing its scope.
Diff below introduces a per-process mutex to protect time accounting
fields accessed in tuagg(). tuagg() is principally called in mi_switch()
where the SCHED_LOCK() is currently held. Movi
Hello Amit,
On 15/05/19(Wed) 09:05, Amit Kulkarni wrote:
> Hi,
>
> This effort is heavily based on top of Gregor's and Michal's diffs. Tried to
> incorporate feedback given by different people to them in 2011/2016. Split
> the new code in a ifdef, so people can do a straight comparison, tried v
On 16/05/19(Thu) 00:08, Amit Kulkarni wrote:
> [...]
> > Regarding the choice of deriving quantum from the priority, are you sure
> > the priorities are correct? Should we keep priorities? Or if userland
> > needs priorities shouldn't we convert quantum into priority and not the
> > other way ar
On 21/05/19(Tue) 20:41, Jasper Lievisse Adriaanse wrote:
> Hi,
>
> This appears to have been wrong from the import, the comment explaining why
> rtcdrain() is needed is in rtcstart() in the same file. OK?
I'd rather kill the reference. It will become outdated next time
somebody refactor the code
When support for multiple CPUs has been added to the scheduler, the use
of reched_proc(), which comes on top of 4.4BSD's need_resched(), has been
overlooked.
This function is called when the priority of a thread changes and if its
new priority is higher than the currently running one. The goal is
When a userland program triggers a fault or does a syscall its SP and/or
PC are checked to be sure they are in expected regions. The result of
this check is cached in the "struct proc" such that a lookup isn't
always necessary.
Currently when the cache is outdated the KERNEL_LOCK() is taken befor
On 01/11/19(Fri) 13:12, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Fri, 01 Nov 2019 00:18:35 -0400
> >
> > Theo de Raadt wrote:
> > > In uvm_map_inentry_fix(), two variables in the map are now being read
> > > without a per-map read lock, this was previously protected by the
> > > ker
On 24/10/19(Thu) 13:30, Stuart Henderson wrote:
> On 2019/10/21 04:06, Martin Pieuchot wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
> >
> > Modified files:
> > lib/librthread :
This function is just a wrapper on top of uvm_unmap(), it has its own
file and is called only 3 times in the kernel. Getting rid of it makes
the overall UVM simpler, ok?
Index: sys/conf/files
===
RCS file: /cvs/src/sys/conf/files,v
r
uvm_km_alloc(9) has never been used in amd64's pmap. pool_get(9) is the
thing since its import by mickey@.
ok?
Index: arch/amd64/amd64/pmap.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/pmap.c,v
retrieving revision 1.135
diff -u -p
km_alloc(9) is still not a full replacement for uvm_km_alloc(9). The
latter allows the protections of the allocation to be changed to
PROT_EXEC via uvm_map_protect(9). This is needed at least by the sti(4)
driver.
Diff below changes km_alloc(9) to allow PROT_EXEC in maxprot. With this
it is pos
The last, now reverted change, to uvm_map_inentry() exposes a race that
is reproducible while building lang/go on amd64 which makes uvm_fault()
fail, resulting a in a SIGSEV of at least one of the processes.
In my tests, uvm_fault() always failed due to 2 conditions, see below.
1. when uvm_map_
For profiling purposes, it would be useful to know where assembly
symbols end.
Diff below adds many END() for libkern and locore.s on sparc64.
ok?
Index: arch/sparc64/sparc64/locore.s
===
RCS file: /cvs/src/sys/arch/sparc64/sparc64
On 03/11/19(Sun) 13:12, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > The last, now reverted change, to uvm_map_inentry() exposes a race that
> > is reproducible while building lang/go on amd64 which makes uvm_fault()
> > fail, resulting a in a SIGSEV of at least
Diff below reintroduce the `kv_executable' flag for km_alloc(9) with a
different meaning. Instead of mapping the pages RWX, the flags allows
the caller to change the protection of the mapping to include PROT_EXEC.
This allows sti(4) to be converted to km_alloc(9), without introducing
side-effect
On 05/11/19(Tue) 10:35, Mark Kettenis wrote:
> > Date: Tue, 5 Nov 2019 10:07:36 +0100
> > From: Martin Pieuchot
> >
> > Diff below reintroduce the `kv_executable' flag for km_alloc(9) with a
> > different meaning. Instead of mapping the pages RWX, the flags
Take the safe approach of converting `boolean_t' to `int', `TRUE' to `1'
and `FALSE' to `0'.
This is to reduce the typedef mess that requires pulling MD/MI headers.
Per-arch ddb code will follow, ok?
Index: ddb/db_command.c
===
RCS
ok?
Index: arch/hppa/hppa/db_disasm.c
===
RCS file: /cvs/src/sys/arch/hppa/hppa/db_disasm.c,v
retrieving revision 1.20
diff -u -p -r1.20 db_disasm.c
--- arch/hppa/hppa/db_disasm.c 15 Oct 2014 17:22:56 - 1.20
+++ arch/hppa/hp
ok?
Index: arch/i386/i386/db_disasm.c
===
RCS file: /cvs/src/sys/arch/i386/i386/db_disasm.c,v
retrieving revision 1.21
diff -u -p -r1.21 db_disasm.c
--- arch/i386/i386/db_disasm.c 5 Mar 2017 01:02:48 - 1.21
+++ arch/i386/i3
procter@ recently found that pretty-printing `th0' in ddb(4) was
incorrect. The global variable is a 'struct timehands' but the CTF
section thought it was a 'struct tcphdr'. That's because net/tcp_subr.o
contains a local variable with the same name inside tcp_signature().
So the diff below makes
clang(1) and gcc(1) have two different ways to generate names for
non-global variables declared as static:
$ nm bsd.gcc |grep faultbuf
81daba40 b faultbuf.6183
$ nm bsd.clang |grep faultbuf
81f52f30 b pageflttrap.faultbuf
Diff
On 24/10/19(Thu) 13:30, Stuart Henderson wrote:
> On 2019/10/21 04:06, Martin Pieuchot wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
> >
> > Modified files:
> > lib/librthread :
Ok?
Index: arch/arm64/arm64/db_disasm.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/db_disasm.c,v
retrieving revision 1.1
diff -u -p -r1.1 db_disasm.c
--- arch/arm64/arm64/db_disasm.c17 Dec 2016 23:38:33 - 1.1
+++ arc
ok?
Index: arch/alpha/alpha/db_disasm.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/db_disasm.c,v
retrieving revision 1.23
diff -u -p -r1.23 db_disasm.c
--- arch/alpha/alpha/db_disasm.c27 Apr 2016 11:03:24 - 1.23
+++
When a static variable is defined in a function, clang(1) emits the
following DWARF:
<1><90>: Abbrev Number: 9 (DW_TAG_subprogram)
DW_AT_name: (indirect string, offset: 0x213b): pageflttrap
[...]
<2>: Abbrev Number: 10 (DW_TAG_variable)
DW_AT_name: (indirect str
This type is just another way to write 'vaddr_t' and requires pulling a
ddb-specific MD header for that, can't we just use vaddr_t everywhere?
Diff below does the conversion in sys/kern and sys/ddb, ok?
Index: kern/kern_timeout.c
===
Current UVM code uses comments to explains when a `map' should be locked
or unlocked.
The diff below introduces functions to check those assertions and start
to use them in two safe places. This also has the advantage of self-
documenting the code, so fewer comments.
While here move the definiti
On 08/11/19(Fri) 17:28, Martin Pieuchot wrote:
> Current UVM code uses comments to explains when a `map' should be locked
> or unlocked.
>
> The diff below introduces functions to check those assertions and start
> to use them in two safe places. This also has t
uvm_mapanon() is called in two occasions: mmap(2) and sigaltstack(2).
Both code paths are obviously in process context an can sleep. That
explains why none of them set the UVM_FLAG_TRYLOCK when calling such
function.
The diff below removes support for this flag. This introduces a
difference with
'db_expr_t' is defined as 'long' on all platforms. I'd like to use some
of the ddb interfaces without having to pull all the type & cast mess into
non-DDB code.
Here's an example of getting rid of in MI code
and using 'long' instead of 'db_expr_t'.
ok?
Index: ddb/db_access.c
==
rw_assert_unlocked(9) should check if the current thread is holding
the lock, not if the lock is held by anyone else. The general check
is racy and I cannot think of any safe way to use it.
Diff below is required for the vm_map_asssert_locked() diff I sent
earlier.
Index: kern/kern_rwlock.c
If the kernel successful found a CTF section but a symbol isn't present
in it assume it has no argument. This make ddb(4) print simpler trace
without garbage for symbols in locore:
db_enter() at db_enter+0x10
comintr(80122000) at comintr+0x2af
intr_handler(8000
This convert tsleep(9) calls that wait for a multiple of `hz' in dev/usb.
Ok?
Index: if_athn_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
retrieving revision 1.53
diff -u -p -r1.53 if_athn_usb.c
--- if_athn_usb.c 12
On 11/11/19(Mon) 12:07, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Sun, Nov 10, 2019 at 04:11:55PM +0100, Martin Pieuchot wrote:
> > rw_assert_unlocked(9) should check if the current thread is holding
> > the lock, not if the lock is held by anyone else. The general
On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> [...]
> The first test I made was on a beefy virtual machine under Hyper-V,
> with 32 vCPUs on a Threadripper 2950X. With and without this patch (and
> the followup for share/mk), I did make -j32 -C /usr/src/usr.bin. The
> results were very disappoi
On 15/11/19(Fri) 15:03, Lauri Tirkkonen wrote:
> On Thu, Nov 14 2019 17:57:20 +0100, Martin Pieuchot wrote:
> > On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> > > [...]
> > > The first test I made was on a beefy virtual machine under Hyper-V,
> > > with 32
As pointed out by sashan@ in a previous diff, unify all checks to have
the same idiom.
Ok?
Index: kern/kern_rwlock.c
===
RCS file: /cvs/src/sys/kern/kern_rwlock.c,v
retrieving revision 1.42
diff -u -p -r1.42 kern_rwlock.c
--- kern/ke
Convert infinite tsleep(9) to tsleep_nsec(9) in sys/dev/usb, ok?
Index: if_wi_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_wi_usb.c,v
retrieving revision 1.70
diff -u -p -r1.70 if_wi_usb.c
--- if_wi_usb.c 12 Nov 2019 07:47:30 -
Convert tsleep(9) -> tsleep_nsec(9) for infinite sleeps in sys/ufs, ok?
Index: ufs/ffs/ffs_softdep.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.144
diff -u -p -r1.144 ffs_softdep.c
--- ufs/ffs/ffs_softdep
Two fixes to reduce difference with other BSDs and make NetBSD's
t_ptrace.c regress pass:
- Return EBUSY when calling PT_TRACE_ME more than once, both FreeBSD and
NetBSD do that.
- Return EPERM instead of EINVAL when trying to trace a parent, this is
what NetBSD does. Alternatively I could k
On 20/11/19(Wed) 22:24, Alexander Bluhm wrote:
> Hi,
>
> Quite often I see "panic: unmount: dangling vnode". My test
> regress/sys/kern/mount triggers it, but it also happens when rebooting
> virtual machines.
>
> The problem is, when dirty buffers are flushed to disk, the unmount
> process slee
On 28/11/19(Thu) 16:49, nayden wrote:
> Hello,
>
> A mostly mechanical diff that makes use of __func__ in place of hardcoded
> function names in panic() and printf() calls.
>
> If someone is working in netinet6 and this change will trample
> your work please let me know and I'll hold off.
>
> ok
For archive, here's the diff on top of -current.
diff --git sys/kern/exec_elf.c sys/kern/exec_elf.c
index 24adf0dbed6..ccbbc6eb3a9 100644
--- sys/kern/exec_elf.c
+++ sys/kern/exec_elf.c
@@ -1217,12 +1217,14 @@ coredump_notes_elf(struct proc *p, void *iocookie,
size_t *sizep)
cpi.c
On 08/11/19(Fri) 17:54, Martin Pieuchot wrote:
> uvm_mapanon() is called in two occasions: mmap(2) and sigaltstack(2).
> Both code paths are obviously in process context an can sleep. That
> explains why none of them set the UVM_FLAG_TRYLOCK when calling such
> function.
>
&
Convert all of them to tsleep_nsec(9), ok?
Index: nfs/nfs_aiod.c
===
RCS file: /cvs/src/sys/nfs/nfs_aiod.c,v
retrieving revision 1.7
diff -u -p -r1.7 nfs_aiod.c
--- nfs/nfs_aiod.c 28 Aug 2015 00:03:54 - 1.7
+++ nfs/nfs_a
Convert them to msleep_nsec(9) and tsleep_nsec(9), ok?
Index: scsi/scsi_base.c
===
RCS file: /cvs/src/sys/scsi/scsi_base.c,v
retrieving revision 1.250
diff -u -p -r1.250 scsi_base.c
--- scsi/scsi_base.c1 Dec 2019 16:56:26 -
Ok?
Index: miscfs/deadfs/dead_vnops.c
===
RCS file: /cvs/src/sys/miscfs/deadfs/dead_vnops.c,v
retrieving revision 1.30
diff -u -p -r1.30 dead_vnops.c
--- miscfs/deadfs/dead_vnops.c 19 Oct 2019 06:56:18 - 1.30
+++ miscfs/dead
Similar to recent ddb(4) changes, replace boolean_t/TRUE/FALSE by
int/1/0.
ok?
Index: arch/amd64/amd64/pmap.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/pmap.c,v
retrieving revision 1.136
diff -u -p -r1.136 pmap.c
--- arch/amd64/amd
Less is more. Fewer files to look at, simpler it becomes to understand
UVM. uvm/uvm_stat.c contains just a ddb(4) function. Let's move it to
uvm/uvm_meter.c which also deals with counters. ok?
Index: conf/files
===
RCS file: /cvs/s
Convert them to tsleep_nsec(9), ok?
Index: kern/vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.193
diff -u -p -r1.193 vfs_bio.c
--- kern/vfs_bio.c 29 Nov 2019 01:04:08 - 1.193
+++ kern/vfs_b
Convert them to {m,t}sleep_nsec(9), ok?
Index: uvm/uvm_device.c
===
RCS file: /cvs/src/sys/uvm/uvm_device.c,v
retrieving revision 1.56
diff -u -p -r1.56 uvm_device.c
--- uvm/uvm_device.c18 Jul 2019 23:47:33 - 1.56
+++ uvm
ok?
Index: i386/pmap.c
===
RCS file: /cvs/src/sys/arch/i386/i386/pmap.c,v
retrieving revision 1.204
diff -u -p -r1.204 pmap.c
--- i386/pmap.c 18 Jan 2019 01:34:50 - 1.204
+++ i386/pmap.c 5 Dec 2019 11:23:20 -
@@ -403,7 +4
Diff below split uvm(9) into the following:
- uvm_init(9)
- uvm_fault(9)
- uvm_km_alloc(9)
- uvm_map(9)
- uvm_pagealloc(9)
- uvn_attach(9)
That will allow us to work on smaller pages and improve the overall
documentation of UVM.
This split doesn't include changes.
Ok?
Index: Makefile
=
On 05/12/19(Thu) 11:57, Otto Moerbeek wrote:
> On Thu, Dec 05, 2019 at 12:38:34PM +0100, Martin Pieuchot wrote:
>
> > ok?
>
> I'm no kernel hacker but I really do not see the point.
Most of the kernel doesn't use any type for boolean. The exception is
UVM which u
Sync with reality, will help KERN_PROC_VMMAP consumers. Ok?
Index: sys/sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.196
diff -u -p -r1.196 sysctl.h
--- sys/sysctl.h22 Oct 2019 21:19:22 - 1
Following cleanup diff:
- reduces gratuitous differences with NetBSD,
- merges multiple '#ifdef _KERNEL' blocks,
- kills unused 'struct vm_map_intrsafe'
- turns 'union vm_map_object' into a anonymous union (following to NetBSD)
- move questionable vm_map_modflags() into uvm/uvm_map.c
- remove guar
Convert the remaining ones to {m,t}sleep_nsec(9), ok?
Index: kern/kern_bufq.c
===
RCS file: /cvs/src/sys/kern/kern_bufq.c,v
retrieving revision 1.32
diff -u -p -r1.32 kern_bufq.c
--- kern/kern_bufq.c16 Aug 2017 17:52:17 -
On 19/12/19(Thu) 18:37, Stuart Henderson wrote:
> While it's nice to have basic support in the kernel, for people using
> these devices for sequences / controlling a chain of neopixels / etc
> they're going to need a custom kernel with the driver disabled in order
> to access it from userland.
Whi
Close pipes before freeing transfer descriptors on close(2), otherwise a
use-after-free is possible in usbd_abort_pipe(9).
Ok?
Index: uhidev.c
===
RCS file: /cvs/src/sys/dev/usb/uhidev.c,v
retrieving revision 1.77
diff -u -p -r1.77 u
I forgot those previously, convert them to tsleep_nsec(9), ok?
Index: kern/init_main.c
===
RCS file: /cvs/src/sys/kern/init_main.c,v
retrieving revision 1.293
diff -u -p -r1.293 init_main.c
--- kern/init_main.c29 Nov 2019 06:34:45
Convert the remaining infinite sleeps that my grep-foo found to
{t,m}sleep_nsec(9), ok?
Index: dev/hotplug.c
===
RCS file: /cvs/src/sys/dev/hotplug.c,v
retrieving revision 1.16
diff -u -p -r1.16 hotplug.c
--- dev/hotplug.c 7 Jun
I'd like to stop converting the given timespec to ticks and instead use
nanoseconds. This is part of the ongoing effort to reduce the use of
`hz' through the kernel.
Since I don't know C I'd appreciate any pointer about the checks that
should be added to TIMESPEC_TO_NSEC().
Then the conversions
On 31/12/19(Tue) 17:44, Alexander Bluhm wrote:
> On Tue, Dec 31, 2019 at 04:35:59PM +0100, Martin Pieuchot wrote:
> > Since I don't know C I'd appreciate any pointer about the checks that
> > should be added to TIMESPEC_TO_NSEC().
>
> Perhaps this way?
Th
On 31/12/19(Tue) 15:00, Todd C. Miller wrote:
> On Tue, 31 Dec 2019 16:35:59 +0100, Martin Pieuchot wrote:
>
> > I'd like to stop converting the given timespec to ticks and instead use
> > nanoseconds. This is part of the ongoing effort to reduce the use of
>
`sce' timeouts, like most of the USB timeouts are expressed in ms. So
use MSEC_TO_NSEC() and tsleep_nsec(9) accordingly.
Ok?
Index: ugen.c
===
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.100
diff -u -p -r1.100 ugen
UOW_TIMEOUT is expressed in msec, so use MSEC_TO_NSEC() and tsleep_nsec(9)
instead of dereferencing `hz'.
Ok?
Index: uow.c
===
RCS file: /cvs/src/sys/dev/usb/uow.c,v
retrieving revision 1.35
diff -u -p -r1.35 uow.c
--- uow.c 6
On 01/01/20(Wed) 22:13, Scott Cheloha wrote:
> > On Dec 31, 2019, at 9:35 AM, Martin Pieuchot wrote:
> >
> > I'd like to stop converting the given timespec to ticks and instead use
> > nanoseconds. This is part of the ongoing effort to reduce the use o
On 02/01/20(Thu) 14:29, Scott Cheloha wrote:
> > On Jan 2, 2020, at 9:02 AM, Martin Pieuchot wrote:
> >
> > On 01/01/20(Wed) 22:13, Scott Cheloha wrote:
> >>> On Dec 31, 2019, at 9:35 AM, Martin Pieuchot wrote:
> >>>
> >>> I'd like to
`delay' is expressed in ms, however since tsleep_nsec(9) doesn't add a
tick the conversions below might result in shorter sleeps. I'd
appreciate if uthum(4) owners could test this diff and report back.
Index: uthum.c
===
RCS file: /c
On 04/01/20(Sat) 16:30, Mark Kettenis wrote:
> > Date: Sat, 4 Jan 2020 16:15:22 +0100
> > From: Martin Pieuchot
> >
> > `delay' is expressed in ms, however since tsleep_nsec(9) doesn't add a
> > tick the conversions below might result in shorter sleeps
On 06/01/20(Mon) 17:21, Scott Cheloha wrote:
> [...]
> But the risk is there. So I don't want to change the rounding yet.
Which risk? You still haven't explain. Diff is below, where is the
risk?
> So I don't want to change the rounding yet.
That we understood :o) It'
Use tsleep_nsec(9) for multiline infinite sleeps as well!
ok?
Index: kern/sysv_sem.c
===
RCS file: /cvs/src/sys/kern/sysv_sem.c,v
retrieving revision 1.56
diff -u -p -r1.56 sysv_sem.c
--- kern/sysv_sem.c 4 Feb 2019 07:04:28 -
Convert sleeps of 1sec or more that follow the '* hz' idiom to
tsleep_nsec(9).
Ok?
Index: dev/acpi/tipmic.c
===
RCS file: /cvs/src/sys/dev/acpi/tipmic.c,v
retrieving revision 1.4
diff -u -p -r1.4 tipmic.c
--- dev/acpi/tipmic.c 4 Ap
On 09/01/20(Thu) 10:46, Alexander Bluhm wrote:
> Without this diff my regress machines became so unstable, that they
> often do not finish the test run.
>
> With this diff, they run fine. No regressions.
Sadly this is a workaround. What is the issue? We're missing a barrier
during umount? How
Convert them to tsleep_nsec(9), ok?
Index: kern/subr_extent.c
===
RCS file: /cvs/src/sys/kern/subr_extent.c,v
retrieving revision 1.62
diff -u -p -r1.62 subr_extent.c
--- kern/subr_extent.c 11 Sep 2019 12:30:34 - 1.62
+++ ke
Hello,
On 10/01/20(Fri) 20:47, j...@posteo.de wrote:
> this diff changes timeout_add(9) to timeout_add_msec(9).
> Since the changes are fairly short, I took the liberty to put
> all diffs of sys/kern/ into this mail.
> If you want me to send indiviual mails please say so.
I would be delighted if
SO_RCVTIMEO and SO_SNDTIMEO allow userland to specify a timeout value
via a 'struct timeval'. Internally the kernel keeps this time
representation in ticks. Diff below changes that to nanoseconds which
allows us to use tsleep_nsec(9) in sosleep().
That means we need a new conversion routine: TIM
The custom semaphores used by softdep always use infinite tsleep(9). So
remove the `timo' argument from sema_init() and switch the implementation
to tsleep_nsec(9) and INFSLP.
ok?
Index: ufs/ffs/ffs_softdep.c
===
RCS file: /cvs/src/
Before converting network timeouts to run in a thread context they were
executed in a soft-interrupt handler. This design implied that timeouts
were serialized.
The current "softclock" thread runs on CPU0 to limit border effects due
to the conversion from soft-interrupt to thread context. Howeve
On 11/01/20(Sat) 16:12, Scott Cheloha wrote:
> On Sat, Jan 11, 2020 at 05:41:00PM +0100, Martin Pieuchot wrote:
> > Before converting network timeouts to run in a thread context they were
> > executed in a soft-interrupt handler. This design implied that timeouts
> > were
Now that tsleep_nsec(9) has the same behavior as tsleep(9) the
conversion be low should be safe.
Ok?
Index: uthum.c
===
RCS file: /cvs/src/sys/dev/usb/uthum.c,v
retrieving revision 1.32
diff -u -p -r1.32 uthum.c
--- uthum.c 9 Jan
901 - 1000 of 2816 matches
Mail list logo
