Re: implement locale(1) charmap argument
On Thu, Apr 16, 2020 at 09:35:18PM +0200, Ingo Schwarze wrote: >$ locale -m > UTF-8 >$ locale charmap > UTF-8 >$ LC_ALL=C locale charmap > US-ASCII >$ LC_ALL=POSIX locale charmap > US-ASCII I am OK with your diff, and noticed a separate issue with -m which is exposed by this change: If US-ASCII is an available charmap, shouldn't locale -m list "US-ASCII" in addition to "UTF-8"?
Re: suggest to run rpki-client hourly
On Thu, Apr 16, 2020 at 05:18:15PM -0600, Theo de Raadt wrote: > Job Snijders wrote: > > > In cases where rpki-client for some reason ends up taking longer than an > > hour, the next execution attempt of the command will be skipped. Better > > to just try again an hour later, this helps avoid concurrent rpki-client > > processes crossing streams. > > Agree. As discussed privately rpki-client has safe output functions, > but the parallel rsync input phase lacks collision prevention. > > > I think 'once an hour' is a reasonable balance between the needs of > > internet users (the ROAs creators who may depend urgently on an > > expedient distribution of updated RPKI information); considerations for > > what the Internet's CA infrastructure realisticly can support; and what > > network operators are willing to tolerate in churn. We have to hold the > > throttle open at the right position. > > I agree we should try 1 hour. > > > +#~ * * * * -s -n rpki-client -v && bgpctl reload > > I would prefer if you use -ns rather than the two seperate options. > ATM crontab -e validation after edit does not like that. -Otto
Re: suggest to run rpki-client hourly
Job Snijders wrote: > In cases where rpki-client for some reason ends up taking longer than an > hour, the next execution attempt of the command will be skipped. Better > to just try again an hour later, this helps avoid concurrent rpki-client > processes crossing streams. Agree. As discussed privately rpki-client has safe output functions, but the parallel rsync input phase lacks collision prevention. > I think 'once an hour' is a reasonable balance between the needs of > internet users (the ROAs creators who may depend urgently on an > expedient distribution of updated RPKI information); considerations for > what the Internet's CA infrastructure realisticly can support; and what > network operators are willing to tolerate in churn. We have to hold the > throttle open at the right position. I agree we should try 1 hour. > +#~ * * * * -s -n rpki-client -v && bgpctl reload I would prefer if you use -ns rather than the two seperate options.
Re: suggest to run rpki-client hourly
Now that cron(8) was put on a quick steroids programme, we have new options available! Awesome work Todd, Theo. On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote: > I'm reviewing some of the timers associated with the workings of the > end-to-end propagation from ROA to VRP. I think suggesting to run > rpki-client only once a day can make for needless brittleness. > > Running rpki-client just once a day also results in only making a rsync > fetch attempt once a day. If the connection can't be established because > of a transient network issue, the RP can easily end up going without > contact with the CA Publication Point for close to 48 hours. A lot of > CRLs appear to have expiration dates in the range of '24 hours'. > > I think attempting to contact a CA PP at least once an hour is more > appropriate for the various 24-48h sliding windows that are in play. In autonomous systems running bgpd(8) and rpki-client(8) on their edge routers, I believe it to be beneficial if out-of-the-box the routers don't all do rpki fetches & bgp loads at the same time. It is expected behavior for RPKI information to un-evenly percolate towards the BGP edge in a staggered way. From a network operational perspective should a support request come in to the ISP, responding "once an hour" will satisfy most situations. In cases where rpki-client for some reason ends up taking longer than an hour, the next execution attempt of the command will be skipped. Better to just try again an hour later, this helps avoid concurrent rpki-client processes crossing streams. I think 'once an hour' is a reasonable balance between the needs of internet users (the ROAs creators who may depend urgently on an expedient distribution of updated RPKI information); considerations for what the Internet's CA infrastructure realisticly can support; and what network operators are willing to tolerate in churn. We have to hold the throttle open at the right position. Anyway, I consider "once an hour" a big upgrade from the decades old "once every 24 hour"-mantra the IRR brought us. :-) Kind regards, Job Index: etc/crontab === RCS file: /cvs/src/etc/crontab,v retrieving revision 1.26 diff -u -p -r1.26 crontab --- etc/crontab 15 Apr 2020 03:24:08 - 1.26 +++ etc/crontab 16 Apr 2020 22:29:16 - @@ -19,4 +19,4 @@ HOME=/var/log 30 5 1 * * /bin/sh /etc/monthly #~ * * * * /usr/libexec/spamd-setup -#0~20 9 * * * -n rpki-client -v && bgpctl reload +#~ * * * * -s -n rpki-client -v && bgpctl reload
Re: patch: Enable dock audio on Thinkpad dock (Thinkpad L460)
On Tuesday, February 11, 2020, Abel Abraham Camarillo Ojeda < acam...@verlet.org> wrote: > > > On Wednesday, January 8, 2020, Abel Abraham Camarillo Ojeda < > acam...@verlet.org> wrote: > >> >> >> On Mon, Dec 30, 2019 at 1:24 PM Abel Abraham Camarillo Ojeda < >> acam...@verlet.org> wrote: >> >>> The following enables audio via the dock station port in my thinkpad >>> L460. >>> But, anyone knows if its possible to automatically disable the laptop >>> speaker >>> when I plug in the audio port in the dock? it doesn't appear to have a >>> *_sense, >>> ideas? >>> >>> this also enables the annoying beep (echo -e "\a"; in console) >>> >>> patch inline and attached: >>> >> >> Hi, comments, oks? >> > > Anyone? > > regards > Hi, any ok, comments? Regards > > >> >> Thanks >> >> >>> Index: azalia_codec.c >>> === >>> RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v >>> retrieving revision 1.178 >>> diff -u -p -r1.178 azalia_codec.c >>> --- azalia_codec.c 14 Oct 2019 02:04:35 - 1.178 >>> +++ azalia_codec.c 30 Dec 2019 19:06:16 - >>> @@ -159,6 +159,17 @@ azalia_codec_init_vtbl(codec_t *this) >>> this->subid == 0x503c17aa) >>> this->qrks |= AZ_QRK_WID_TPDOCK2; >>> break; >>> + case 0x10ec0293: >>> + this->name = "Realtek ALC293"; >>> + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; >>> + >>> + /* >>> +* Enable dock audio on Thinkpad docks >>> +* 0x17aa : 0x5051 = Thinkpad L460 >>> +*/ >>> + if (this->subid == 0x505117aa) >>> + this->qrks |= AZ_QRK_WID_TPDOCK2; >>> + break; >>> case 0x10ec0298: >>> this->name = "Realtek ALC298"; >>> if (this->subid == 0x320019e5 || >>> >>> mixerctl diff: >>> >>> --- tmp/mixerctl_orig Mon Dec 30 12:08:15 2019 >>> +++ tmp/mixerctl_patch Mon Dec 30 12:06:22 2019 >>> @@ -1,35 +1,41 @@ >>> -inputs.dac-0:1=126,126 >>> -inputs.dac-2:3=126,126 >>> +inputs.dac-0:1=174,174 >>> +inputs.dac-2:3=174,174 >>> inputs.mic2=85,85 >>> inputs.mic=85,85 >>> inputs.mix2_source=dac-2:3,mix >>> inputs.mix3_source=dac-0:1,mix >>> inputs.mix_mic2=120,120 >>> -inputs.mix_source=mic2 >>> +inputs.mix_source=spkr3,mic2 >>> +inputs.mix_spkr3=120,120 >>> +inputs.spkr3=85,85 >>> outputs.hp_boost=off >>> outputs.hp_eapd=on >>> outputs.hp_mute=off >>> outputs.hp_sense=unplugged >>> outputs.hp_source=mix3 >>> outputs.master.mute=off >>> -outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp >>> -outputs.master=126,126 >>> +outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp,spkr2 >>> +outputs.master=190,190 >>> outputs.mic2_dir=input-vr80 >>> outputs.mic2_sense=unplugged >>> +outputs.spkr2_boost=off >>> +outputs.spkr2_eapd=on >>> +outputs.spkr2_mute=off >>> +outputs.spkr2_source=mix2 >>> outputs.spkr_eapd=on >>> outputs.spkr_mute=off >>> outputs.spkr_muters=hp >>> outputs.spkr_source=mix2 >>> record.adc-0:1=124,124 >>> record.adc-0:1_mute=off >>> record.adc-0:1_source=mic >>> record.adc-2:3=124,124 >>> record.adc-2:3_mute=off >>> -record.adc-2:3_source=mic2 >>> +record.adc-2:3_source=spkr3 >>> record.adc-4:5=124,124 >>> record.adc-4:5_mute=off >>> -record.adc-4:5_source=mic2 >>> +record.adc-4:5_source=spkr3 >>> record.enable=sysctl >>> record.volume.mute=off >>> record.volume.slaves=adc-0:1,adc-2:3,adc-4:5 >>> record.volume=124,124 >>> >>> dmesg: >>> >>> OpenBSD 6.6-current (GENERIC.MP) #9: Mon Dec 30 13:01:52 CST 2019 >>> acam...@merced.00z.us:/usr/obj/sys/arch/amd64/compile/GENERIC.MP >>> real mem = 17028538368 (16239MB) >>> avail mem = 16491659264 (15727MB) >>> mpath0 at root >>> scsibus0 at mpath0: 256 targets >>> mainbus0 at root >>> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd705d000 (63 entries) >>> bios0: vendor LENOVO version "R08ET64W (1.38 )" date 05/02/2019 >>> bios0: LENOVO 20FVA09400 >>> acpi0 at bios0: ACPI 5.0 >>> acpi0: sleep states S0 S3 S4 S5 >>> acpi0: tables DSDT FACP UEFI SSDT ECDT HPET APIC MCFG SSDT DBGP DBG2 >>> BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI >>> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) XHCI(S3) >>> acpitimer0 at acpi0: 3579545 Hz, 24 bits >>> acpiec0 at acpi0 >>> acpihpet0 at acpi0: 2399 Hz >>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >>> cpu0 at mainbus0: apid 0 (boot processor) >>> cpu0: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz, 2195.54 MHz, 06-4e-03 >>> cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO >>> V,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE, >>> SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA >>> 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA >>> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG, >>> LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1, >>> HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP, >>> CLFLUSHOPT,PT,MD_
Re: implement locale(1) charmap argument
Makes sense to me. OK millert@ - todd
distrib/notes/arm64/prep update
any comments? ok?
Index: prep
===
RCS file: /cvs/src/distrib/notes/arm64/prep,v
retrieving revision 1.9
diff -u -p -r1.9 prep
--- prep15 Apr 2020 11:41:08 - 1.9
+++ prep16 Apr 2020 20:29:56 -
@@ -24,11 +24,11 @@ Booting from an SD card:
storage devices. Under OpenBSD, it will appear as a ``sd'' device, for
example sd1.
- Use the dd(1) utility to copy the miniroot to the hard drive.
+ Use the dd(1) utility to copy the miniroot to the SD card.
The command would likely be, under OpenBSD:
dd if=miniroot{:--:}OSrev.fs of=/dev/rsd1c bs=1m
- When you have connected the serial to you computer, a command such
+ When you have connected the serial to your computer, a command such
as "cu -l cuaU0 -s 115200" (assuming cuaU0 is your serial port device)
should connect you to the board's console.
@@ -48,6 +48,35 @@ script.
=> bootefi ${kernel_addr_r} ${fdt_addr_r}
The bootloader will then run and try to load sd0a:/bsd off an FFS
filesystem after a timeout.
+
+Install on Raspberry Pi 4:
+
+ You will need a microSD card (only a small one is needed), a USB
+ storage device, a TTL serial interface adapter (e.g. CP2102 USB-UART
+ converter), and a cable to attach this to the TXD/RXD/GND pins on the
+ https://pinout.xyz/ header on the board.
+
+ Follow the installation instructions at https://github.com/pftf/RPi4
+ to install UEFI firmware to a FAT-formatted microSD card.
+
+ Use the dd(1) utility to copy the miniroot to the USB storage device.
+ The command would likely be, under OpenBSD:
+ dd if=miniroot{:--:}OSrev.fs of=/dev/rsd1c bs=1m
+
+ When you have connected the serial to your computer, a command such
+ as "cu -l cuaU0 -s 115200" (assuming cuaU0 is your serial port device)
+ should connect you to the board's console.
+
+ Shortly after powering the board, you should see messages on the serial
+ console starting with "Initialising SDRAM" followed by messages from the
+ UEFI firmware. If you have a monitor connected to the HDMI port, you
+ should see a multi-coloured screen followed by UEFI firmware output.
+ If you do not see this, re-check your UEFI firmware installation.
+
+ OpenBSD should boot automatically soon after loading the UEFI firmware.
+ If a monitor is connected you will see messages from the boot loader,
+ but after the kernel has started running you will only see output on
+ the serial console.
Install on systems without a supported miniroot:
implement locale(1) charmap argument
Hi,
our locale(1) implementation is intentionally simplistic
and implements only a subset of this POSIX specification:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/locale.html
However, one feature is missing that is actually useful and arguably
also well-placed inside the locale(1) utility. If you want to know
from within a C program which character encoding is actually being
used (as opposed to which one the user requested), you can use the
nl_langinfo(3) function. But i'm not aware of a possibiliy to ask
the same from within a sh(1) program.
POSIX says that "locale charmap" should answer that question.
In the next release of textproc/groff, that feature of locale(1)
will be used in the test suite, and it seems reasonable to do so.
So, here is a very simple patch to support the "charmap" argument.
Testing:
$ export LC_CTYPE=en_US.UTF-8
$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE=en_US.UTF-8
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=
$ locale -a | wc
68 68 794
$ locale -m
UTF-8
$ locale charmap
UTF-8
$ LC_ALL=C locale charmap
US-ASCII
$ LC_ALL=POSIX locale charmap
US-ASCII
$ LC_ALL=NonSense locale charmap
US-ASCII
$ locale -x
locale: unknown option -- x
usage: locale [-a | -m | charmap]
$ locale nonsense
usage: locale [-a | -m | charmap]
$ locale -am
usage: locale [-a | -m | charmap]
$ locale -a charmap
usage: locale [-a | -m | charmap]
$ locale -m charmap
usage: locale [-a | -m | charmap]
$ locale charmap nonsense
usage: locale [-a | -m | charmap]
OK?
Ingo
P.S.
It would be trivial to also support the POSIX -k option, as in
$ locale -k charmap
charmap="UTF-8"
but that doesn't actually feel useful and i'm not aware of anything
that might want to use it, so KISS and let's proceed one step at a time.
Supporting "name" arguments other than "charmap" would make little
sense on OpenBSD, nor would the -c option.
Index: locale.1
===
RCS file: /cvs/src/usr.bin/locale/locale.1,v
retrieving revision 1.7
diff -u -p -r1.7 locale.1
--- locale.126 Oct 2016 01:00:27 - 1.7
+++ locale.116 Apr 2020 19:04:25 -
@@ -1,6 +1,6 @@
.\" $OpenBSD: locale.1,v 1.7 2016/10/26 01:00:27 schwarze Exp $
.\"
-.\" Copyright 2016 Ingo Schwarze
+.\" Copyright 2016, 2020 Ingo Schwarze
.\" Copyright 2013 Stefan Sperling
.\"
.\" Permission to use, copy, modify, and distribute this software for any
@@ -23,7 +23,7 @@
.Nd character encoding and localization conventions
.Sh SYNOPSIS
.Nm locale
-.Op Fl a | Fl m
+.Op Fl a | Fl m | Cm charmap
.Sh DESCRIPTION
If the
.Nm
@@ -31,7 +31,7 @@ utility is invoked without any arguments
configuration is shown.
.Pp
The options are as follows:
-.Bl -tag -width Ds
+.Bl -tag -width charmap
.It Fl a
Display a list of supported locales.
.It Fl m
@@ -39,6 +39,11 @@ Display a list of supported character en
On
.Ox ,
this always returns UTF-8 only.
+.It Cm charmap
+Display the currently selected character encoding.
+On
+.Ox ,
+this returns either US-ASCII or UTF-8.
.El
.Pp
A locale is a set of environment variables telling programs which
Index: locale.c
===
RCS file: /cvs/src/usr.bin/locale/locale.c,v
retrieving revision 1.12
diff -u -p -r1.12 locale.c
--- locale.c5 Feb 2016 12:59:12 - 1.12
+++ locale.c16 Apr 2020 19:04:25 -
@@ -16,6 +16,7 @@
*/
#include
+#include
#include
#include
#include
@@ -169,7 +170,7 @@ show_locales(void)
static void
usage(void)
{
- fprintf(stderr, "usage: %s [-a | -m]\n", __progname);
+ fprintf(stderr, "usage: %s [-a | -m | charmap]\n", __progname);
exit(1);
}
@@ -203,12 +204,16 @@ main(int argc, char *argv[])
argc -= optind;
argv += optind;
- if (argc != 0 || (aflag && mflag))
+ if (aflag + mflag + argc > 1)
usage();
else if (aflag)
show_locales();
else if (mflag)
printf("UTF-8\n");
+ else if (strcmp(*argv, "charmap") == 0)
+ printf("%s\n", nl_langinfo(CODESET));
+ else
+ usage();
return 0;
}
Re: Some small nits with httpd and relayd and a relayd question
On 2020-04-16 18:34, Kevin Chadwick wrote: > If httpd is put in front of a reverse proxy of grafana. I seem to get some > http/1.1 js requests become http/1.0 bad requests. I should add that this was with httpd fcgi. So it may just be, my bad.
Some small nits with httpd and relayd and a relayd question
If httpd is put in front of a reverse proxy of grafana. I seem to get some http/1.1 js requests become http/1.0 bad requests. Perhaps related "http://daemonforums.org/showthread.php?p=68392"; With relayd there is no problem. However relayd seems to not like the nistp521 keys that httpd was quite happy with. I get "key size 1128 not support" from relayd https://cvsweb.openbsd.org/src/usr.sbin/relayd/ssl.c?rev=1.34&content-type=text/x-cvsweb-markup The tls priv sep is the main reason I am using relayd/httpd, so I am not complaining about this hack. Gos http server is good but doesn't protect the key, so well. I assume switching to RSA, is the only answer? Anything below nistp521 would be more prone than RSA to quantum attacks, if they ever actually happen anyway. Or is there a diff for httpd that could be adapted to relayd?
Re: rpki-client: replace deprecated ERR_remove_state
Claudio Jeker wrote: > On Thu, Apr 16, 2020 at 09:45:45AM -0600, Theo de Raadt wrote: > > I don't understand the point of any of this cleanup. The process > > is dying and none of these things maintain external state. > > > > I'm going to call it what it is: stylistically stupid and rigid. > > > > Why? Because it would mean every call to errx() in the program is > > wrong because they don't attempt this, and only this one exit() call > > needs this kind of cleanup. That is simply not plausible. > > Indeed, also I noticed that ERR_remove_thread_state() was deprecated in > OpenSSL 1.1 and so I'm kind of back to square 1 again regarding the use of > deprecated functions. > > All this cleanup before exit(3) is done mostly to please runtime memory > leak checkers. > > Also EVP_cleanup() and ERR_free_strings() are deprecated according to > their man page. There is no documentation for CRYPTO_cleanup_all_ex_data() > but looking at the code it seems to be not important. > > Removing all of them seems to be the best move forward. I'd like to add one more point for others following along in the public: Please don't ever use atexit() for this kind of stuff. On OpenBSD, atexit() has some self-protecting safety features, but those don't exist on other systems. As many, once a program does one atexit() call, if a bug is found to corrupt the atexit memory chain in libc, nasty stuff can be done. People should treat atexit like a loaded gun.
Re: rpki-client: replace deprecated ERR_remove_state
Claudio Jeker wrote: > On Thu, Apr 16, 2020 at 09:45:45AM -0600, Theo de Raadt wrote: > > I don't understand the point of any of this cleanup. The process > > is dying and none of these things maintain external state. > > > > I'm going to call it what it is: stylistically stupid and rigid. > > > > Why? Because it would mean every call to errx() in the program is > > wrong because they don't attempt this, and only this one exit() call > > needs this kind of cleanup. That is simply not plausible. > > Indeed, also I noticed that ERR_remove_thread_state() was deprecated in > OpenSSL 1.1 and so I'm kind of back to square 1 again regarding the use of > deprecated functions. > > All this cleanup before exit(3) is done mostly to please runtime memory > leak checkers. Which suggests people aren't actually fuzzing the programs via the errx() paths? I don't believe it. I don't think this was done to please a runtime memory leak checker, I think it was done proactively as a "style choice" in the belief it will please a runtime memory leak checker. So it is waiting for the plane to drop the box in exactly the same place as last time.
Re: rpki-client: replace deprecated ERR_remove_state
On Thu, Apr 16, 2020 at 09:45:45AM -0600, Theo de Raadt wrote: > I don't understand the point of any of this cleanup. The process > is dying and none of these things maintain external state. > > I'm going to call it what it is: stylistically stupid and rigid. > > Why? Because it would mean every call to errx() in the program is > wrong because they don't attempt this, and only this one exit() call > needs this kind of cleanup. That is simply not plausible. Indeed, also I noticed that ERR_remove_thread_state() was deprecated in OpenSSL 1.1 and so I'm kind of back to square 1 again regarding the use of deprecated functions. All this cleanup before exit(3) is done mostly to please runtime memory leak checkers. Also EVP_cleanup() and ERR_free_strings() are deprecated according to their man page. There is no documentation for CRYPTO_cleanup_all_ex_data() but looking at the code it seems to be not important. Removing all of them seems to be the best move forward. > Claudio Jeker wrote: > > > ERR_remove_state(0) is deprecated use the new api > > ERR_remove_thread_state(NULL) instead. > > > > -- > > :wq Claudio > > > > Index: main.c > > === > > RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v > > retrieving revision 1.61 > > diff -u -p -r1.61 main.c > > --- main.c 1 Apr 2020 14:15:49 - 1.61 > > +++ main.c 16 Apr 2020 10:01:56 - > > @@ -1250,7 +1250,7 @@ out: > > > > EVP_cleanup(); > > CRYPTO_cleanup_all_ex_data(); > > - ERR_remove_state(0); > > + ERR_remove_thread_state(NULL); > > ERR_free_strings(); > > > > exit(rc); > > > -- :wq Claudio
Re: cron: support single instance jobs
Hey,
i think this is a brilliant idea and it would remove a lot of bloat from
my scripts. So i gave your code a try on the latest snapshot and it
worked very well. Thanks for this!
Thanks and greetings
Leo
Am 16.04.2020 um 16:56 schrieb Todd C. Miller:
One annoying issue with cron is that it has no way to prevent jobs
from being run concurrently. As a result, cron jobs have to do
their own locking to prevent concurrent execution.
The following adds a "-s" flag to the command field which indicates
that only a single instance of the job should run concurrenty.
- todd
Index: usr.sbin/cron/cron.c
===
RCS file: /cvs/src/usr.sbin/cron/cron.c,v
retrieving revision 1.78
diff -u -p -u -r1.78 cron.c
--- usr.sbin/cron/cron.c11 Feb 2020 12:42:01 - 1.78
+++ usr.sbin/cron/cron.c15 Apr 2020 22:17:15 -
@@ -497,6 +497,7 @@ sigchld_reaper(void)
case 0:
break;
default:
+ job_exit(pid);
break;
}
} while (pid > 0);
Index: usr.sbin/cron/crontab.5
===
RCS file: /cvs/src/usr.sbin/cron/crontab.5,v
retrieving revision 1.38
diff -u -p -u -r1.38 crontab.5
--- usr.sbin/cron/crontab.5 15 Apr 2020 01:59:34 - 1.38
+++ usr.sbin/cron/crontab.5 16 Apr 2020 13:15:49 -
@@ -217,6 +217,13 @@ option is an attempt to cure potentially
.Xr cron 8 .
.It Fl q Ar command
Execution will not be logged.
+.It Fl s Ar command
+Only a single instance of
+.Ar command
+will be run concurrently.
+Additional instances of
+.Ar command
+will not be scheduled until the earlier one completes.
.El
.Pp
Commands are executed by
Index: usr.sbin/cron/do_command.c
===
RCS file: /cvs/src/usr.sbin/cron/do_command.c,v
retrieving revision 1.60
diff -u -p -u -r1.60 do_command.c
--- usr.sbin/cron/do_command.c 28 Jun 2019 13:32:47 - 1.60
+++ usr.sbin/cron/do_command.c 15 Apr 2020 22:56:32 -
@@ -47,9 +47,10 @@
static void child_process(entry *, user *);
-void
+pid_t
do_command(entry *e, user *u)
{
+ pid_t pid;
/* fork to become asynchronous -- parent process is done immediately,
* and continues to run the normal cron code, which means return to
@@ -58,7 +59,7 @@ do_command(entry *e, user *u)
* vfork() is unsuitable, since we have much to do, and the parent
* needs to be able to run off and fork other processes.
*/
- switch (fork()) {
+ switch ((pid = fork())) {
case -1:
syslog(LOG_ERR, "(CRON) CAN'T FORK (%m)");
break;
@@ -69,8 +70,13 @@ do_command(entry *e, user *u)
break;
default:
/* parent process */
+ if ((e->flags & SINGLE_JOB) == 0)
+ pid = -1;
break;
}
+
+ /* only return pid if a singleton */
+ return (pid);
}
static void
Index: usr.sbin/cron/entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 entry.c
--- usr.sbin/cron/entry.c 15 Apr 2020 01:59:34 - 1.50
+++ usr.sbin/cron/entry.c 15 Apr 2020 20:08:50 -
@@ -354,6 +354,14 @@ load_entry(FILE *file, void (*error_func
}
e->flags |= DONT_LOG;
break;
+ case 's':
+ /* only allow the user to set the option once */
+ if ((e->flags & SINGLE_JOB) == SINGLE_JOB) {
+ ecode = e_option;
+ goto eof;
+ }
+ e->flags |= SINGLE_JOB;
+ break;
default:
ecode = e_option;
goto eof;
Index: usr.sbin/cron/funcs.h
===
RCS file: /cvs/src/usr.sbin/cron/funcs.h,v
retrieving revision 1.29
diff -u -p -u -r1.29 funcs.h
--- usr.sbin/cron/funcs.h 5 Feb 2018 03:52:37 - 1.29
+++ usr.sbin/cron/funcs.h 16 Apr 2020 13:19:32 -
@@ -24,7 +24,8 @@
void load_database(cron_db **),
job_add(entry *, user *),
- do_command(entry *, user *),
+ job_remove(entry *, user *),
+ job_exit(pid_t),
free_user(user *),
env_free(char **),
unget_char(int, FILE *),
@@ -32,6 +33,8 @@ void load_database(cron_db **),
skip_comments(FILE *),
poke_daemon(unsigned char),
atrun(at_db *, double, time_t);
+
+pid_t do_command(entry *, user *);
int
Re: cleanup an bad and unneeded typecast in rpki-client
On Thu, 16 Apr 2020 12:00:04 +0200, Claudio Jeker wrote: > There is a bit of strange code in the ip parser of rpki-client to parse > the AFI. This is a 2byte network byte order value. Instead of using a a > char buf and a short just do everything with a one uint16_t. The current > code does *(uint16_t)buf which is not save since buf is a char array. > Lucky us that the stack ends up enough aligned that this code does not > blow up on strict align archs. Still fix is simple and makes the code much > cleaner. OK millert@ - todd
Re: rpki-client: replace deprecated ERR_remove_state
I don't understand the point of any of this cleanup. The process is dying and none of these things maintain external state. I'm going to call it what it is: stylistically stupid and rigid. Why? Because it would mean every call to errx() in the program is wrong because they don't attempt this, and only this one exit() call needs this kind of cleanup. That is simply not plausible. Claudio Jeker wrote: > ERR_remove_state(0) is deprecated use the new api > ERR_remove_thread_state(NULL) instead. > > -- > :wq Claudio > > Index: main.c > === > RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v > retrieving revision 1.61 > diff -u -p -r1.61 main.c > --- main.c1 Apr 2020 14:15:49 - 1.61 > +++ main.c16 Apr 2020 10:01:56 - > @@ -1250,7 +1250,7 @@ out: > > EVP_cleanup(); > CRYPTO_cleanup_all_ex_data(); > - ERR_remove_state(0); > + ERR_remove_thread_state(NULL); > ERR_free_strings(); > > exit(rc); >
randomize daily/weekly/monthly crons
Really like the ~ feature in cron. I'm moving every machine that gets updated to -current to use this for the daily/weekly/monthly crons, so they are randomized in the 30 minute window after the original start time. Especially useful on machines running a few (or more) VMs. Something (or something like it) to consider for inclusion? Thank you for a very useful addition! Paul Index: crontab === RCS file: /home/OpenBSD/cvs/src/etc/crontab,v retrieving revision 1.26 diff -u -p -r1.26 crontab --- crontab 15 Apr 2020 03:24:08 - 1.26 +++ crontab 16 Apr 2020 15:05:22 - @@ -14,9 +14,9 @@ HOME=/var/log #1-59 * * * * /usr/bin/newsyslog -m # # do daily/weekly/monthly maintenance -30 1 * * * /bin/sh /etc/daily -30 3 * * 6 /bin/sh /etc/weekly -30 5 1 * * /bin/sh /etc/monthly +30~1 * * * /bin/sh /etc/daily +30~3 * * 6 /bin/sh /etc/weekly +30~5 1 * * /bin/sh /etc/monthly #~ * * * * /usr/libexec/spamd-setup #0~20 9 * * * -n rpki-client -v && bgpctl reload -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
cron: support single instance jobs
One annoying issue with cron is that it has no way to prevent jobs
from being run concurrently. As a result, cron jobs have to do
their own locking to prevent concurrent execution.
The following adds a "-s" flag to the command field which indicates
that only a single instance of the job should run concurrenty.
- todd
Index: usr.sbin/cron/cron.c
===
RCS file: /cvs/src/usr.sbin/cron/cron.c,v
retrieving revision 1.78
diff -u -p -u -r1.78 cron.c
--- usr.sbin/cron/cron.c11 Feb 2020 12:42:01 - 1.78
+++ usr.sbin/cron/cron.c15 Apr 2020 22:17:15 -
@@ -497,6 +497,7 @@ sigchld_reaper(void)
case 0:
break;
default:
+ job_exit(pid);
break;
}
} while (pid > 0);
Index: usr.sbin/cron/crontab.5
===
RCS file: /cvs/src/usr.sbin/cron/crontab.5,v
retrieving revision 1.38
diff -u -p -u -r1.38 crontab.5
--- usr.sbin/cron/crontab.5 15 Apr 2020 01:59:34 - 1.38
+++ usr.sbin/cron/crontab.5 16 Apr 2020 13:15:49 -
@@ -217,6 +217,13 @@ option is an attempt to cure potentially
.Xr cron 8 .
.It Fl q Ar command
Execution will not be logged.
+.It Fl s Ar command
+Only a single instance of
+.Ar command
+will be run concurrently.
+Additional instances of
+.Ar command
+will not be scheduled until the earlier one completes.
.El
.Pp
Commands are executed by
Index: usr.sbin/cron/do_command.c
===
RCS file: /cvs/src/usr.sbin/cron/do_command.c,v
retrieving revision 1.60
diff -u -p -u -r1.60 do_command.c
--- usr.sbin/cron/do_command.c 28 Jun 2019 13:32:47 - 1.60
+++ usr.sbin/cron/do_command.c 15 Apr 2020 22:56:32 -
@@ -47,9 +47,10 @@
static voidchild_process(entry *, user *);
-void
+pid_t
do_command(entry *e, user *u)
{
+ pid_t pid;
/* fork to become asynchronous -- parent process is done immediately,
* and continues to run the normal cron code, which means return to
@@ -58,7 +59,7 @@ do_command(entry *e, user *u)
* vfork() is unsuitable, since we have much to do, and the parent
* needs to be able to run off and fork other processes.
*/
- switch (fork()) {
+ switch ((pid = fork())) {
case -1:
syslog(LOG_ERR, "(CRON) CAN'T FORK (%m)");
break;
@@ -69,8 +70,13 @@ do_command(entry *e, user *u)
break;
default:
/* parent process */
+ if ((e->flags & SINGLE_JOB) == 0)
+ pid = -1;
break;
}
+
+ /* only return pid if a singleton */
+ return (pid);
}
static void
Index: usr.sbin/cron/entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 entry.c
--- usr.sbin/cron/entry.c 15 Apr 2020 01:59:34 - 1.50
+++ usr.sbin/cron/entry.c 15 Apr 2020 20:08:50 -
@@ -354,6 +354,14 @@ load_entry(FILE *file, void (*error_func
}
e->flags |= DONT_LOG;
break;
+ case 's':
+ /* only allow the user to set the option once */
+ if ((e->flags & SINGLE_JOB) == SINGLE_JOB) {
+ ecode = e_option;
+ goto eof;
+ }
+ e->flags |= SINGLE_JOB;
+ break;
default:
ecode = e_option;
goto eof;
Index: usr.sbin/cron/funcs.h
===
RCS file: /cvs/src/usr.sbin/cron/funcs.h,v
retrieving revision 1.29
diff -u -p -u -r1.29 funcs.h
--- usr.sbin/cron/funcs.h 5 Feb 2018 03:52:37 - 1.29
+++ usr.sbin/cron/funcs.h 16 Apr 2020 13:19:32 -
@@ -24,7 +24,8 @@
void load_database(cron_db **),
job_add(entry *, user *),
- do_command(entry *, user *),
+ job_remove(entry *, user *),
+ job_exit(pid_t),
free_user(user *),
env_free(char **),
unget_char(int, FILE *),
@@ -32,6 +33,8 @@ void load_database(cron_db **),
skip_comments(FILE *),
poke_daemon(unsigned char),
atrun(at_db *, double, time_t);
+
+pid_t do_command(entry *, user *);
intjob_runqueue(void),
get_char(FILE *),
Index: usr.sbin/cron/job.c
===
RCS file: /cvs/src/usr.sbin/cron/job.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 job.c
--- usr.
Re: Update www/groups.html
Hi, clematis wrote on Thu, Apr 16, 2020 at 12:53:19PM +0200: > Hello, > Here's a few suggestions to update www/groups.html > I was checking if all those links were still existing/active/valid. Thanks, both for doing the checks and providing details about what exactly you did. > Does anyone has any questions or concerns removing those? I guess if > no-one react within another week we can consider this as "groups > timeout". Given that you already waited for feedback from the group contacts to no avail, i simply committed the change. If somebody speaks up on the list providing a new web address showing recent activity and a new, working contact for some group, we can always put the new information in. I find it easier that way than trying to keep track of uncommitted patches. > It's the first time I am looking at something else than ports/ so > here is what I've done: > - remove the lines from build/groups.dat > - run make > no error , look at groups.html - changes looked good. In that step, i usually do "make ../groups.html". > - run a cvs diff on groups.html to read it for sanity check - looked OK. > - check via browser locally. OK. > - cvs diff -uNp groups.dat > www_build_groups.dat.diff (see > attached and hopefully that's what you meant by "emailing you the > changes in the form of SUPPORT.TEMPLATE") > > Please let me know if I've missed a step or anything else that should be > done. That's fine, i'd do more or less the same in such a case. Yours, Ingo
Update www/groups.html
Hello, Here's a few suggestions to update www/groups.html I was checking if all those links were still existing/active/valid. 1/ Removing the groups listed in India for the reason below: - Jharkhand (India) http://www.arithme.net doesn't look like an openbsd user group... I've been digging the waybackmachine (web.archive.org) down to 2004 but could never see any *bsd reference or group like activity. I've emailed the admin contact but didn't get any response. - OpenBSD INDIA The facebook link is broken. I've emailed both contact provided. One of them (Ashish Rai) replied confirming there's no local group activities or contact with other local users. There's no website either. 2/ Removing Openbeer / Italy News/activity stopped in 2008. Website has changed to this current default provider page somehwere in 2016/2017 I've sent an email to the listed owner but I haven't heard anything back. 3/ Removing LWFUG / Wyoming Website not accessible - seems to had redirects and not found since end of 2017. Emailed the contact but no answer. Does anyone has any questions or concerns removing those? I guess if no-one react within another week we can consider this as "groups timeout". It's the first time I am looking at something else than ports/ so here is what I've done: - remove the lines from build/groups.dat - run make no error , look at groups.html - changes looked good. - run a cvs diff on groups.html to read it for sanity check - looked OK. - check via browser locally. OK. - cvs diff -uNp groups.dat > www_build_groups.dat.diff (see attached and hopefully that's what you meant by "emailing you the changes in the form of SUPPORT.TEMPLATE") Please let me know if I've missed a step or anything else that should be done. PS: I am still having open actions before sending suggestion to update www/mail.html and www/support.html - just FYI that will come later in separated email thread. Comments? Ok? Thanks. Regards, -- clematis (0x7e96fd2400fe7b59) Index: groups.dat === RCS file: /cvs/www/build/groups.dat,v retrieving revision 1.146 diff -u -p -u -p -r1.146 groups.dat --- groups.dat 23 Nov 2019 16:14:03 - 1.146 +++ groups.dat 16 Apr 2020 09:57:37 - @@ -113,40 +113,6 @@ F Irregular N *BSD -# Start of India -0 -C India -P Jharkhand -T Ranchi -F Irregular -O Jharkhand OpenBSD -I Mungal Lal Shaw -M mu...@arithme.net -U http://www.arithme.net -N OpenBSD - -0 -C India -P Uttar Pradesh -T Varanasi -F Irregular -O OpenBSD INDIA -I Ashish Kumar Rai -M raiashis...@gmail.com -U http://facebook.com/raiashishkumar -N OpenBSD - -0 -C India -P Uttar Pradesh -T Allahabad -F Irregular -O OpenBSD INDIA -I Sanjai Verma -M verma.san...@gmail.com -N OpenBSD - - # Start of Iran 0 C Iran @@ -181,18 +147,6 @@ U https://www.irbug.org/ N *BSD -# Start of Italy -0 -C Italy -T Venice -O Beer OpenBSD User Group -I Fabio Cazzin -M fa...@openbeer.it -U http://www.OpenBEER.it -F Irregular -N OpenBSD - - # Start of Japan 0 C Japan @@ -371,17 +325,6 @@ I James Rieve M bugo...@gmail.com U http://sites.google.com/site/bugortn/Home F Every Sunday at 2:00PM -N *BSD - -0 -C USA -P Wyoming -T Laramie -O Laramie Wyoming Freenix Users Group(LWFUG) -I Russ Ingram -M ring...@gargoylecc.com -U http://www.lwfug.org -F Irregular N *BSD
Re: sysupgrade: add BUILDINFO file to fetched files
On 2020/04/13 08:44, Mikolaj Kucharski wrote:
> Hi,
>
> Would below be okay?
>
> On Tue, Apr 07, 2020 at 04:46:38AM +, Mikolaj Kucharski wrote:
> > Hi,
> >
> > When I'm upgrading my machines, I find it useful to have BUILDINFO
> > file around. Tested on RPi3.
> >
> > Please carbon-copy me in any replies. Thank you.
> >
> > openbsd-rpi# sysupgrade -s -n
> > Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/
> > SHA256.sig 100% |**| 1453 00:00
> > Signature Verified
> > Verifying old sets.
> > BUILDINFO100% |**|54 00:00
> > Verifying sets.
> > Fetching updated firmware.
> > Will upgrade on next reboot
> >
> > openbsd-rpi# reboot
> > ... [successfull upgrade]
> > openbsd-rpi# ls -1A /home/_sysupgrade/ | wc -l
> >0
> >
> >
> > OpenBSD 6.6-current (GENERIC.MP) #513: Wed Mar 18 16:41:35 MDT 2020
> > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> >
> > Index: sysupgrade.sh
> > ===
> > RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> > retrieving revision 1.37
> > diff -u -p -u -r1.37 sysupgrade.sh
> > --- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
> > +++ sysupgrade.sh 20 Mar 2020 06:30:51 -
> > @@ -152,9 +152,9 @@ if cmp -s /var/db/installed.SHA256 SHA25
> > exit 0
> > fi
> >
> > -# INSTALL.*, bsd*, *.tgz
> > +# BUILDINFO, INSTALL.*, bsd*, *.tgz
> > SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
> > --e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
> > +-e '/^BUILDINFO$/p;/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
> >
> > OLD_FILES=$(ls)
> > OLD_FILES=$(rmel SHA256 $OLD_FILES)
> >
>
> --
> Regards,
> Mikolaj
>
Rather than downloading it and deleting it again, it would be more
useful if BUILDINFO was kept around after installing. Then sysupgrade
could check to make sure it isn't going backwards with a future update.
(e.g. if some malicious mirror or mitm intentionally serves an old
snapshot [with a good signature] to prevent users getting a security
fix).
I started looking at this a while ago and have had this in my tree (I'd
forgotten about until I just did a cvs up) - maybe worth some more thought
(it's not super-robust but I'm not sure if it needs to be..) ENOTIME to
look at it more now though.
Index: usr.sbin/sysupgrade/sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.37
diff -u -p -r1.37 sysupgrade.sh
--- usr.sbin/sysupgrade/sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
+++ usr.sbin/sysupgrade/sysupgrade.sh 16 Apr 2020 10:40:37 -
@@ -131,6 +131,7 @@ cd ${SETSDIR}
echo "Fetching from ${URL}"
unpriv -f SHA256.sig ftp -N sysupgrade -Vmo SHA256.sig ${URL}SHA256.sig
+unpriv -f BUILDINFO ftp -N sysupgrade -Vmo BUILDINFO ${URL}BUILDINFO
_KEY=openbsd-${_KERNV[0]%.*}${_KERNV[0]#*.}-base.pub
_NEXTKEY=openbsd-${NEXT_VERSION%.*}${NEXT_VERSION#*.}-base.pub
@@ -147,11 +148,26 @@ esac
unpriv -f SHA256 signify -Ve -p "${SIGNIFY_KEY}" -x SHA256.sig -m SHA256
rm SHA256.sig
+unpriv cksum -qC SHA256 BUILDINFO
+
if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then
echo "Already on latest snapshot."
exit 0
fi
+if [[ -r /var/db/installed.BUILDINFO ]] && ! $FORCE; then
+ read _skip _skip _oldbuildtime _skip < /var/db/installed.BUILDINFO
+ read _skip _skip _newbuildtime _skip < BUILDINFO
+ if [[ $_newbuildtime -lt $_oldbuildtime ]]; then
+ echo "Snapshot on mirror is older than installed version!"
+ exit 1
+ fi
+ if [[ $_newbuildtime -eq $_oldbuildtime ]]; then
+ echo "Already on latest snapshot? Mismatch between BUILDINFO
and SHA256?"
+ exit 1
+ fi
+fi
+
# INSTALL.*, bsd*, *.tgz
SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
-e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
@@ -187,9 +203,14 @@ Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes
__EOT
+# XXX should be done in bsd.rd so that this is present for a clean install too
+cat <<__EOT > /etc/rc.firsttime
+cp /home/_sysupgrade/BUILDINFO /var/db/installed.BUILDINFO
+__EOT
+
if ! ${KEEP}; then
CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
- cat <<__EOT > /etc/rc.firsttime
+ cat <<__EOT >> /etc/rc.firsttime
rm -f /home/_sysupgrade/{${CLEAN}}
__EOT
fi
rpki-client: replace deprecated ERR_remove_state
ERR_remove_state(0) is deprecated use the new api ERR_remove_thread_state(NULL) instead. -- :wq Claudio Index: main.c === RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v retrieving revision 1.61 diff -u -p -r1.61 main.c --- main.c 1 Apr 2020 14:15:49 - 1.61 +++ main.c 16 Apr 2020 10:01:56 - @@ -1250,7 +1250,7 @@ out: EVP_cleanup(); CRYPTO_cleanup_all_ex_data(); - ERR_remove_state(0); + ERR_remove_thread_state(NULL); ERR_free_strings(); exit(rc);
cleanup an bad and unneeded typecast in rpki-client
There is a bit of strange code in the ip parser of rpki-client to parse
the AFI. This is a 2byte network byte order value. Instead of using a a
char buf and a short just do everything with a one uint16_t. The current
code does *(uint16_t)buf which is not save since buf is a char array.
Lucky us that the stack ends up enough aligned that this code does not
blow up on strict align archs. Still fix is simple and makes the code much
cleaner.
--
:wq Claudio
Index: ip.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/ip.c,v
retrieving revision 1.9
diff -u -p -r1.9 ip.c
--- ip.c27 Nov 2019 17:18:24 - 1.9
+++ ip.c16 Apr 2020 09:48:02 -
@@ -41,8 +41,7 @@
int
ip_addr_afi_parse(const char *fn, const ASN1_OCTET_STRING *p, enum afi *afi)
{
- char buf[2];
- shortv;
+ uint16_t v;
if (p->length == 0 || p->length > 3) {
warnx("%s: invalid field length, want 1--3, have %d",
@@ -50,8 +49,8 @@ ip_addr_afi_parse(const char *fn, const
return 0;
}
- memcpy(buf, p->data, sizeof(uint16_t));
- v = ntohs(*(uint16_t *)buf);
+ memcpy(&v, p->data, sizeof(v));
+ v = ntohs(v);
/* Only accept IPv4 and IPv6 AFIs. */
slaacd(8): only pay attention to interfaces in our routing domain
While slaacd(8) doesn't receive router advertisements for interface in
a different rdomain it still touches those interfaces, i.e. removing
addresses.
OK
diff --git frontend.c frontend.c
index 8c6d48810e9..8f5894a77de 100644
--- frontend.c
+++ frontend.c
@@ -69,6 +69,7 @@ void get_rtaddrs(int, struct sockaddr *, struct
sockaddr **);
voidicmp6_receive(int, short, void *);
int get_flags(char *);
int get_xflags(char *);
+int get_ifrdomain(char *);
voidget_lladdr(char *, struct ether_addr *, struct sockaddr_in6 *);
voidsend_solicitation(uint32_t);
#ifndefSMALL
@@ -480,14 +481,31 @@ get_xflags(char *if_name)
return ifr.ifr_flags;
}
+int
+get_ifrdomain(char *if_name)
+{
+ struct ifreq ifr;
+
+ (void) strlcpy(ifr.ifr_name, if_name, sizeof(ifr.ifr_name));
+ if (ioctl(ioctlsock, SIOCGIFRDOMAIN, (caddr_t)&ifr) == -1) {
+ log_warn("SIOCGIFRDOMAIN");
+ return -1;
+ }
+ return ifr.ifr_rdomainid;
+}
+
void
update_iface(uint32_t if_index, char* if_name)
{
struct imsg_ifinfo imsg_ifinfo;
- int flags, xflags;
+ int flags, xflags, ifrdomain;
if ((flags = get_flags(if_name)) == -1 || (xflags =
- get_xflags(if_name)) == -1)
+ get_xflags(if_name)) == -1 || (ifrdomain = get_ifrdomain(if_name))
+ == -1)
+ return;
+
+ if (ifrdomain != getrtable())
return;
if (!(xflags & IFXF_AUTOCONF6))
@@ -520,9 +538,12 @@ update_autoconf_addresses(uint32_t if_index, char* if_name)
struct sockaddr_in6 *sin6;
struct imsg_link_state imsg_link_state;
time_t t;
- int xflags;
+ int xflags, ifrdomain;
- if ((xflags = get_xflags(if_name)) == -1)
+ if ((xflags = get_xflags(if_name)) == -1 || (ifrdomain =
+ get_ifrdomain(if_name)) == -1)
+ return;
+ if (ifrdomain != getrtable())
return;
if (!(xflags & IFXF_AUTOCONF6))
--
I'm not entirely sure you are real.
Re: Simplify NET_LOCK() variations
Hello,
On Thu, Apr 16, 2020 at 10:57:42AM +0200, Martin Pieuchot wrote:
> On 14/04/20(Tue) 10:08, Martin Pieuchot wrote:
> > On 13/04/20(Mon) 03:20, Alexandr Nedvedicky wrote:
> > > On Sun, Apr 12, 2020 at 07:02:43PM +0200, Mark Kettenis wrote:
> > > > > From: "Theo de Raadt"
> > > > > Date: Sun, 12 Apr 2020 10:28:59 -0600
> > > > >
> > > > > > + if ((p->p_flag & P_SYSTEM) &&
> > > > > > + (strncmp(p->p_p->ps_comm, "softnet", 7) == 0))
> > > > >
> > > > > Wow that is ugly.
> > > >
> > > > A better approach might be to store a pointer to the softnet task's
> > > > struct proc in a global variable and check that. That is what we do
> > > > for the pagedaemon for example.
> >
> > Diff below implements that by introducing the in_taskq() function, any
> > comment on that approach?
> >
> > [...]
> > Diff below uses NET_RLOCK_IN_SOFTNET() with a corresponding KASSERT()
> > and converts all the places where tasks are enqueued on the "softnet"
> > taskq.
>
> Do we consider this approach good enough to explicitly document the 2,5
> years old state of locking of the network stack?
having this ASSERT already would helped us to discover the bug reported
by Richard much faster and easier.
>
> Is the in_taskq() approach overkilled or is it fine? Or are the names
> good enough?
I like it more than my 'magic' flag idea I shared earlier.
I'm fine with names. They are explicit enough.
>
> Could this change have helped avoid the previous mistake?
I would say yes.
>
> In other words, are you ok with it?
I'm OK with it. However I would like to know some more details
on the construct below:
> @@ -356,7 +367,17 @@ taskq_thread(void *xtq)
> {
> struct taskq *tq = xtq;
> struct task work;
> - int last;
> + int last, i;
> +
> + mtx_enter(&tq->tq_mtx);
> + for (i = 0; i < tq->tq_nthreads; i++) {
> + if (tq->tq_threads[i] == NULL) {
> + tq->tq_threads[i] = curproc;
> + break;
> + }
> + }
> + KASSERT(i < tq->tq_nthreads);
> + mtx_leave(&tq->tq_mtx);
>
> if (ISSET(tq->tq_flags, TASKQ_MPSAFE))
> KERNEL_UNLOCK();
> @@ -381,4 +402,17 @@ taskq_thread(void *xtq)
> wakeup_one(&tq->tq_running);
>
> kthread_exit(0);
> +}
sorry if my question sounds stupid. The snippet above indicates
the task queue threads stay around forever (once created), right?
I'm asking, because I see no place where we do 'tq_threads[i] = NULL'.
thanks and
regards
sashan
Re: Simplify NET_LOCK() variations
On 14/04/20(Tue) 10:08, Martin Pieuchot wrote:
> On 13/04/20(Mon) 03:20, Alexandr Nedvedicky wrote:
> > On Sun, Apr 12, 2020 at 07:02:43PM +0200, Mark Kettenis wrote:
> > > > From: "Theo de Raadt"
> > > > Date: Sun, 12 Apr 2020 10:28:59 -0600
> > > >
> > > > > + if ((p->p_flag & P_SYSTEM) &&
> > > > > + (strncmp(p->p_p->ps_comm, "softnet", 7) == 0))
> > > >
> > > > Wow that is ugly.
> > >
> > > A better approach might be to store a pointer to the softnet task's
> > > struct proc in a global variable and check that. That is what we do
> > > for the pagedaemon for example.
>
> Diff below implements that by introducing the in_taskq() function, any
> comment on that approach?
>
> [...]
> Diff below uses NET_RLOCK_IN_SOFTNET() with a corresponding KASSERT()
> and converts all the places where tasks are enqueued on the "softnet"
> taskq.
Do we consider this approach good enough to explicitly document the 2,5
years old state of locking of the network stack?
Is the in_taskq() approach overkilled or is it fine? Or are the names
good enough?
Could this change have helped avoid the previous mistake?
In other words, are you ok with it?
Index: kern/kern_task.c
===
RCS file: /cvs/src/sys/kern/kern_task.c,v
retrieving revision 1.27
diff -u -p -r1.27 kern_task.c
--- kern/kern_task.c19 Dec 2019 17:40:11 - 1.27
+++ kern/kern_task.c14 Apr 2020 07:49:38 -
@@ -47,6 +47,7 @@ struct taskq {
unsigned int tq_nthreads;
unsigned int tq_flags;
const char *tq_name;
+ struct proc **tq_threads;
struct mutex tq_mtx;
struct task_list tq_worklist;
@@ -55,6 +56,7 @@ struct taskq {
#endif
};
+struct proc *systqproc;
static const char taskq_sys_name[] = "systq";
struct taskq taskq_sys = {
@@ -64,6 +66,7 @@ struct taskq taskq_sys = {
1,
0,
taskq_sys_name,
+ &systqproc,
MUTEX_INITIALIZER(IPL_HIGH),
TAILQ_HEAD_INITIALIZER(taskq_sys.tq_worklist),
#ifdef WITNESS
@@ -74,6 +77,7 @@ struct taskq taskq_sys = {
#endif
};
+struct proc *systqmpproc;
static const char taskq_sys_mp_name[] = "systqmp";
struct taskq taskq_sys_mp = {
@@ -83,6 +87,7 @@ struct taskq taskq_sys_mp = {
1,
TASKQ_MPSAFE,
taskq_sys_mp_name,
+ &systqmpproc,
MUTEX_INITIALIZER(IPL_HIGH),
TAILQ_HEAD_INITIALIZER(taskq_sys_mp.tq_worklist),
#ifdef WITNESS
@@ -129,6 +134,8 @@ taskq_create(const char *name, unsigned
tq->tq_nthreads = nthreads;
tq->tq_name = name;
tq->tq_flags = flags;
+ tq->tq_threads = mallocarray(nthreads, sizeof(*tq->tq_threads),
+ M_DEVBUF, M_WAITOK|M_ZERO);
mtx_init_flags(&tq->tq_mtx, ipl, name, 0);
TAILQ_INIT(&tq->tq_worklist);
@@ -172,6 +179,8 @@ taskq_destroy(struct taskq *tq)
}
mtx_leave(&tq->tq_mtx);
+ free(tq->tq_threads, M_DEVBUF,
+ tq->tq_nthreads * sizeof(*tq->tq_threads));
free(tq, M_DEVBUF, sizeof(*tq));
}
@@ -186,6 +195,8 @@ taskq_create_thread(void *arg)
switch (tq->tq_state) {
case TQ_S_DESTROYED:
mtx_leave(&tq->tq_mtx);
+ free(tq->tq_threads, M_DEVBUF,
+ tq->tq_nthreads * sizeof(*tq->tq_threads));
free(tq, M_DEVBUF, sizeof(*tq));
return;
@@ -356,7 +367,17 @@ taskq_thread(void *xtq)
{
struct taskq *tq = xtq;
struct task work;
- int last;
+ int last, i;
+
+ mtx_enter(&tq->tq_mtx);
+ for (i = 0; i < tq->tq_nthreads; i++) {
+ if (tq->tq_threads[i] == NULL) {
+ tq->tq_threads[i] = curproc;
+ break;
+ }
+ }
+ KASSERT(i < tq->tq_nthreads);
+ mtx_leave(&tq->tq_mtx);
if (ISSET(tq->tq_flags, TASKQ_MPSAFE))
KERNEL_UNLOCK();
@@ -381,4 +402,17 @@ taskq_thread(void *xtq)
wakeup_one(&tq->tq_running);
kthread_exit(0);
+}
+
+int
+in_taskq(struct taskq *tq)
+{
+ int i;
+
+ for (i = 0; i < tq->tq_nthreads; i++) {
+ if (curproc == tq->tq_threads[i])
+ return (1);
+ }
+
+ return (0);
}
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.603
diff -u -p -r1.603 if.c
--- net/if.c12 Apr 2020 07:04:03 - 1.603
+++ net/if.c14 Apr 2020 07:34:49 -
@@ -250,6 +250,47 @@ struct task if_input_task_locked = TASK_
struct rwlock netlock = RWLOCK_INITIALIZER("netlock");
/*
+ * Reader version of NET_LOCK() to be used in "softnet" thread only.
+
+ * The "softnet" thread should be the only thread processing packets
+ * without holding an exclusive lock. This is done to allow read-only
+ * ioctl(2) to not block.
+
sys/conf.h buglet
dev_type_poll() functions return POLL* value or 0 if nothing is
supported. Diff below fixes the cdev_ipmi_init() definition by
passing selfalse instead of returning ENODEV in a poll function.
While here make comments match reality, ok?
Index: sys/conf.h
===
RCS file: /cvs/src/sys/sys/conf.h,v
retrieving revision 1.149
diff -u -p -r1.149 conf.h
--- sys/conf.h 3 Apr 2020 13:31:11 - 1.149
+++ sys/conf.h 16 Apr 2020 07:55:09 -
@@ -460,6 +460,7 @@ extern struct cdevsw cdevsw[];
(dev_type_stop((*))) enodev, 0, dev_init(c,n,poll), \
(dev_type_mmap((*))) enodev, 0, D_CLONE, dev_init(c,n,kqfilter) }
+/* open, close, ioctl */
#define cdev_pvbus_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), \
(dev_type_read((*))) enodev, \
@@ -468,11 +469,11 @@ extern struct cdevsw cdevsw[];
(dev_type_stop((*))) enodev, 0, selfalse, \
(dev_type_mmap((*))) enodev }
-/* open, close, read, write, poll, ioctl, nokqfilter */
+/* open, close, ioctl */
#define cdev_ipmi_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
- (dev_type_stop((*))) enodev, 0, (dev_type_poll((*))) enodev, \
+ (dev_type_stop((*))) enodev, 0, selfalse, \
(dev_type_mmap((*))) enodev, 0 }
/* open, close, ioctl, mmap */
