bpf(4): separate nonblocking status from read timeout

Hi, I want to remove the use of ticks from bpf(4) and replace it with the system uptime clock. Before we can do that, though, we need to separate the bpf(4) descriptor's nonblocking status and its read timeout. The two states share the same struct member, bpf_d.bd_rtout. Currently, if

i2c driver for Elan Touchpad

A long while ago, Ben Pye did an i2c driver for the Elan Touchpad. I believe it had been reviewed at the time, but it was never committed. Attached is that patch against -current. OK? Index: arch/amd64/conf/GENERIC === RCS file:

Re: Regarding the understanding of the malloc(3) code

On Wed, Mar 25, 2020 at 01:54:51AM +0530, Neeraj Pal wrote: > Hi Otto, > > I am having two small issues or confusions: > > First Query: > > 885 /* > 886 * Allocate a page of chunks > 887 */ > 888 static struct chunk_info * > 889 omalloc_make_chunks(struct dir_info *d, int bits, int

Re: Regarding the understanding of the malloc(3) code

Hi Otto, I am having two small issues or confusions: First Query: 885 /* 886 * Allocate a page of chunks 887 */ 888 static struct chunk_info * 889 omalloc_make_chunks(struct dir_info *d, int bits, int listnum) 890 { 891 struct chunk_info *bp; 892 void *pp; 893 894

Re: [PLEASE TEST] acpi(4): acpi_sleep(): tsleep(9) -> tsleep_nsec(9)

> Date: Tue, 24 Mar 2020 12:52:55 -0500 > From: Scott Cheloha > > On Tue, Mar 24, 2020 at 09:17:34AM +0100, Mark Kettenis wrote: > > > Date: Mon, 23 Mar 2020 21:57:46 -0500 > > > From: Scott Cheloha > > > > > > On Sun, Mar 15, 2020 at 09:55:53PM -0500, Scott Cheloha wrote: > > > > > > > >

Re: xorg packaging issue

On Tue, Mar 24, 2020 at 01:26:36PM +0100, Marc Espie wrote: > There's some inconsistency: > lists/xserv/mi:./usr/X11R6/share/aclocal/xorg-macros.m4 > lists/xshare/mi:./usr/X11R6/lib/pkgconfig/xorg-macros.pc > > both should be in xshare It was moved to xserv by fries@ some years ago for I don't

Re: [PLEASE TEST] acpi(4): acpi_sleep(): tsleep(9) -> tsleep_nsec(9)

On Tue, Mar 24, 2020 at 09:17:34AM +0100, Mark Kettenis wrote: > > Date: Mon, 23 Mar 2020 21:57:46 -0500 > > From: Scott Cheloha > > > > On Sun, Mar 15, 2020 at 09:55:53PM -0500, Scott Cheloha wrote: > > > > > > [...] > > > > > > This is a straightforward ticks-to-milliseconds conversion, but

Re: Dead code in uvm_pageout()

> Date: Tue, 24 Mar 2020 16:11:48 +0100 > From: Martin Pieuchot > > On 24/03/20(Tue) 15:55, Mark Kettenis wrote: > > > Date: Tue, 24 Mar 2020 15:18:13 +0100 > > > From: Martin Pieuchot > > > > > > As soon as an entry is found on `pmr_control.allocs' the boolean > > > `work_done' will be set to

Re: uvm_mapent_alloc() & NULL check

> Date: Tue, 24 Mar 2020 16:08:56 +0100 > From: Martin Pieuchot > > Variable `me' is never NULL before reaching RBT_POISON(). Diff has a > lot of context to ease the review. > > CID 1453116 Dereference before null check > > ok? ok kettenis@ > Index: uvm/uvm_map.c >

Re: Dead code in uvm_pageout()

On 24/03/20(Tue) 15:55, Mark Kettenis wrote: > > Date: Tue, 24 Mar 2020 15:18:13 +0100 > > From: Martin Pieuchot > > > > As soon as an entry is found on `pmr_control.allocs' the boolean > > `work_done' will be set to true. So it is impossible to reach the > > case below that sets UVM_PMA_FAIL.

uvm_mapent_alloc() & NULL check

Variable `me' is never NULL before reaching RBT_POISON(). Diff has a lot of context to ease the review. CID 1453116 Dereference before null check ok? Index: uvm/uvm_map.c === RCS file: /cvs/src/sys/uvm/uvm_map.c,v retrieving

Re: Dead code in uvm_pageout()

> Date: Tue, 24 Mar 2020 15:18:13 +0100 > From: Martin Pieuchot > > As soon as an entry is found on `pmr_control.allocs' the boolean > `work_done' will be set to true. So it is impossible to reach the > case below that sets UVM_PMA_FAIL. > > CID 1453061 Logically dead code > > Ok? Almost

Dead code in uvm_pageout()

As soon as an entry is found on `pmr_control.allocs' the boolean `work_done' will be set to true. So it is impossible to reach the case below that sets UVM_PMA_FAIL. CID 1453061 Logically dead code Ok? Index: uvm/uvm_pdaemon.c ===

Re: Regarding the understanding of the malloc(3) code

On Wed, Mar 18, 2020 at 4:01 PM Otto Moerbeek wrote: > Not all meta-data canaries live in r/o memory. > > A thing that also helps is to follow the cvs history of a file. The > first version of my malloc (form 2008) was more simple, and looking at > the diffs through the years gives you great

Re: Saving stack frames in dt(4)

On 23/03/20(Mon) 15:18, Martin Pieuchot wrote: > On 19/03/20(Thu) 15:37, Martin Pieuchot wrote: > > People are starting to capture kernel stack traces and produce > > Flamegraphs. Those traces currently include the frames used by > > dt(4) itself: > > > > dt_pcb_ring_get+0x11d > >

Re: iked users database misses entries after ikectl reload

On Mon, Mar 23, 2020 at 05:53:00PM -0300, Bernardo Cunha Vieira wrote: > Hi, > This fixes the users' database corruption after an iked reload. > The old code overwrites the pointers in the RB tree, losing users > if a list of users is provided in config file. > Regards, > Bernardo Good find,

bootblocks ffs2 support for sparc64

Hi, As some of you know I have been working on the ability to boot from an ffs2 root partition on as many platforms as possible. Many platforms are done, but sparc64, landisk, octeon and luna88k remain. sparc64 uses bootblock written in Forth that interpret the filesystem on the boot disk.

xorg packaging issue

There's some inconsistency: lists/xserv/mi:./usr/X11R6/share/aclocal/xorg-macros.m4 lists/xshare/mi:./usr/X11R6/lib/pkgconfig/xorg-macros.pc both should be in xshare This does explain the failures of tightvnc on some bulk machines. By default, proot does NOT copy xserv in the chroot, and I

iked users database misses entries after ikectl reload

Hi, This fixes the users' database corruption after an iked reload. The old code overwrites the pointers in the RB tree, losing users if a list of users is provided in config file. Regards, Bernardo Index: config.c === RCS file:

Re: Untangle proc * in VOP_*

On 23/03/20(Mon) 18:51, Ted Unangst wrote: > [...] > If this is a temporary measure, I think it should include some > annotation to that effect, so that it doesn't continue spreading. It isn't, it's to help review or upcoming diffs :o) It's not to make this nice it's to tedu it!

Re: [PLEASE TEST] acpi(4): acpi_sleep(): tsleep(9) -> tsleep_nsec(9)

> Date: Mon, 23 Mar 2020 21:57:46 -0500 > From: Scott Cheloha > > On Sun, Mar 15, 2020 at 09:55:53PM -0500, Scott Cheloha wrote: > > > > [...] > > > > This is a straightforward ticks-to-milliseconds conversion, but IIRC > > pirofti@ wanted me to get some tests before committing it. > > > >

Re: rtsock: redundant NULL pointer check

On Mon, Mar 23, 2020 at 10:36:20PM +0100, Tobias Heider wrote: > It seems that there is no way 'rtm' could actually be NULL here, which > means we can get rid of the check. > > ok? OK claudio@ > Index: net/rtsock.c > === > RCS

snmpd(8) (temporary) removal of sysortable

We currently abuse sysORTable to display information in a way that it shouldn't. According to SNMPv2-MIB: "The (conceptual) table listing the capabilities of the local SNMP application acting as a command responder with respect to various MIB modules.