Re: Say no to LARVAL

On Tue, 8 May 2018, Martin Pieuchot wrote: > The way our kernel allocates and populates new 'struct file *' is > currently a complete mess. One of the problems is that it puts > incomplete descriptors on the global `filehead' list and on the > open file array `fd_ofiles'. But to make sure that

futex: FUTEX_WAIT: check for normalized timeout

Hi, futex(2) doesn't do any range checking for timeout for FUTEX_WAIT, though recent Linux does so. I assume we'd also want to validate timeout before waiting. The attached returns EINVAL if timeout's fields are non-normal, documents it, and adds a test case. ok? -- Scott Cheloha Index:

tcp debug timers

Hi, In the old times TCP timers were slow or fast pru requests. TCP debug sockets have still code for that. Replace that with a timer implementation. ok? bluhm Index: sys/netinet/tcp_debug.c === RCS file:

Re: `f_ops' is immutable

On Tue, May 08, 2018 at 06:52:23PM +0200, Martin Pieuchot wrote: > diskmapioctl() plays some tricks to change the vnode of an open file. > It tries to be clever to avoid allocating a new `fp'. It is totally > understandable because the kernel is lacking an API to insert/remove > 'struct file *'

`f_ops' is immutable

diskmapioctl() plays some tricks to change the vnode of an open file. It tries to be clever to avoid allocating a new `fp'. It is totally understandable because the kernel is lacking an API to insert/remove 'struct file *' from shared data structures. But since it is not changing the type of the

Say no to LARVAL

The way our kernel allocates and populates new 'struct file *' is currently a complete mess. One of the problems is that it puts incomplete descriptors on the global `filehead' list and on the open file array `fd_ofiles'. But to make sure that other threads won't use such descriptors before they

Spinning time is not System time

Diff below, gypped from jmatthew@, allows us to see how much time CPUs spend spinning on a mutex or on the KERNEL_LOCK(). On my sparc64 with 16 CPUs, top(1) now reports: 16 CPUs: 16.8% user, 0.0% nice, 9.2% sys, 49.4% spin, 0.1% intr, 24.5% idle And systat(1) CPU view: CPUUser

Re: tcp timer delack

On 08/05/18(Tue) 15:26, Alexander Bluhm wrote: > On Tue, May 08, 2018 at 03:04:59PM +0200, Martin Pieuchot wrote: > > On 08/05/18(Tue) 14:32, Alexander Bluhm wrote: > > > @@ -176,12 +176,12 @@ do { \ > > > struct ifnet *ifp = NULL; \ > > > if (m && (m->m_flags & M_PKTHDR)) \ > > >

Re: tcp timer delack

On Tue, May 08, 2018 at 03:04:59PM +0200, Martin Pieuchot wrote: > On 08/05/18(Tue) 14:32, Alexander Bluhm wrote: > > @@ -176,12 +176,12 @@ do { \ > > struct ifnet *ifp = NULL; \ > > if (m && (m->m_flags & M_PKTHDR)) \ > > ifp = if_get(m->m_pkthdr.ph_ifidx); \ > > - if

Re: tcp timer delack

On 08/05/18(Tue) 14:32, Alexander Bluhm wrote: > Hi, > > Historically there were slow and fast tcp timeouts. That is why > the delack timer has a different implementation. > > Let's use the same macros for all TCP timer. > > Index: netinet/tcp_input.c >

Re: new semapahore implementation using atomics and futexes

On 07/05/18(Mon) 14:01, Paul Irofti wrote: > > > > > The reason we need this is to make semaphores safe for asynchronous > > > > > signals. > > > > Could you describe with words what is currently broken and how the > > version below fixes it? > > POSIX dictates that sem_post() needs to be

tcp timer delack

Hi, Historically there were slow and fast tcp timeouts. That is why the delack timer has a different implementation. Let's use the same macros for all TCP timer. ok? bluhm Index: netinet/tcp_input.c === RCS file:

Re: Introduce rtm_sendup()

On Tue, May 08, 2018 at 11:08:28AM +0200, Martin Pieuchot wrote: > Diff below factorizes some bits of route_input() into rtm_sendup(), a > function similar to pfkey_sendup(). Both functions will need the same > MP-safeness love, so it makes sense to reduce differences. > > Ok? OK bluhm@ >

Re: sysctl_file() & refcount

On Tue, May 08, 2018 at 12:55:49PM +0200, Martin Pieuchot wrote: > Use fd_getfile() instead of rewriting it. Plus we'll need a properly > refcounted `fp' as soon as some syscalls are unlocked. > > Ok? OK bluhm@ > Index: kern/kern_sysctl.c >

socket splicing timer use after free

Hi, Socket splicing can delay operations by task or timeout. I have fixed the use afer free in the task a while ago, but forgot the timeout. Introduce soreaper() that is scheduled onto the timer thread. soput() is scheduled from there onto the sosplice task thread. After that it is save to

sysctl_file() & refcount

Use fd_getfile() instead of rewriting it. Plus we'll need a properly refcounted `fp' as soon as some syscalls are unlocked. Ok? Index: kern/kern_sysctl.c === RCS file: /cvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.335

Introduce rtm_sendup()

Diff below factorizes some bits of route_input() into rtm_sendup(), a function similar to pfkey_sendup(). Both functions will need the same MP-safeness love, so it makes sense to reduce differences. Ok? Index: net/pfkeyv2.c === RCS

Re: Print xHCI version

> Date: Tue, 8 May 2018 10:47:16 +0200 > From: Martin Pieuchot > > I'd like to print the version of the xHCI controller in the dmesg like > we do for AHCI. I've been looking at some xHCI 1.1 peculiarities lately > and apparently our driver also need some love for pre 1.0

Print xHCI version

I'd like to print the version of the xHCI controller in the dmesg like we do for AHCI. I've been looking at some xHCI 1.1 peculiarities lately and apparently our driver also need some love for pre 1.0 chips. With the diff below, we will now print: xhci0 at pci0 dev 20 function 0 "Intel 9 Series

switchd(8): ignore packet_out with dstport = OFP_PORT_ANY

On Fri, Apr 20, 2018 at 10:18:34AM -0700, Ayaka Koshibe wrote: > Hi, > > switchd(8) sends packet_outs with OFP_PORT_ANY as the dstport, causing > switches receiving them to disconnect due to validation failure of the said > message. The comments indicate that looping packets should be ignored,

Automatic configuration of /etc/ttys in installer

After my recent changes to armv7 and arm64 the installer and single-user mode are usable with a non-standard serial console speed. However, the installer will still install an /etc/ttys file with std.115200 in it. This means that getty(8) will change the speed which means you get garbage or