Re: stdio: fclose(3), fopen(3): intended locking hierarchy?

2020-12-01 Thread Scott Cheloha
On Mon, Nov 30, 2020 at 08:44:41PM -0800, Philip Guenther wrote: > On Mon, Nov 30, 2020 at 6:10 PM Scott Cheloha > wrote: > > > On Sat, Nov 28, 2020 at 01:41:50PM -0800, Philip Guenther wrote: > > > ... > > > > After thinking through states more, #4 isn't safe: _fwalk() can't take > > >

PF synproxy should act on inbound packets only

2020-12-01 Thread Alexandr Nedvedicky
Hello, the issue described here has been hit bu Stuart some time ago. feel free to stop reading if you don't care/use pf(4) synproxy. let's assume there are rules which allow just surfing web over http: block all pass proto tcp from any to any port = 80 synproxy state pass proto

Re: Dell XPS 9310 succesful install but bootloader can't read disk label

2020-12-01 Thread George Koehler
On Wed, 2 Dec 2020 01:59:00 +0100 Noth wrote: > Disk: sd0   Usable LBA: 34 to 4000797326 [4000797360 Sectors] >    #: type [   start: size ] > >    0: EFI Sys

Re: Dell XPS 9310 succesful install but bootloader can't read disk label

2020-12-01 Thread Noth
Here we go (sd0 is the NVMe, sd0a is an encrypted OpenBSD install, which is on sd2). And yes, once decrypted, I can write to the partitions: Disk: sd0   Usable LBA: 34 to 4000797326 [4000797360 Sectors]    #: type [   start: size ]

Re: ACPI diff that needs wide testing

2020-12-01 Thread Greg Steuck
Mark Kettenis writes: >> From: Greg Steuck >> Date: Mon, 30 Nov 2020 20:54:59 -0800 >> >> Mark Kettenis writes: >> >> > The diff below fixes the way we handle named references in AML >> > packages. This fixes some bugs but I'd like to make sure that this >> > doesn't inadvertedly break

Re: Dell XPS 9310 succesful install but bootloader can't read disk label

2020-12-01 Thread Mark Kettenis
> From: Noth > Date: Tue, 1 Dec 2020 21:18:14 +0100 > > Hi, > >   As a follow up, I got a usb-c stick and installed -current to that. > It boots the system so I now have a dmesg, pcidump and usbdump for you: > > http://casper.nineinchnetworks.ch/images/dmesg9310.txt > >

Re: Dell XPS 9310 succesful install but bootloader can't read disk label

2020-12-01 Thread Noth
Hi,   As a follow up, I got a usb-c stick and installed -current to that. It boots the system so I now have a dmesg, pcidump and usbdump for you: http://casper.nineinchnetworks.ch/images/dmesg9310.txt http://casper.nineinchnetworks.ch/images/pcidump9310.txt

Re: ACPI diff that needs wide testing

2020-12-01 Thread Mark Kettenis
> From: Greg Steuck > Date: Mon, 30 Nov 2020 20:54:59 -0800 > > Mark Kettenis writes: > > > The diff below fixes the way we handle named references in AML > > packages. This fixes some bugs but I'd like to make sure that this > > doesn't inadvertedly break things. So tests on a wide variety

Re: ACPI diff that needs wide testing

2020-12-01 Thread Mark Kettenis
> Date: Tue, 1 Dec 2020 20:17:47 +0100 > From: Theo Buehler > > On Tue, Dec 01, 2020 at 08:10:33PM +0100, Mark Kettenis wrote: > > > From: Greg Steuck > > > Date: Mon, 30 Nov 2020 20:54:59 -0800 > > > > > > Mark Kettenis writes: > > > > > > > The diff below fixes the way we handle named

[PATCH] __rec_open() should set the type

2020-12-01 Thread Boudewijn Dijkstra
According to dbopen(3), the 'type' field of struct DB holds the "type of the underlying access method (and file format)." In __bt_open() it is set to DB_BTREE and in __hash_open() it is set to DB_HASH, so one might expect that in __rec_open() it is set to DB_RECNO. However, it is left

Re: ACPI diff that needs wide testing

2020-12-01 Thread Theo Buehler
On Tue, Dec 01, 2020 at 08:10:33PM +0100, Mark Kettenis wrote: > > From: Greg Steuck > > Date: Mon, 30 Nov 2020 20:54:59 -0800 > > > > Mark Kettenis writes: > > > > > The diff below fixes the way we handle named references in AML > > > packages. This fixes some bugs but I'd like to make sure

More uvm_pagefree() lock fixes

2020-12-01 Thread Martin Pieuchot
As recently pointed out by jmatthew@ these need the lock as well, ok? Index: uvm/uvm_km.c === RCS file: /cvs/src/sys/uvm/uvm_km.c,v retrieving revision 1.137 diff -u -p -r1.137 uvm_km.c --- uvm/uvm_km.c23 May 2020 06:15:09

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Martin Pieuchot
On 01/12/20(Tue) 15:30, Claudio Jeker wrote: > [...] > Did you run a make build with that smr_barrier() in it and checked that it > does not cause a slow down? I am sceptical, smr_barrier() is a very slow > construct which introduces large delays and should be avoided whenever > possible. I did

Re: ACPI diff that needs wide testing

2020-12-01 Thread Mark Kettenis
> From: Greg Steuck > Date: Mon, 30 Nov 2020 20:54:59 -0800 > > Mark Kettenis writes: > > > The diff below fixes the way we handle named references in AML > > packages. This fixes some bugs but I'd like to make sure that this > > doesn't inadvertedly break things. So tests on a wide variety

Re: More uvm_pagefree() lock fixes

2020-12-01 Thread Mark Kettenis
> Date: Tue, 1 Dec 2020 13:18:59 -0300 > From: Martin Pieuchot > > On 01/12/20(Tue) 15:18, Mark Kettenis wrote: > > > Date: Tue, 1 Dec 2020 11:08:50 -0300 > > > From: Martin Pieuchot > > > > > > As recently pointed out by jmatthew@ these need the lock as well, ok? > > > > No. These pages are

Re: wireguard + witness

2020-12-01 Thread Sebastien Marie
On Tue, Dec 01, 2020 at 06:59:22AM +0100, Sebastien Marie wrote: > On Mon, Nov 30, 2020 at 11:14:46PM +, Stuart Henderson wrote: > > Thought I'd try a WITNESS kernel to see if that gives any clues about > > what's going on with my APU crashing all over the place (long shot but > > I got bored

Re: Prevent race in single_thread_set()

2020-12-01 Thread Claudio Jeker
On Mon, Nov 30, 2020 at 07:19:28PM -0300, Martin Pieuchot wrote: > On 04/11/20(Wed) 11:19, Martin Pieuchot wrote: > > Here's a 3rd approach to solve the TOCTOU race in single_thread_set(). > > The issue being that the lock serializing access to `ps_single' is not > > held when calling

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Claudio Jeker
On Mon, Nov 30, 2020 at 07:10:47PM -0300, Martin Pieuchot wrote: > Every multi-threaded process keeps a list of threads in `ps_threads'. > This list is iterated in interrupt and process context which makes it > complicated to protect it with a rwlock. > > One of the places where such iteration is

Re: wireguard + witness

2020-12-01 Thread Stuart Henderson
On 2020/12/01 10:32, Sebastien Marie wrote: > On Tue, Dec 01, 2020 at 06:59:22AM +0100, Sebastien Marie wrote: > > On Mon, Nov 30, 2020 at 11:14:46PM +, Stuart Henderson wrote: > > > Thought I'd try a WITNESS kernel to see if that gives any clues about > > > what's going on with my APU

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Jonathan Matthew
On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote: > On 01/12/20(Tue) 15:30, Claudio Jeker wrote: > > [...] > > Did you run a make build with that smr_barrier() in it and checked that it > > does not cause a slow down? I am sceptical, smr_barrier() is a very slow > > construct which

Re: ACPI diff that needs wide testing

2020-12-01 Thread Florian Obser
On Tue, Dec 01, 2020 at 10:40:30PM +0100, Mark Kettenis wrote: > > From: Greg Steuck > > Date: Mon, 30 Nov 2020 20:54:59 -0800 > > > > Mark Kettenis writes: > > > > > The diff below fixes the way we handle named references in AML > > > packages. This fixes some bugs but I'd like to make sure

Re: rad(8): rdomain support

2020-12-01 Thread Theo Buehler
On Mon, Nov 30, 2020 at 05:46:57PM +0100, Florian Obser wrote: > On Sun, Nov 29, 2020 at 12:20:31PM +0100, Florian Obser wrote: > > > > Let rad(8) handle all rdomains in a single daemon, similar to previous > > work in slaacd. > > > > Suggested / requested by tb who showed me previous work

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Jonathan Matthew
On Tue, Dec 01, 2020 at 10:31:43AM +0100, Claudio Jeker wrote: > On Mon, Nov 30, 2020 at 07:10:47PM -0300, Martin Pieuchot wrote: > > Every multi-threaded process keeps a list of threads in `ps_threads'. > > This list is iterated in interrupt and process context which makes it > > complicated to

Re: wireguard + witness

2020-12-01 Thread Stuart Henderson
On 2020/12/01 21:27, Matt Dunwoodie wrote: > On Tue, 1 Dec 2020 10:32:29 +0100 > Sebastien Marie wrote: > > > Jason, Matt, > > > > sthen@ told me that the same lock is reported several times (exactly, > > two locks are reported several times: lock1, lock2, lock1, lock2...) > > > > witness(4)

Re: rad(8): rdomain support

2020-12-01 Thread Florian Obser
I copied the (void)strlcpy from somewhere, likely ifconfig originally. Thanks for pointing it out, I shall remove it before commit. I don't like that style and don't think it helps anything during review since one needs to check anyway that truncation either can't happen or doesn't matter. On 1

Re: Prevent race in single_thread_set()

2020-12-01 Thread Martin Pieuchot
On 01/12/20(Tue) 10:21, Claudio Jeker wrote: > On Mon, Nov 30, 2020 at 07:19:28PM -0300, Martin Pieuchot wrote: > > On 04/11/20(Wed) 11:19, Martin Pieuchot wrote: > > > Here's a 3rd approach to solve the TOCTOU race in single_thread_set(). > > > The issue being that the lock serializing access to

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Claudio Jeker
On Tue, Dec 01, 2020 at 09:47:35PM +1000, Jonathan Matthew wrote: > On Tue, Dec 01, 2020 at 10:31:43AM +0100, Claudio Jeker wrote: > > On Mon, Nov 30, 2020 at 07:10:47PM -0300, Martin Pieuchot wrote: > > > Every multi-threaded process keeps a list of threads in `ps_threads'. > > > This list is

Re: wireguard + witness

2020-12-01 Thread Matt Dunwoodie
On Tue, 1 Dec 2020 10:32:29 +0100 Sebastien Marie wrote: > Jason, Matt, > > sthen@ told me that the same lock is reported several times (exactly, > two locks are reported several times: lock1, lock2, lock1, lock2...) > > witness(4) reports when a lock doesn't have LO_INITIALIZED flag set in >

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Martin Pieuchot
On 01/12/20(Tue) 21:47, Jonathan Matthew wrote: > On Tue, Dec 01, 2020 at 10:31:43AM +0100, Claudio Jeker wrote: > > On Mon, Nov 30, 2020 at 07:10:47PM -0300, Martin Pieuchot wrote: > > > Every multi-threaded process keeps a list of threads in `ps_threads'. > > > This list is iterated in interrupt

Re: Prevent race in single_thread_set()

2020-12-01 Thread Claudio Jeker
On Tue, Dec 01, 2020 at 10:27:15AM -0300, Martin Pieuchot wrote: > On 01/12/20(Tue) 10:21, Claudio Jeker wrote: > > On Mon, Nov 30, 2020 at 07:19:28PM -0300, Martin Pieuchot wrote: > > > On 04/11/20(Wed) 11:19, Martin Pieuchot wrote: > > > > Here's a 3rd approach to solve the TOCTOU race in

snmpd drop traphandler process

2020-12-01 Thread Martijn van Duren
Hello tech@, Long story short: the traphandler process in snmpd annoys me a great deal and is in the way for overhauling the transport mapping section of snmpe, which is needed for implementing new agentx master support. The current traphandler process is also a joke, since all it does is

Re: More uvm_pagefree() lock fixes

2020-12-01 Thread Martin Pieuchot
On 01/12/20(Tue) 15:18, Mark Kettenis wrote: > > Date: Tue, 1 Dec 2020 11:08:50 -0300 > > From: Martin Pieuchot > > > > As recently pointed out by jmatthew@ these need the lock as well, ok? > > No. These pages are "unmanaged" and therefore they can not be on any > of the page queues and

Re: [PATCH] __rec_open() should set the type

2020-12-01 Thread Todd C . Miller
On Tue, 01 Dec 2020 14:07:18 +0100, "Boudewijn Dijkstra" wrote: > According to dbopen(3), the 'type' field of struct DB holds the "type of > the underlying access method (and file format)." In __bt_open() it is set > to DB_BTREE and in __hash_open() it is set to DB_HASH, so one might expect

Re: Use SMR_TAILQ for `ps_threads'

2020-12-01 Thread Claudio Jeker
On Tue, Dec 01, 2020 at 10:46:00AM -0300, Martin Pieuchot wrote: > On 01/12/20(Tue) 21:47, Jonathan Matthew wrote: > > On Tue, Dec 01, 2020 at 10:31:43AM +0100, Claudio Jeker wrote: > > > On Mon, Nov 30, 2020 at 07:10:47PM -0300, Martin Pieuchot wrote: > > > > Every multi-threaded process keeps a

Re: More uvm_pagefree() lock fixes

2020-12-01 Thread Mark Kettenis
> Date: Tue, 1 Dec 2020 11:08:50 -0300 > From: Martin Pieuchot > > As recently pointed out by jmatthew@ these need the lock as well, ok? No. These pages are "unmanaged" and therefore they can not be on any of the page queues and locking those page queues would be pointless. We probably should