Re: patch: adding httpd implicit file extensions
On 2/27/21 3:10 AM, Stuart Henderson wrote:
I might be missing something but doesn't this do the same?
location not found match "/(.*)" {
request rewrite "/%1.html"
}
Nope, you're not missing anything, I wasn't aware you could do this.
This *does* actually solve my problem, although it should be
location not found match "/(.+)"
(with `.+` instead of `.*`) in order for it to work properly with
`index.html`. I guess my patch is pretty unnecessary :)
On 2/27/21 3:10 AM, Stuart Henderson wrote:
Custom error pages sound useful indeed.
My patch for that is actually quite small (including a slight tweak to
the default font). It hardcodes the error file path to `/.html` (e.g. /var/www/htdocs/404.html) and if that
file exists, it uses that file's contents instead of a hardcoded error
string. It's not very configurable, but it gets the job done:
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.143
diff -u -p -u -p -r1.143 server_http.c
--- server_http.c 5 Jan 2021 19:56:11 - 1.143
+++ server_http.c 27 Feb 2021 23:31:13 -
@@ -848,6 +848,8 @@ server_abort_http(struct client *clt, un
char buf[IBUF_READ_SIZE];
char*escapedmsg = NULL;
int bodylen;
+ char err_path[PATH_MAX];
+ FILE*f;
if (code == 0) {
server_close(clt, "dropped");
@@ -925,14 +927,25 @@ server_abort_http(struct client *clt, un
/* A CSS stylesheet allows minimal customization by the user */
style = "body { background-color: white; color: black; font-family: "
- "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
+ "sans-serif; }\n"
"hr { border: 0; border-bottom: 1px dashed; }\n"
"@media (prefers-color-scheme: dark) {\n"
"body { background-color: #1E1F21; color: #EEEFF1; }\n"
"a { color: #BAD7FF; }\n}";
+ /* Check for error document HTML file */
+ bodylen = 0;
+ if (snprintf(err_path, sizeof(err_path), "%s/%d.html", srv_conf->root,
+ code) != -1 && (f = fopen(err_path, "r")) != NULL) {
+ fseek(f, 0, SEEK_END);
+ bodylen = ftell(f);
+ fseek(f, 0, SEEK_SET);
+ body = calloc(bodylen + 1, sizeof(char));
+ bodylen = body ? fread(body, sizeof(char), bodylen, f) : 0;
+ }
+
/* Generate simple HTML error document */
- if ((bodylen = asprintf(,
+ if (bodylen == 0 && (bodylen = asprintf(,
"\n"
"\n"
"\n"
install smtpd-filters(7)?
It would be nice to have this reference installed, would this be the right place to do that? (ok, mostly I want to link https://man.openbsd.org/smtpd-filter.7 from https://github.com/afresh1/OpenSMTPd-Filter/) Comments, OK? Index: usr.sbin/smtpd/smtpd/Makefile === RCS file: /cvs/src/usr.sbin/smtpd/smtpd/Makefile,v retrieving revision 1.107 diff -u -p -r1.107 Makefile --- usr.sbin/smtpd/smtpd/Makefile 31 Jan 2020 22:01:20 - 1.107 +++ usr.sbin/smtpd/smtpd/Makefile 28 Feb 2021 02:18:32 - @@ -79,7 +79,7 @@ SRCS+=scheduler_proc.c SRCS+= stat_ramstat.c -MAN= sendmail.8 smtpd.8 smtpd.conf.5 table.5 +MAN= sendmail.8 smtpd.8 smtpd.conf.5 smtpd-filters.7 table.5 BINDIR=/usr/sbin LDADD+=-levent -lutil -lssl -lcrypto -lm -lz
Re: Mesa leak in intel iris driver
Stuart Henderson wrote: > On 2021/02/27 11:50, Theo de Raadt wrote: > > To see the problem, It is better to look at "UVM amap" in "vmstat -m" > > > > UVM amap 32835 1690K 2636K 78644K 268129080 > > 16,32,64,128,256,512,1024,4096,8192 > > > > this number is way too big, it should be 500 to 2000 > > ish. > > Some things I'm running use a bunch more. > > UVM amap125046 8548K 8898K 78644K1471704770 > 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,524288 > > I wouldn't be surprised if there's some kind of leak on this system but > most of these do go away after closing things.. (it's not Iris in this > case). After closing firefox (with a lot of tabs), chrome, mysqld, a > couple of Java and Perl things: > > UVM amap 7201 411K 8898K 78644K1472547160 > 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,524288 > > mutt and some other things that I didn't close use quite a few too. > > (I have some work software using perl pdf::api2 with large files which > hits amap *really* hard, stefan@ did a uvm commit in 2016 that helped a > lot with stopping that from killing the kernel) the amap INUSE is the sum of all userland sub-address-space mappings (because we are so aggressive doing address space randomization for all objects). since >pagesize malloc (and mmaps) will be naturally guarded, each one is an amap. If you leak, this will grow uncomfortably. If you don't leak, it still grows until the process releases the full-range of the amap, or exits. Having chosen many years ago to do aggressive address space randomization, we kind of accept the kernel datastructure cost. Right now we are not chasing how to handle issues with natural growth, first we go after the leaks. In the X server, in particular.
iscsid/iscsictl: Introduce poll-and-wait delay during reload
Hello tech,
Recently I encountered a problem with automounting iscsi volumes at boot
time. This came down to a timing issue, where iscsictl reload was
returning before the volumes were attached - causing the machine to
enter single user mode when it would try to fsck the iscsi volumes.
See this thread:
https://marc.info/?l=openbsd-bugs=161404736018432=2
Adding "&& sleep 5" to /etc/rc.d/iscsid did mitigate this, however
that's both hacky and precarious.
After some discussion with claudio@, the principled solution is to make
iscsictl wait until the sessions are up and the devices are attached
before returning. Since "iscsictl reload" is called in the rc script,
this would halt the boot process long enough for all the volumes to be
available before progressing - and thus, eliminating my problem.
The following diff is an attempt at that, with some caveats. It does the
following things:
- adds a control command to iscsid to allow for polling of session and
connection status during iscsictl reload.
- book-keeping code for working out if there are sessions still
initializing
- some poll-wait mechanisms in iscsictl, which (a) waits for iscsid to
tell it everything is up and running or (b) returns after 10 poll
attempts 1 second apart (thus, the max delay here is currently 10
seconds).
I have confirmed that the current implementation does indeed solve my
problem, however there's a couple of things I still question:
1. In the poll_and_wait() function in iscsictl, you'll notice there's an
extra sleep with the comment that it is there to give time for the
devices to attach. In my case, the extra second was needed for both my
devices to attach. without the extra sleep, the first device would
attach successfully while iscsictl was still waiting, but the second
still had not fully attached even though my book-keeping code said that
nothing further was in flight. I question whether there's a better way
to do this and welcome suggestions about that.
2. It's probably too chatty. Is it also perhaps better to have a
separate command that does this, rather than hijacking "reload"?
3. I don't know whether the book-keeping code is entirely
reasonable. I've tried to capture every state, but I do wonder if there
are cases where things slip through the cracks.
For context, here is the machine booting (and hitting single user mode)
with the standard iscsid:
https://www.youtube.com/watch?v=F09PaT-8IJU=youtu.be
Whereas, here is the same machine configured identically with my iscsid
changes applied:
https://www.youtube.com/watch?v=TZzmQBVDRxo=youtu.be
The delay appears to be somewhere around 2-3 seconds, which is less than
the full 10 allowable by the poll_and_wait() loop - so it does appear to
be detecting the status correctly (at least in this configuration).
Anyhow, I'd love to hear some comments and suggestions. Please note this
is my first submission outside of ports that's bigger than a 1 or 2
liner, and it's been a while since I've written C (I write C++ at my day
job, and it's not systems programming...), so hopefully I haven't done
anything too silly.
Thanks,
Ash
diff --git a/usr.sbin/iscsictl/iscsictl.c b/usr.sbin/iscsictl/iscsictl.c
index 77f9c74abde..46404b5512b 100644
--- a/usr.sbin/iscsictl/iscsictl.c
+++ b/usr.sbin/iscsictl/iscsictl.c
@@ -40,6 +40,10 @@ struct pdu *ctl_getpdu(char *, size_t);
int ctl_sendpdu(int, struct pdu *);
void show_config(struct ctrlmsghdr *, struct pdu *);
void show_vscsi_stats(struct ctrlmsghdr *, struct pdu *);
+void poll_and_wait(void);
+void poll_session_status(void);
+void register_poll(struct ctrlmsghdr *, struct pdu *);
+void poll_print(struct session_poll *);
char cbuf[CONTROL_READ_SIZE];
@@ -48,6 +52,12 @@ struct control {
int fd;
} control;
+
+struct session_poll poll_result; /* Poll result */
+
+#define POLL_DELAY 1 /* Delay between poll attempts (seconds) */
+#define POLL_ATTEMPTS 10/* Number of poll attempts before returning */
+
__dead void
usage(void)
{
@@ -68,7 +78,7 @@ main (int argc, char* argv[])
char *sockname = ISCSID_CONTROL;
struct session_ctlcfg *s;
struct iscsi_config *cf;
- int ch, val = 0;
+ int ch, poll = 0, val = 0;
/* check flags */
while ((ch = getopt(argc, argv, "f:s:")) != -1) {
@@ -135,6 +145,9 @@ main (int argc, char* argv[])
>initiator, sizeof(cf->initiator)) == -1)
err(1, "control_compose");
}
+
+ /* Reloading, so poll afterwards. */
+ poll = 1;
SIMPLEQ_FOREACH(s, >sessions, entry) {
struct ctrldata cdv[3];
bzero(cdv, sizeof(cdv));
@@ -174,8 +187,13 @@ main (int argc, char* argv[])
run();
- close(control.fd);
+ /* If we've reloaded, we probably should wait in case any new connections
+ need to come up (or fail). */
+ if (poll) {
+ poll_and_wait();
+ }
+ close(control.fd);
return (0);
}
@@ -237,6 +255,11 @@ run_command(struct pdu *pdu)
show_vscsi_stats(cmh, pdu);
done =
Re: Mesa leak in intel iris driver
On 2021/02/27 11:50, Theo de Raadt wrote: > To see the problem, It is better to look at "UVM amap" in "vmstat -m" > > UVM amap 32835 1690K 2636K 78644K 268129080 > 16,32,64,128,256,512,1024,4096,8192 > > this number is way too big, it should be 500 to 2000 ish. Some things I'm running use a bunch more. UVM amap125046 8548K 8898K 78644K1471704770 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,524288 I wouldn't be surprised if there's some kind of leak on this system but most of these do go away after closing things.. (it's not Iris in this case). After closing firefox (with a lot of tabs), chrome, mysqld, a couple of Java and Perl things: UVM amap 7201 411K 8898K 78644K1472547160 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,524288 mutt and some other things that I didn't close use quite a few too. (I have some work software using perl pdf::api2 with large files which hits amap *really* hard, stefan@ did a uvm commit in 2016 that helped a lot with stopping that from killing the kernel)
Re: Workflow question
Thanks! This works perfectly! On Sun, Feb 28, 2021 at 12:01:06AM +0100, Theo Buehler wrote: > > Following the advice in the FAQ I added my user to the wobj group. I > > suppose I could "make obj" and have the objs written to /usr/obj? Is > > this a workflow the developers recommend or follow? Thanks! > > Yes. More precisely, by default 'make obj' in /usr/src/usr.bin/systat > will create a symlink obj@ -> /usr/obj/usr.bin/systat where the build > artefacts will be placed. > > $ ls -ld /usr/obj/usr.bin/systat > drwxrwx--- 2 build wobj 1024 Feb 26 21:47 /usr/obj/usr.bin/systat/ Regards, Anindya
Re: Workflow question
> Following the advice in the FAQ I added my user to the wobj group. I > suppose I could "make obj" and have the objs written to /usr/obj? Is > this a workflow the developers recommend or follow? Thanks! Yes. More precisely, by default 'make obj' in /usr/src/usr.bin/systat will create a symlink obj@ -> /usr/obj/usr.bin/systat where the build artefacts will be placed. $ ls -ld /usr/obj/usr.bin/systat drwxrwx--- 2 build wobj 1024 Feb 26 21:47 /usr/obj/usr.bin/systat/
Workflow question
Hi, I am making a small change to systat(1) and hope to submit it for review soon. For my own edification, I have a few questions regarding the recommended workflow for such work. Hopefully tech@ is the right place to ask this :) I generated the tags with "make tags", and also temporarily added -O0 -g to the build flags in the Makefile. I can run "make" in /usr/src/usr.bin/systat directly and it works: I get a binary which runs. However, I don't like the fact that it writes the obj files in the same directory. Following the advice in the FAQ I added my user to the wobj group. I suppose I could "make obj" and have the objs written to /usr/obj? Is this a workflow the developers recommend or follow? Thanks! Anindya
Re: Mesa leak in intel iris driver
Hi, I have been noticing this leak for a few weeks now. I typically update to the latest snapshot every 10-14 days and Xorg memory usage grows monotonically in the meantime. I was gathering some data for a report, but thanks to this thread it's explained now. I look forward to testing the fix. I also have the iris driver. > 35MB of memory is too large to expose amap leakage, since most of the amaps > are associated with single pages. The X server does some very large > allocations, > and thus SIZE will not show these very well. > > To see the problem, It is better to look at "UVM amap" in "vmstat -m" > > UVM amap 32835 1690K 2636K 78644K 268129080 > 16,32,64,128,256,512,1024,4096,8192 > > this number is way too big, it should be 500 to 2000 ish. Thanks for this comment! Now I know what to look for. On my system running for 3 days it is already over 32,000. Regards, Anindya
sndiod: allow mixing of duplex, record-only and play-only audio devices
Hi,
Currently sndiod does not allow you to use alternative devices (-F
devices) which support only a subset of the modes of the main (-f)
device.
For example, if you do `sndiod -f rsnd/0 -F rsnd/1` and:
- rsnd/0 is full-duplex (rec + play).
- rsnd/1 is play-only.
Then you will be unable to use rsnd/1 as sndiod deems is incompatible
and refuses to use it (similarly if rsnd/1 is record-only).
This is annoying. It means if you want to use a record-only or play-only
device, you will either have to kill sndiod and restart it specifying
only that device (`sndiod -f rsnd/1` for the above example), or failing
that, downgrade the functionality of the main device (`-m play`).
This diff (a joint effort between ratchov@ and myself) makes mixing
devices with different modes possible. It does this by making both
recording and playing available for all devices, even if the underlying
hardware doesn't support both modes.
For example, if I try to record from a play-only device, then recording
will succeed, but the captured PCM data will be pure silence. Similarly,
if I try to play to a record-only device, then the audio stream will
disappear into the ether.
This is mostly a no-op for sndiod in the default configuration (except
that play-only devices now accept recording clients). If you use
alternative devices (-F), then it's possible for a record-only device to
be found first, which may be confusing if you just want to hear sound.
We can only assume that if you deviate from defaults, then you know what
you are doing.
Please test and let us know if it works for you.
(Dongle DACs are often play-only, and are thus a good test. Select the
device with `sndioctl server.device=X` and then try to record from it
with `aucat -o /tmp/test.wav`. You should get silence. Don't forget to
enable the record permission sysctl though!)
Index: dev.c
===
RCS file: /cvs/src/usr.bin/sndiod/dev.c,v
retrieving revision 1.90
diff -u -p -r1.90 dev.c
--- dev.c 2 Feb 2021 11:18:57 - 1.90
+++ dev.c 27 Feb 2021 21:45:38 -
@@ -1142,43 +1142,51 @@ dev_adjpar(struct dev *d, int mode,
/*
* Open the device with the dev_reqxxx capabilities. Setup a mixer, demuxer,
* monitor, midi control, and any necessary conversions.
+ *
+ * Note that record and play buffers are always allocated, even if the
+ * underlying device doesn't support both modes.
*/
int
dev_allocbufs(struct dev *d)
{
- if (d->mode & MODE_REC) {
- /*
-* Create device <-> demuxer buffer
-*/
- d->rbuf = xmalloc(d->round * d->rchan * sizeof(adata_t));
+ /*
+* Create record buffer.
+*/
- /*
-* Insert a converter, if needed.
-*/
- if (!aparams_native(>par)) {
- dec_init(>dec, >par, d->rchan);
- d->decbuf = xmalloc(d->round * d->rchan * d->par.bps);
- } else
- d->decbuf = NULL;
- }
- if (d->mode & MODE_PLAY) {
- /*
-* Create device <-> mixer buffer
-*/
- d->poffs = 0;
- d->psize = d->bufsz + d->round;
- d->pbuf = xmalloc(d->psize * d->pchan * sizeof(adata_t));
- d->mode |= MODE_MON;
+/* Create device <-> demuxer buffer */
+ d->rbuf = xmalloc(d->round * d->rchan * sizeof(adata_t));
+
+ /* Insert a converter, if needed. */
+ if (!aparams_native(>par)) {
+ dec_init(>dec, >par, d->rchan);
+ d->decbuf = xmalloc(d->round * d->rchan * d->par.bps);
+ } else
+ d->decbuf = NULL;
+
+ /*
+* Create play buffer
+*/
+
+ /* Create device <-> mixer buffer */
+ d->poffs = 0;
+ d->psize = d->bufsz + d->round;
+ d->pbuf = xmalloc(d->psize * d->pchan * sizeof(adata_t));
+ d->mode |= MODE_MON;
+
+ /* Append a converter, if needed. */
+ if (!aparams_native(>par)) {
+ enc_init(>enc, >par, d->pchan);
+ d->encbuf = xmalloc(d->round * d->pchan * d->par.bps);
+ } else
+ d->encbuf = NULL;
+
+ /*
+* Initially fill the record buffer with zeroed samples. This ensures
+* that when a client records from a play-only device the client just
+* gets silence.
+*/
+ memset(d->rbuf, 0, d->round * d->rchan * sizeof(adata_t));
- /*
-* Append a converter, if needed.
-*/
- if (!aparams_native(>par)) {
- enc_init(>enc, >par, d->pchan);
- d->encbuf = xmalloc(d->round * d->pchan * d->par.bps);
- } else
- d->encbuf = NULL;
- }
if (log_level >= 2) {
dev_log(d);
log_puts(": ");
@@ -1935,8
Re: OpenBSD perl 5.32.1 - Call for Testing
On Fri, 26 Feb 2021 11:31:07 -0800 Andrew Hewus Fresh wrote: > On Sat, Feb 20, 2021 at 02:11:45PM -0800, Andrew Hewus Fresh wrote: > > I've probably missed making it in for 6.9, but it is again time for > > testing a perl update so it can become /usr/bin/perl > > It was pointed out that there is still time to get this in for 6.9, and > sthen@ says it looks OK in a bulk ports build, so I'll be working on > preparing the import this weekend. Please let me know of any reasons > to hold off. Good news that ports can build. I had moved my amd64 and powerpc64 to perl 5.32.1, but have not yet built any ports. I will move my macppc to 5.32.1 sometime after your import it.--George
Re: Clarifications about ELF(5)
> On Sat, Feb 27, 2021 at 07:26:42PM +, George Brown wrote: > > > hi. diff committed, with one change: we did not add "must" (just removed > > > "usually"). > > > > > > jmc > > > > Thanks Jason. Though browsing cvsweb it seems the commit did include the > > "must" not sure if the decision changed after sending your mail or the > > wrong diff got applied? > > > > thanks, i totally messed up my commit. i've fixed that now. sorry that i > also didn;t credit you as the author of the diff! > > thanks for your diff and the follow up. > jmc No worries! I seem to have fudged the subject in my last mail so it seems fat-fingers are abound. Thanks again.
Re: Clarifications about ELF(5)
On Sat, Feb 27, 2021 at 07:26:42PM +, George Brown wrote: > > hi. diff committed, with one change: we did not add "must" (just removed > > "usually"). > > > > jmc > > Thanks Jason. Though browsing cvsweb it seems the commit did include the > "must" not sure if the decision changed after sending your mail or the > wrong diff got applied? > thanks, i totally messed up my commit. i've fixed that now. sorry that i also didn;t credit you as the author of the diff! thanks for your diff and the follow up. jmc
Clarifications about ELF(5)
> hi. diff committed, with one change: we did not add "must" (just removed > "usually"). > > jmc Thanks Jason. Though browsing cvsweb it seems the commit did include the "must" not sure if the decision changed after sending your mail or the wrong diff got applied?
Re: Clarifications about ELF(5)
On Sat, Feb 27, 2021 at 12:24:33PM +, George Brown wrote: > Binaries without a .note.openbsd.ident section fail to execute. This > note section is mentioned in the ELF man page as follows. > > > .note This section holds information in the note section format > >described below. This section is of type SHT_NOTE. No > >attribute types are used. OpenBSD native executables usually > >contain a .note.openbsd.ident section to identify themselves, > >for the kernel to bypass any compatibility ELF binary emula- > >tion tests when loading the file. > > The use of the word "usually" makes this read ambiguously to me. In that > it's not clear if this note is present and/or required in all binaries. > > Examining binaries on my system it seems this note is indeed always > present and from practise does seem to be required (removing it from > binaries with objcopy -R causes execution to fail). The mention of > "emulation" made we wonder if perhaps this was referring to the old > compat_linux layer. Reviewing the history it seems this part of the man > page is largely unchanged from it's import in V 1.1 which pre-dates the > removal of compat_linux. > > Is this indeed a remnant? If so should an update with firmer wording be > made, perhaps something like the following? Though I'm not really sure > what in the underlying implantation this note represents in a post > compat_linux removal world? > > diff --git a/share/man/man5/elf.5 b/share/man/man5/elf.5 > index d22279f6738..aece235de6b 100644 > --- a/share/man/man5/elf.5 > +++ b/share/man/man5/elf.5 > @@ -1026,10 +1026,9 @@ This section is of type > .Dv SHT_NOTE . > No attribute types are used. > .Ox > -native executables usually contain a > +native executables must contain a > .Sy .note.openbsd.ident > -section to identify themselves, for the kernel to bypass any compatibility > -ELF binary emulation tests when loading the file. > +section to identify themselves. > .It .plt > This section holds the procedure linkage table. > This section is of type > hi. diff committed, with one change: we did not add "must" (just removed "usually"). jmc
Re: Mesa leak in intel iris driver
Theo Buehler wrote:
> On Sat, Feb 27, 2021 at 12:21:35AM +1100, Jonathan Gray wrote:
> > Bring in a change which was backported to Mesa 20.1 but not 20.0.
> > This is for inteldrm with >= gen8/broadwell hardware.
> > /var/log/Xorg.0.log with 'DRI driver: iris' and 'xdriinfo' will
> > show 'Screen 0: iris' if you are using the iris driver.
>
> This seems to help a lot on my x280 where xdriinfo prints Screen 0: iris.
>
> inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics 620" rev 0x07
> drm0 at inteldrm0
> inteldrm0: msi, KABYLAKE, gen 9
> inteldrm0: 1920x1080, 32bpp
>
> I hadn't paid attention to it previously, but as observed yesterday
> after a few hours of uptime, Xorg would already use way above 100M
> and grow steadily.
>
> Running with this patch overnight I'm at the below which apart from the
> TIME column looks pretty much like right after startup.
>
> PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
> 24637 _x11 20 35M 65M sleep/1 poll 1:29 0.10% Xorg
> 20308 root 20 2464K 1284K idle netio 0:00 0.00% Xorg
35MB of memory is too large to expose amap leakage, since most of the amaps
are associated with single pages. The X server does some very large
allocations,
and thus SIZE will not show these very well.
To see the problem, It is better to look at "UVM amap" in "vmstat -m"
UVM amap 32835 1690K 2636K 78644K 268129080
16,32,64,128,256,512,1024,4096,8192
this number is way too big, it should be 500 to 2000 ish.
Re: ip_fragment ip6_fragment
> On 26 Feb 2021, at 14:08, Alexander Bluhm wrote: > > Hi, > > I always bothered me that ip_fragment() and ip6_fragment() behave > sligtly differently. Unify them and use an mlist to simplify the > fragment list. > > - The functions ip_fragment() and ip6_fragment() always consume the mbuf. > - They free the mbuf and mbuf list in case of an error. > - They care about the counter. > - Adjust the code a bit to make v4 and v6 look similar. > - Maybe there was an mbuf leak when pf_route6() called pf_refragment6() > and it failed. Now the mbuf is always freed by ip6_fragment(). > > ok? ok mvs@
Re: [OpenBSD -current] Change event timer in main loop with kqueue
Moving to tech@.
On Fri, Feb 26, 2021 at 09:42:07PM +0100, martin mag wrote:
> I've been trying to use kqueue for the last couple of day but I keep
> having an issue with EVFILT_TIMER filter. (I'm running Openbsd
> -current)
>
> Right now, I'm trying to do the following:
> 1) Initilialize a timer event @ 200ms, periodically.
> 2) Inside the main event loop => If this event is retrieved, print
> elapsed time since last one
> 3) After 2 iterations, MODIFY the timer event to 1000ms and continue the loop
> 4) Code stops after 4 iterations as pb arise after the first timer
> change @ iteration 2.
>
> Reading the manpages kqueue(2), one sees that:
> ** ) An event is uniquely defined by the pair (ident, filter) ==>
> in the example below (TIMER1, EVFILT_TIMER)
> **) "" Re-adding an existing event will modify the parameters of
> the original event, and not result in a duplicate entry. "" => So
> re-adding the event (TIMER1, EVFILT_TIMER) with a modified field
> 'data' should update the timer from 200ms to 1000ms.
>
> => Apparently, timer is updated, but not in the way I expected.
The kernel does not reschedule the timer when the user changes the
timeout period. The new period will take effect only after the current
period has expired. This is not explained in the manual page, though.
With the recent kqueue changes, it is straightforward to make the kernel
modify an existing timer. I think the clearest behaviour is to reset the
timer completely when it is modified. If there are pending events, they
should be cancelled because they do not necessarily correspond to the
new settings.
When f_modify and f_process are present in kqread_filtops, filt_timer
is not used. filt_timerexpire() activates timer knotes directly using
knote_activate() instead of KNOTE().
However, the current behaviour has been around so long that one can
argue that it is an actual feature. BSDs are not consistent with this,
though. FreeBSD resets the timer immediately, whereas NetBSD and
DragonFly BSD apply the new period after expiry.
I guess the resetting is harmless in most cases but might wreak havoc
at least with software that keeps poking its timers before expiry.
Index: lib/libc/sys/kqueue.2
===
RCS file: src/lib/libc/sys/kqueue.2,v
retrieving revision 1.43
diff -u -p -r1.43 kqueue.2
--- lib/libc/sys/kqueue.2 14 Nov 2020 10:16:15 - 1.43
+++ lib/libc/sys/kqueue.2 27 Feb 2021 12:54:27 -
@@ -468,6 +468,11 @@ contains the number of times the timeout
This filter automatically sets the
.Dv EV_CLEAR
flag internally.
+.Pp
+If an existing timer is re-added, the existing timer and related pending events
+will be cancelled.
+The timer will be re-started using the timeout period
+.Fa data .
.It Dv EVFILT_DEVICE
Takes a descriptor as the identifier and the events to watch for in
.Fa fflags ,
Index: sys/kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.161
diff -u -p -r1.161 kern_event.c
--- sys/kern/kern_event.c 24 Feb 2021 14:59:52 - 1.161
+++ sys/kern/kern_event.c 27 Feb 2021 12:54:27 -
@@ -135,7 +135,8 @@ int filt_fileattach(struct knote *kn);
void filt_timerexpire(void *knx);
intfilt_timerattach(struct knote *kn);
void filt_timerdetach(struct knote *kn);
-intfilt_timer(struct knote *kn, long hint);
+intfilt_timermodify(struct kevent *kev, struct knote *kn);
+intfilt_timerprocess(struct knote *kn, struct kevent *kev);
void filt_seltruedetach(struct knote *kn);
const struct filterops kqread_filtops = {
@@ -163,7 +164,9 @@ const struct filterops timer_filtops = {
.f_flags= 0,
.f_attach = filt_timerattach,
.f_detach = filt_timerdetach,
- .f_event= filt_timer,
+ .f_event= NULL,
+ .f_modify = filt_timermodify,
+ .f_process = filt_timerprocess,
};
struct pool knote_pool;
@@ -444,15 +447,48 @@ filt_timerdetach(struct knote *kn)
struct timeout *to;
to = (struct timeout *)kn->kn_hook;
- timeout_del(to);
+ timeout_del_barrier(to);
free(to, M_KEVENT, sizeof(*to));
kq_ntimeouts--;
}
int
-filt_timer(struct knote *kn, long hint)
+filt_timermodify(struct kevent *kev, struct knote *kn)
+{
+ struct timeout *to = kn->kn_hook;
+ int s;
+
+ /* Reset the timer. Any pending events are discarded. */
+
+ timeout_del_barrier(to);
+
+ s = splhigh();
+ if (kn->kn_status & KN_QUEUED)
+ knote_dequeue(kn);
+ kn->kn_status &= ~KN_ACTIVE;
+ splx(s);
+
+ kn->kn_data = 0;
+ knote_modify(kev, kn);
+ /* Reinit timeout to invoke tick adjustment again. */
+ timeout_set(to, filt_timerexpire, kn);
+ filt_timer_timeout_add(kn);
+
+ return (0);
+}
+
+int
+filt_timerprocess(struct knote *kn,
Re: Mesa leak in intel iris driver
On Sat, Feb 27, 2021 at 12:21:35AM +1100, Jonathan Gray wrote: > Bring in a change which was backported to Mesa 20.1 but not 20.0. > This is for inteldrm with >= gen8/broadwell hardware. > /var/log/Xorg.0.log with 'DRI driver: iris' and 'xdriinfo' will > show 'Screen 0: iris' if you are using the iris driver. This seems to help a lot on my x280 where xdriinfo prints Screen 0: iris. inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics 620" rev 0x07 drm0 at inteldrm0 inteldrm0: msi, KABYLAKE, gen 9 inteldrm0: 1920x1080, 32bpp I hadn't paid attention to it previously, but as observed yesterday after a few hours of uptime, Xorg would already use way above 100M and grow steadily. Running with this patch overnight I'm at the below which apart from the TIME column looks pretty much like right after startup. PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 24637 _x11 20 35M 65M sleep/1 poll 1:29 0.10% Xorg 20308 root 20 2464K 1284K idle netio 0:00 0.00% Xorg
Clarifications about ELF(5)
Binaries without a .note.openbsd.ident section fail to execute. This note section is mentioned in the ELF man page as follows. > .note This section holds information in the note section format >described below. This section is of type SHT_NOTE. No >attribute types are used. OpenBSD native executables usually >contain a .note.openbsd.ident section to identify themselves, >for the kernel to bypass any compatibility ELF binary emula- >tion tests when loading the file. The use of the word "usually" makes this read ambiguously to me. In that it's not clear if this note is present and/or required in all binaries. Examining binaries on my system it seems this note is indeed always present and from practise does seem to be required (removing it from binaries with objcopy -R causes execution to fail). The mention of "emulation" made we wonder if perhaps this was referring to the old compat_linux layer. Reviewing the history it seems this part of the man page is largely unchanged from it's import in V 1.1 which pre-dates the removal of compat_linux. Is this indeed a remnant? If so should an update with firmer wording be made, perhaps something like the following? Though I'm not really sure what in the underlying implantation this note represents in a post compat_linux removal world? diff --git a/share/man/man5/elf.5 b/share/man/man5/elf.5 index d22279f6738..aece235de6b 100644 --- a/share/man/man5/elf.5 +++ b/share/man/man5/elf.5 @@ -1026,10 +1026,9 @@ This section is of type .Dv SHT_NOTE . No attribute types are used. .Ox -native executables usually contain a +native executables must contain a .Sy .note.openbsd.ident -section to identify themselves, for the kernel to bypass any compatibility -ELF binary emulation tests when loading the file. +section to identify themselves. .It .plt This section holds the procedure linkage table. This section is of type
Re: patch: adding httpd implicit file extensions
On 2021/02/26 15:38, Bruce Hill wrote:
> Hello, this is my first time contributing to openbsd and this mailing
> list, so please excuse any newbie blunders. I recently switched my
> personal website to use httpd with statically generated HTML files, but
> was unhappy to find that my HTML files could only be accessed by exact
> filename, including the ".html" at the end. My site previously ran on
> Apache with rewrite rules to ensure that "example.com/foo" would serve
> the file "/foo.html" (when "/foo" didn't exist). I wanted to keep my
> original URLs working and I aesthetically prefer URLs without ".html"
> suffixes, so I looked around for different options with httpd. The best
> option I could find was to create symbolic links from "/foo" to
> "/foo.html" and set the default media type to text/html, but this
> solution was cumbersome (I had to maintain all the symbolic links) and
> had undesirable side effects (all extensionless files were treated as
> text/html instead of text/plain).
>
> I decided instead to look into modifying httpd to support implicit file
> extensions. My basic idea was to add a configurable setting called
> `implicit extension`. When a file is not found and the file doesn't
> already have the implicit extension, then httpd will look for the same
> filename but with the implicit extension added at the end, and reroute
> to that file if it exists. This neatly solves my problem by adding
> `implicit extension ".html"` to the top of my /etc/httpd.conf file, and
> `implicit extension ".php"` to the section of my website that uses PHP
> scripts. For simplicity (and because my website doesn't use both HTML
> and PHP in the same subdomain), I opted to only support a single
> implicit extension per config block, though in the future, supporting
> globs as implicit extensions might also be nice(e.g. `implicit extension
> ".{html,php}"`).
I might be missing something but doesn't this do the same?
location not found match "/(.*)" {
request rewrite "/%1.html"
}
> I've been running the code on my personal website for a while now
> without any issues. If this patch is accepted, I also have a separate
> small patch that displays custom HTTP error pages if you have a
> /[] file (e.g. /404 or /404.html), which
> works well in conjunction with this patch.
Custom error pages sound useful indeed.
> I'm happy to take any feedback or criticism on both the idea and my
> implementation patch below. Hopefully other people find this useful as
> well!
>
> - Bruce Hill
>
>
> Index: config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/config.c,v
> retrieving revision 1.61
> diff -u -p -u -p -r1.61 config.c
> --- config.c 21 Sep 2020 09:42:07 - 1.61
> +++ config.c 26 Feb 2021 23:30:18 -
> @@ -568,6 +568,13 @@ config_getserver_config(struct httpd *en
> >default_type, sizeof(struct media_type));
> }
> + f = SRVFLAG_IMPLICIT_EXT;
> + if ((srv_conf->flags & f) == 0) {
> + srv_conf->flags |= parent->flags & f;
> + memcpy(_conf->implicit_extension,
> + >implicit_extension,
> sizeof(parent->implicit_extension));
> + }
> +
> f = SRVFLAG_PATH_REWRITE|SRVFLAG_NO_PATH_REWRITE;
> if ((srv_conf->flags & f) == 0) {
> srv_conf->flags |= parent->flags & f;
> Index: httpd.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
> retrieving revision 1.153
> diff -u -p -u -p -r1.153 httpd.h
> --- httpd.h 29 Oct 2020 12:30:52 - 1.153
> +++ httpd.h 26 Feb 2021 23:30:19 -
> @@ -57,6 +57,7 @@
> #define HTTPD_REALM_MAX 255
> #define HTTPD_LOCATION_MAX 255
> #define HTTPD_DEFAULT_TYPE { "bin", "application", "octet-stream", NULL }
> +#define HTTPD_IMPLICIT_EXT ""
> #define HTTPD_LOGVIS VIS_NL|VIS_TAB|VIS_CSTYLE
> #define HTTPD_TLS_CERT "/etc/ssl/server.crt"
> #define HTTPD_TLS_KEY"/etc/ssl/private/server.key"
> @@ -391,6 +392,7 @@ SPLAY_HEAD(client_tree, client);
> #define SRVFLAG_DEFAULT_TYPE 0x0080
> #define SRVFLAG_PATH_REWRITE 0x0100
> #define SRVFLAG_NO_PATH_REWRITE 0x0200
> +#define SRVFLAG_IMPLICIT_EXT 0x0400
> #define SRVFLAG_LOCATION_FOUND 0x4000
> #define SRVFLAG_LOCATION_NOT_FOUND 0x8000
> @@ -399,8 +401,8 @@ SPLAY_HEAD(client_tree, client);
> "\05ROOT\06LOCATION\07FCGI\10NO_FCGI\11LOG\12NO_LOG"\
> "\14SYSLOG\15NO_SYSLOG\16TLS\17ACCESS_LOG\20ERROR_LOG" \
> "\21AUTH\22NO_AUTH\23BLOCK\24NO_BLOCK\25LOCATION_MATCH" \
> - "\26SERVER_MATCH\27SERVER_HSTS\30DEFAULT_TYPE\31PATH\32NO_PATH" \
> - "\37LOCATION_FOUND\40LOCATION_NOT_FOUND"
> +
Re: install rc.d script for resolvd
On Sat 27/02/2021 07:37, Bjorn Ketelaars wrote: > resolvd will not start at boot without its rc.d script. > > OK? Additionally register rc.d/resolvd in sets list. Index: distrib/sets/lists/base/mi === RCS file: /cvs/src/distrib/sets/lists/base/mi,v retrieving revision 1.1012 diff -u -p -r1.1012 mi --- distrib/sets/lists/base/mi 26 Feb 2021 17:20:07 - 1.1012 +++ distrib/sets/lists/base/mi 27 Feb 2021 11:03:47 - @@ -185,6 +185,7 @@ ./etc/rc.d/rbootd ./etc/rc.d/rc.subr ./etc/rc.d/relayd +./etc/rc.d/resolvd ./etc/rc.d/ripd ./etc/rc.d/route6d ./etc/rc.d/sasyncd Index: etc/Makefile === RCS file: /cvs/src/etc/Makefile,v retrieving revision 1.481 diff -u -p -r1.481 Makefile --- etc/Makefile26 Feb 2021 17:18:41 - 1.481 +++ etc/Makefile27 Feb 2021 11:03:47 - @@ -62,7 +62,7 @@ RCDAEMONS=amd apmd bgpd bootparamd cron dvmrpd eigrpd ftpd ftpproxy ftpproxy6 hostapd hotplugd httpd identd \ ifstated iked inetd isakmpd iscsid ldapd ldattach ldomd ldpd lockd \ lpd mopd mountd mrouted nfsd npppd nsd ntpd ospf6d ospfd \ - pflogd portmap rad radiusd rarpd rbootd relayd ripd route6d \ + pflogd portmap rad radiusd rarpd rbootd relayd resolvd ripd route6d \ sasyncd sensorsd slowcgi slaacd smtpd sndiod snmpd spamd \ spamlogd sshd statd switchd syslogd tftpd tftpproxy unbound \ unwind vmd watchdogd wsmoused xenodm ypbind ypldap ypserv
Re: 2 diffs for dev/acpi/dsdt.c
Hi,
Let me update "diff #2".
On Fri, 26 Feb 2021 13:42:32 +0900 (JST)
YASUOKA Masahiko wrote:
> My vaio repeatedly crashed by "Data modified on freelist"(*1) or other
> memory corruptions. After my long time debug, I found the route cause
> is a handling of references of LocalX, like the following:
>
> If ((SMRW (0x0B, 0x16, 0x21, RefOf (Local0)) == Zero))
>
> In the called control method, "RefOf (Local1)" is referred as Arg3, is
> stored a value like the following:
>
> Arg3 = \_SB.PCI0.LPCB.EC0.SMD0
>
> In aml_store(), lvalue is reset if lvalue is a LocalX. But since that
> was done before resolving the reference, lvalue was not reset if
> lvalue is a reference of LocalX.
>
> diff #1 fixes that problem. It resets lvalue after resolving
> references.
>
> ok?
>
> diff #2 adds aml_die() if any memory corruption occurs when creating
> field in a buffer. This actually happens on my vaio (pro pk 14) if
> diff #1 is not applied.
>
> ok?
>
> diff #1
>
> Index: sys/dev/acpi/dsdt.c
> ===
> RCS file: /var/cvs/openbsd/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.257
> diff -u -p -r1.257 dsdt.c
> --- sys/dev/acpi/dsdt.c 17 Dec 2020 17:57:19 - 1.257
> +++ sys/dev/acpi/dsdt.c 26 Feb 2021 04:12:03 -
> @@ -2961,11 +2961,11 @@ aml_store(struct aml_scope *scope, struc
> aml_rwfield(rhs, 0, rhs->v_field.bitlen, , ACPI_IOREAD);
> rhs =
> }
> +
> + lhs = aml_gettgt(lhs, AMLOP_STORE);
> /* Store to LocalX: free value */
> if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
> aml_freevalue(lhs);
> -
> - lhs = aml_gettgt(lhs, AMLOP_STORE);
> switch (lhs->type) {
> case AML_OBJTYPE_UNINITIALIZED:
> aml_copyvalue(lhs, rhs);
>
> diff #2
>
> Index: sys/dev/acpi/dsdt.c
> ===
> RCS file: /var/cvs/openbsd/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.257
> diff -u -p -r1.257 dsdt.c
> --- sys/dev/acpi/dsdt.c 17 Dec 2020 17:57:19 - 1.257
> +++ sys/dev/acpi/dsdt.c 26 Feb 2021 04:33:21 -
> @@ -2742,11 +2742,17 @@ aml_rwfield(struct aml_value *fld, int b
> } else if (mode == ACPI_IOREAD) {
> /* bufferfield:read */
> _aml_setvalue(val, AML_OBJTYPE_INTEGER, 0, 0);
> + if (ref1->length < aml_bytepos(fld->v_field.bitpos) +
> + aml_bytelen(fld->v_field.bitlen))
> + aml_die("bufferfield:read out of range");
> aml_bufcpy(>v_integer, 0, ref1->v_buffer,
> fld->v_field.bitpos, fld->v_field.bitlen);
> } else {
> /* bufferfield:write */
> val = aml_convert(val, AML_OBJTYPE_INTEGER, -1);
> + if (ref1->length < aml_bytepos(fld->v_field.bitpos) +
> + aml_bytelen(fld->v_field.bitlen))
> + aml_die("bufferfield:write out of range");
> aml_bufcpy(ref1->v_buffer, fld->v_field.bitpos, >v_integer,
> 0, fld->v_field.bitlen);
> aml_delref(, "wrbuffld");
It's better to die when creating a field which refers out of range
memory.
ok?
Index: sys/dev/acpi/dsdt.c
===
RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.257
diff -u -p -r1.257 dsdt.c
--- sys/dev/acpi/dsdt.c 17 Dec 2020 17:57:19 - 1.257
+++ sys/dev/acpi/dsdt.c 27 Feb 2021 09:58:31 -
@@ -2790,6 +2790,11 @@ aml_createfield(struct aml_value *field,
data->type != AML_OBJTYPE_BUFFER)
data = aml_convert(data, AML_OBJTYPE_BUFFER, -1);
+ if (field->type == AML_OBJTYPE_BUFFERFIELD &&
+ data->length < aml_bytepos(bpos) + aml_bytelen(blen))
+ aml_die("%s(%s) out of range\n", aml_mnem(opcode, 0),
+ aml_nodename(field->node));
+
field->v_field.type = opcode;
field->v_field.bitpos = bpos;
field->v_field.bitlen = blen;
dpb.1 - reuse DPB_PROPERTIES=tag mechanism
Change the description of the 'tag' property to something more generic:
- There are no more ports that have DPB_PROPERTIES=tag:{kde3,kde4} set
in their Makefile;
- Explain that only one tag set can be used.
The 'tag' property comes in handy to solve a dpb build issue with the
two audacious flavors. Instead of using a port specific tag name use
generic a/b.
Does this make sense?
Index: dpb.1
===
RCS file: /cvs/src/share/man/man1/dpb.1,v
retrieving revision 1.20
diff -u -p -r1.20 dpb.1
--- dpb.1 4 Apr 2020 08:41:54 - 1.20
+++ dpb.1 27 Feb 2021 07:49:13 -
@@ -872,16 +872,19 @@ and several build slots.
Very large port that should be built in parallel, uses
.Ev MAKE_JOBS
and lots of build slots.
-.It Ar tag:kde3
-kde3 port that conflicts with kde4 ports.
+.It Ar tag:a
Prevent scheduling ports with
-.Ar tag:kde4
+.Ar tag:b
on the same host.
-.It Ar tag:kde4
-kde4 port that conflicts with kde3 ports.
+.It Ar tag:b
Prevent scheduling ports with
-.Ar tag:kde3
+.Ar tag:a
on the same host.
+.El
+.Pp
+Note that multiple
+.Ar tag
+sets will not work simultaneously, thus only one set can be used.
.El
.Sh THE SECURITY MODEL OF DPB
When
Re: patch: adding httpd implicit file extensions
On 2021-02-27 00:38, Bruce Hill wrote:
> Hello, this is my first time contributing to openbsd and this mailing
> list, so please excuse any newbie blunders. I recently switched my
> personal website to use httpd with statically generated HTML files, but
> was unhappy to find that my HTML files could only be accessed by exact
> filename, including the ".html" at the end. My site previously ran on
> Apache with rewrite rules to ensure that "example.com/foo" would serve
> the file "/foo.html" (when "/foo" didn't exist). I wanted to keep my
> original URLs working and I aesthetically prefer URLs without ".html"
> suffixes, so I looked around for different options with httpd. The best
> option I could find was to create symbolic links from "/foo" to
> "/foo.html" and set the default media type to text/html, but this
> solution was cumbersome (I had to maintain all the symbolic links) and
> had undesirable side effects (all extensionless files were treated as
> text/html instead of text/plain).
>
Hello, wouldn't the following serve for what you want?
location not found match "^/scripts/(.*)$" {
request rewrite "/scripts/%1.php"
}
location not found match "^/(.*)$" {
request rewrite "/%1.html"
}
