mbg(4): tsleep(9) -> tsleep_nsec(9)

2020-12-03 Thread Scott Cheloha
Hi, mbg(4) is among the few remaining drivers using tsleep(9). In a few spots, when the kernel is not cold, the driver will spin for up to 1/10 seconds waiting for the MBG_BUSY flag to go low. We can approximate this behavior by spinning 10 times and sleeping 10 milliseconds each iteration. 10

srp_finalize(9): tsleep(9) -> tsleep_nsec(9)

2020-12-03 Thread Scott Cheloha
Hi, srp_finalize(9) uses tsleep(9) to spin while it waits for the object's refcount to reach zero. It blocks for up to 1 tick and then checks the refecount again and again. We can just as easily do this with tsleep_nsec(9) and block for 1 millisecond per interval. ok? Index: kern_srp.c

tht(4): more tsleep(9) -> tsleep_nsec(9) conversions

2020-12-03 Thread Scott Cheloha
Hi, tht(4) is another driver still using tsleep(9). It uses it to spin while it waits for the card to load the firmware. Then it uses it to spin for up to 2 seconds while waiting for THT_REG_INIT_STATUS. In the firmware case we can sleep for 10 milliseconds each iteration. In the

hvn(4): msleep(9) -> msleep_nsec(9)

2020-12-03 Thread Scott Cheloha
Hi, In hvn_alloc_cmd() we spin within a mutex while the freelist is empty. Because we're using a mutex there is no way to miss the wakeup(9) from hvn_free_cmd(), so we don't even need a timeout here. Instead of doing msleep(9) for 1 tick repeatedly we can msleep_nsec(9) without a timeout

softraid(4): more tsleep(9) -> tsleep_nsec(9) conversions

2020-12-03 Thread Scott Cheloha
Hi, softraid(4) is another driver still using tsleep(9). softraid(4) uses tsleep(9) in one spot to poll for completion. It uses it in two other spots to momentarily yield the CPU to permit a different thread to make progress. In all cases the length of the timeout is totally arbitrary. We're

Re: Use SMR_TAILQ for `ps_threads'

2020-12-03 Thread Jonathan Matthew
On Wed, Dec 02, 2020 at 07:44:02PM +0100, Anton Lindqvist wrote: > On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote: > > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote: > > > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote: > > > > On 01/12/20(Tue) 15:30, Claudio

Re: Use SMR_TAILQ for `ps_threads'

2020-12-03 Thread Jonathan Matthew
On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote: > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote: > > 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

Re: [PATCH] Convert ddb_sysctl to sysctl_bounded_arr

2020-12-03 Thread George Koehler
On Mon, 30 Nov 2020 20:04:10 -0800 Greg Steuck wrote: > Tested with a bunch of manual sysctl -w's. > > OK? I'm not sure about this diff. I'm more likely to do ddb{0}> set $radix = 0t2 and less likely to do # sysctl ddb.radix=2 but you enforce the range check (radix in 8..16)

Re: PF synproxy should act on inbound packets only

2020-12-03 Thread Alexandr Nedvedicky
Hello, > > Just a style nit. Other errors do not put stdin:1 in brackes. One > line per error. In pf.conf the rule direction matters. What about > > stdin:1 warning: synproxy used for inbound rules only, ignored for outbound > thanks, I like your suggestion. below is updated diff.

Re: tcpdump: Don't link to libl and remove reference to yydebug

2020-12-03 Thread Martin Vahlensieck
On Thu, Dec 03, 2020 at 10:56:17PM +0300, Vitaliy Makkoveev wrote: > > On 3 Dec 2020, at 13:20, Martin Vahlensieck > > wrote: > > > > Hi > > Hi. > Hi > > > > This is unused. It has been in there since the import from NetBSD. > > Their logs show that tcpgram.y and tcplex.l have been removed

Re: Diff: Article Fixes

2020-12-03 Thread Jason McIntyre
On Thu, Dec 03, 2020 at 02:20:23AM -0500, VARIK VALEFOR wrote: > Sir or Madam: > > This message contains some diffs which fix incorrect article usage, i.e., > the use of "a" where "an" should have been used, and vice-versa. > > "If you love something, and you set it free, and it doesn't come

Re: amdgpu(4): use DRM_INFO instead of printf for printing compute unit info

2020-12-03 Thread Charlie Burnett
Sure thing! Tracing it out, it seems to happen after the function psp_v11_0_ring_set_wptr is called, but I'm having trouble figuring out *why* the timing is messing it up. It also runs fine if any print statements are called before amdgpu_device_ip_init, however DRMDEBUG has to be disabled. It

bgpd show status of set tables

2020-12-03 Thread Claudio Jeker
The use of roa-set, prefix-set and as-set is fairly common in bgpd. Still sometimes it is not exactly clear how old the data in those tables is. This diff is a first step at inproving inspection by adding bgpctl show sets Sample output is: Type Name #IPv4

Diff: Article Fixes

2020-12-03 Thread VARIK VALEFOR
Sir or Madam: This message contains some diffs which fix incorrect article usage, i.e., the use of "a" where "an" should have been used, and vice-versa. "If you love something, and you set it free, and it doesn't come back, you're a dumb-ass." Varik "NOT A COMPUTER PROGRAMMER!!!" Valefor

Re: tcpdump: Don't link to libl and remove reference to yydebug

2020-12-03 Thread Vitaliy Makkoveev
> On 3 Dec 2020, at 13:20, Martin Vahlensieck > wrote: > > Hi Hi. > > This is unused. It has been in there since the import from NetBSD. > Their logs show that tcpgram.y and tcplex.l have been removed in 1995. > I am not sure what the policy is for the getopt(3) call: Should Y be > removed

Re: PF synproxy should act on inbound packets only

2020-12-03 Thread Alexander Bluhm
On Wed, Dec 02, 2020 at 12:43:28AM +0100, Alexandr Nedvedicky wrote: > the fix is to apply synproxy action on inbound packets only. Diff below > does that exactly. Furthermore it also makes pfctl(8) to emit warning, > when synproxy is being used in outbound/unbound rule: Sounds reasonable. >

Re: Use SMR_TAILQ for `ps_threads'

2020-12-03 Thread Mark Kettenis
> Date: Wed, 2 Dec 2020 19:44:02 +0100 > From: Anton Lindqvist > > On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote: > > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote: > > > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote: > > > > On 01/12/20(Tue) 15:30, Claudio

Re: unwind(8): handle large answers differently

2020-12-03 Thread Florian Obser
Anyone? While I could volunteer all y'all for testing that seems a bit silly. I'd rather have someone to read the diff because - The tricky cases will be very rare to hit in normal operations, DNS answers are just not that big. - I'd like to hear that this is actually a good pattern to do this

Small optimization to smr_grace_wait()

2020-12-03 Thread Visa Hankala
Here is a small optimization to SMR's naive grace period mechanism. It makes use of the fact that some CPUs may cross a quiescent state independently while the SMR thread is running smr_grace_wait(). Such CPUs can be skipped. Index: kern/kern_smr.c

Re: rpki-client: use strndup instead of malloc + memcpy

2020-12-03 Thread Claudio Jeker
On Thu, Dec 03, 2020 at 03:48:00PM +0100, Christian Weisgerber wrote: > Claudio Jeker: > > > In tal_parse() use strndup() to create the tal descr instead of the more > > complex malloc, memcpy version. Result is the same but the strndup version > > is a lot nicer. > > Yes, but... > > > ---

postgresql 12 - could not open shared memory segment

2020-12-03 Thread David Hill
Hello - I am using postgresql 12 on OpenBSD 6.8. After a while of running, postgresql starts throwing out errors: 2020-12-03 08:18:35.052 CST [60288] ERROR: could not open shared memory segment "/PostgreSQL.1780529043": No such file or directory 2020-12-03 08:18:35.052 CST [40083] ERROR:

Re: rpki-client: use strndup instead of malloc + memcpy

2020-12-03 Thread Christian Weisgerber
Claudio Jeker: > In tal_parse() use strndup() to create the tal descr instead of the more > complex malloc, memcpy version. Result is the same but the strndup version > is a lot nicer. Yes, but... > --- tal.c 11 Oct 2020 12:39:25 - 1.22 > +++ tal.c 3 Dec 2020 12:00:25 - >

Re: Use SMR_TAILQ for `ps_threads'

2020-12-03 Thread Visa Hankala
On Wed, Dec 02, 2020 at 07:44:02PM +0100, Anton Lindqvist wrote: > I'm wondering if smr_grace_wait() could be improved on amd64, assuming > SMT is disabled, by skipping offline CPUs. > > Index: kern/kern_smr.c > === > RCS file:

Re: Better overflow check in bgpd

2020-12-03 Thread Claudio Jeker
On Wed, Dec 02, 2020 at 12:19:11PM +0100, Claudio Jeker wrote: > The overflow check for the relative metric adjustments of filtersets > assumes a certain overflow behaviour of signed integers. I think it is > better to write this in a way that does not involve an overflow. > Here a small follow

rpki-client refactor some path building

2020-12-03 Thread Claudio Jeker
Use asprintf with %.*s to construct the path based on the mft file location and the filename of the referenced file. Since the * field in printf(3) is expecting an int type, typecast the ptrdiff_t to an int. Add an assert check to make sure there is no overflow. Also do the same overflow check in

Re: hvn(4), hyperv(4): tsleep(9) -> tsleep_nsec(9)

2020-12-03 Thread Andre Stoebe
Hello Scott, I tested this with Hyper-V on Windows 10 and it works fine so far. Regards, Andre OpenBSD 6.8-current (GENERIC.MP) #6: Thu Dec 3 12:54:46 CET 2020 an...@dev.stoe.be:/sys/arch/amd64/compile/GENERIC.MP real mem = 4278124544 (4079MB) avail mem = 4133171200 (3941MB) random: good

rpki-client: use strndup instead of malloc + memcpy

2020-12-03 Thread Claudio Jeker
In tal_parse() use strndup() to create the tal descr instead of the more complex malloc, memcpy version. Result is the same but the strndup version is a lot nicer. OK? -- :wq Claudio Index: tal.c === RCS file:

tcpdump: Don't link to libl and remove reference to yydebug

2020-12-03 Thread Martin Vahlensieck
Hi This is unused. It has been in there since the import from NetBSD. Their logs show that tcpgram.y and tcplex.l have been removed in 1995. I am not sure what the policy is for the getopt(3) call: Should Y be removed in the optstring as well (not done in this diff)? Best, Martin Index: