On 14/01/20(Tue) 10:34, Jonathan Gray wrote:
> On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> > I'm facing a lock ordering issue while profiling the scheduler which
> > cannot be solved without using a different lock for the global sleepqueue
> &
On 13/01/20(Mon) 21:31, Martin Pieuchot wrote:
> I'd like hardclock() to be free of SCHED_LOCK(), the diff below brings
> us one step away from that goal. Please test with your favorite
> benchmark and report any regression :o)
>
> The reason for moving the SCHED_LOCK() away
I'd like hardclock() to be free of SCHED_LOCK(), the diff below brings
us one step away from that goal. Please test with your favorite
benchmark and report any regression :o)
The reason for moving the SCHED_LOCK() away from hardclock() is because
it will allow us to re-commit the diff moving
I'm facing a lock ordering issue while profiling the scheduler which
cannot be solved without using a different lock for the global sleepqueue
and the runqueues.
The SCHED_LOCK() currently protects both data structures as well as the
related fields in 'struct proc'. One of this fields is
On 13/01/20(Mon) 13:35, Mark Kettenis wrote:
> > Date: Mon, 13 Jan 2020 13:20:45 +0100
> > From: Martin Pieuchot
> >
> > vdsp(4) uses a workaround to not block forever in case the hypervisor
> > doesn't generate an interrupt. The current behavior is to wait the
vdsp(4) uses a workaround to not block forever in case the hypervisor
doesn't generate an interrupt. The current behavior is to wait the
smallest possible interval: one tick.
Since this is a documented workaround the value doesn't matter much, so
convert the driver to tsleep_nsec(9) with a
On 13/01/20(Mon) 12:27, Martin Pieuchot wrote:
> On 13/01/20(Mon) 12:16, Alexander Bluhm wrote:
> > On Sun, Jan 12, 2020 at 01:33:43PM +0100, Martin Pieuchot wrote:
> > > @@ -304,7 +306,7 @@ soclose(struct socket *so, int flags)
> > > while (so
On 13/01/20(Mon) 12:16, Alexander Bluhm wrote:
> On Sun, Jan 12, 2020 at 01:33:43PM +0100, Martin Pieuchot wrote:
> > @@ -304,7 +306,7 @@ soclose(struct socket *so, int flags)
> > while (so->so_state & SS_ISCONNECTED) {
> >
On 12/01/20(Sun) 18:37, Philip Guenther wrote:
> On Sun, Jan 12, 2020 at 4:44 AM Martin Pieuchot wrote:
>
> > The consensus is now to switch syscall doing sleeps to use tsleep_nsec(9).
> > Our direct goal is to stop expressing time as ticks, more might come
> > later.
On 12/01/20(Sun) 16:29, Scott Cheloha wrote:
> On Sun, Jan 12, 2020 at 12:52:53PM +0100, Martin Pieuchot wrote:
> [...]
> > > > However we should raise the IPL level of this thread to ensure no other
> > > > timeout can run in the middle of another one.
> > >
The consensus is now to switch syscall doing sleeps to use tsleep_nsec(9).
Our direct goal is to stop expressing time as ticks, more might come
later.
Diff below introduces the previously discussed TIMESPEC_TO_NSEC(9) macro
and makes use of it in 3 syscalls.
Comments? Oks?
Index:
On 09/01/20(Thu) 16:10, Martin Pieuchot wrote:
> 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 t
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
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
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.
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
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
+++
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?
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
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
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)
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. I'd
>
`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:
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 stop
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 of
>
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
`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
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
> >
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?
Thanks.
>
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
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
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
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
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.
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 -
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
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 -
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 uses
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
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
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
+++
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
+++
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
---
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:
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
+++
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 -
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
+++
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.
>
&
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)
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.
>
>
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
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
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
---
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 -
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
---
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,
> > > w
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
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
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
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
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
'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
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 the ad
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
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
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
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
+++
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
+++
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 :
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
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
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
+++
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
+++
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
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 a
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 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
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:
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
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
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
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
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 :
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
> > >
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
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
On 25/10/19(Fri) 15:10, Damien Miller wrote:
> Some HID devices do not list any report IDs for communication, e.g. my
> Yubikey5:
>
> > uhidev0: iclass 3/0
> > uhid0 at uhidev0: input=64, output=64, feature=0
> > ugen0 at uhub0 port 2 configuration 1 "Yubico YubiKey FIDO+CCID" rev
> > 2.00/5.12
On 23/10/19(Wed) 08:43, Peter J. Philipp wrote:
> Hi Holger & Tech,
Hello Peter,
> I have made my octeon router work again and I have a patch. But I'm not an
> openbsd developer, nor is this patch official in any way.
Could you explain in words what is the issue? Why does your diff
prevent
On 18/10/19(Fri) 14:55, Stefan Sperling wrote:
> On Fri, Oct 18, 2019 at 12:54:06PM +0200, Stefan Sperling wrote:
> > On Fri, Oct 18, 2019 at 11:37:01AM +0200, Martin Pieuchot wrote:
> > > The question here is how an `xfer' with a status of NORMAL_COMPLETION
> > > can b
On 17/10/19(Thu) 18:53, Stefan Sperling wrote:
> My USB scanner works again in 6.6 \o/
> Thanks to whoever fixed it. I have no idea when and how it happened but
> since a few releases back it has always been failed with some I/O error.
> But now it just works again as it once did (apart from a
Kill unused _wait() and use *_PRIVATE in both places.
Using the non-private version of this interface means an extra
uvm_map lookup is done. This isn't required for threads of the
same process.
Ok?
Index: lib/libc/thread/synch.h
The only raison d'etre of scheduler_fork_hook() is because `p_estcpu' is
not at the right place in "struct proc". Diff below fixes that. I
reordered the fields to not have implicit padding increase the size of
the structure.
ok?
Index: sys/proc.h
Convert the two pseudo-drivers to use tsleep_nsec(9) in their read(2)
routine, both drivers block indefinitely.
ok?
Index: net/if_tun.c
===
RCS file: /cvs/src/sys/net/if_tun.c,v
retrieving revision 1.190
diff -u -p -r1.190 if_tun.c
The hz/2 idiom means 500ms, so use that. ok?
Index: netinet/if_ether.c
===
RCS file: /cvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.240
diff -u -p -r1.240 if_ether.c
--- netinet/if_ether.c 17 Jul 2019 16:46:18 -
Bonjour hypra !
J'ai donc passé ma journée d'hier sur Evince et j'ai terminé une
première implémentation en suivant les mêmes pratiques que pour
GtkTextView.
Le code ci-dessous est aussi disponible dans sa branche, sur:
https://gitlab.gnome.org/mpieuchot/evince/tree/issue1203
J'ai eu un
The code is identical 8) ok?
Index: uvideo.c
===
RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
retrieving revision 1.203
diff -u -p -r1.203 uvideo.c
--- uvideo.c7 Aug 2019 11:16:02 - 1.203
+++ uvideo.c7 Oct 2019
I converted the 'hz / 2' idiom into MSEC_TO_NSEC(500), the rest is
obvious.
ok?
Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.204
diff -u -p -r1.204 ehci.c
--- ehci.c 31 Mar 2019 06:16:38 -
The refactoring below reduces the places where scheduling related
variables are written, to help future locking, and makes various
"features" of the existing logic obvious:
- `p_priority' is now modified inside setrunqueue() it becomes obvious
that it is a placeholder for calculating the queue.
I'd like to include CTF data in bsd.gdb.
Currently it only include DWARF data, 'cause that's what the compiler
generates. So the diff below is a hack to teach ctfstrip(1) to also
include the .SUNW_ctf section in bsd.gdb.
This make backtraces readable with a debug kernel, ok?
Index: ctfstrip
ok?
Index: dev/video.c
===
RCS file: /cvs/src/sys/dev/video.c,v
retrieving revision 1.41
diff -u -p -r1.41 video.c
--- dev/video.c 11 Oct 2017 08:08:50 - 1.41
+++ dev/video.c 5 Oct 2019 09:47:42 -
@@ -182,7 +182,7 @@
601 - 700 of 2703 matches
Mail list logo
