acpivout(4): fix brightness not going up
Hi,
Backlight on multiple laptops will go down but not up when using brightness
keys.
Compare new brightness level to min/max values in sc_bcl[] instead.
Diff below restores backlight up function.
Index: dev/acpi/acpivout.c
===
RCS file: /cvs/src/sys/dev/acpi/acpivout.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 acpivout.c
--- dev/acpi/acpivout.c 21 Oct 2019 16:32:51 - 1.14
+++ dev/acpi/acpivout.c 3 Nov 2019 01:04:27 -
@@ -175,9 +175,9 @@ acpivout_brightness_step(struct acpivout
nlevel = acpivout_find_brightness(sc, level + (dir * BRIGHTNESS_STEP));
if (nlevel == level) {
- if (dir == 1 && (nlevel + 1 < sc->sc_bcl_len))
+ if (dir == 1 && (nlevel + 1 < sc->sc_bcl[sc->sc_bcl_len - 1]))
nlevel++;
- else if (dir == -1 && (nlevel - 1 >= 0))
+ else if (dir == -1 && (nlevel - 1 >= sc->sc_bcl[0]))
nlevel--;
}
if (nlevel == level)
km_alloc(9) & PROT_EXEC
km_alloc(9) is still not a full replacement for uvm_km_alloc(9). The
latter allows the protections of the allocation to be changed to
PROT_EXEC via uvm_map_protect(9). This is needed at least by the sti(4)
driver.
Diff below changes km_alloc(9) to allow PROT_EXEC in maxprot. With this
it is possible to convert sti(4).
However this implies that all current allocations can now have their
protection changed to be executable. This might not be what we want, in
such case I'd suggest adding a new `kp_protexec' to "struct kmem_pa_mode"
and set it specifically in dev/ic/sti.c.
Comments?
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.132
diff -u -p -r1.132 uvm_km.c
--- uvm/uvm_km.c18 Jul 2019 23:47:33 - 1.132
+++ uvm/uvm_km.c2 Nov 2019 21:15:55 -
@@ -813,7 +813,7 @@ km_alloc(size_t sz, const struct kmem_va
struct vm_page *pg;
struct pglist pgl;
int mapflags = 0;
- vm_prot_t prot;
+ vm_prot_t prot, maxprot;
paddr_t pla_align;
int pla_flags;
int pla_maxseg;
@@ -862,6 +862,7 @@ km_alloc(size_t sz, const struct kmem_va
#endif
alloc_va:
prot = PROT_READ | PROT_WRITE;
+ maxprot = prot | PROT_EXEC;
if (kp->kp_pageable) {
KASSERT(kp->kp_object);
@@ -906,7 +907,7 @@ try_map:
map = *kv->kv_map;
va = vm_map_min(map);
if (uvm_map(map, , sz, uobj, kd->kd_prefer,
- kv->kv_align, UVM_MAPFLAG(prot, prot, MAP_INHERIT_NONE,
+ kv->kv_align, UVM_MAPFLAG(prot, maxprot, MAP_INHERIT_NONE,
MADV_RANDOM, mapflags))) {
if (kv->kv_wait && kd->kd_waitok) {
tsleep(map, PVM, "km_allocva", 0);
Re: timeout.9: cite our sources
Hi Scott & Jason, Jason McIntyre wrote on Sat, Nov 02, 2019 at 06:16:49PM +: > On Sat, Nov 02, 2019 at 12:32:30PM -0500, Scott Cheloha wrote: >> Cite the paper describing the timing wheel. PDF here: >> >> http://www.cs.columbia.edu/~nahum/w6998/papers/ton97-timing-wheels.pdf >> >> The authors have an older paper describing the same idea, from 1987: >> >> http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf >> >> but the 1997 version contains additional information gathered over ten >> years of praxis. The typesetting is also way nicer in 1997. >> >> Once question about the .Rs block: why is the issue number rendered >> before the volume number? Isn't it usually the other way around? >> IIRC the issue is a subset of a given volume. > the ordering of these blocks is kind of set in stone. so mandoc will do > what groff does. i guess a reordering will involve persuading other > people that it makes sense. That is true. Then again, it does not seem unlikely that we could persuade people in this case. Whether volume and issue are used together at all may depend on the discipline (for example, in high energay physics, it appears that usually only volume and page numbers are used for citing journals). But *if* both are used together, i suspect you are right that the other order makes more sense. If you think it is worth it, tell me off-list and i'll post a trivial patch to change the order to gr...@gnu.org. Changing the order in mandoc is also trivial and would be done at the same time if the groff folks like the idea. Whatever that leads to, given both .%V and .%N only render a bare number, which certainly shouldn't be changed because i suspect using only one at a time may be the dominant use case, either order is not very clear when using both together. So i suggest quoting the numbers in exactly the same way as given in the original paper: .%V vol. 5 .%N no. 6 >> Oh, another question: is it standard to mention the city of publication >> for an academic journal in a citation? ToN is published from Piscataway, >> NJ, fwiw. > i don;t know, but i think the amount of info used in these blocks is > determined by the person adding it - how much info is useful? for rfcs, > for example, we settled on a standard blurb that both gave credit and > allowed readers to find the docs. whether you need all the refs you've > given i guess it decided by you (i think often a title suffices). I agree with Jason. For journals, in particular for well-known ones, the city of publication is often omitted because it is not really needed for getting a copy. In this case, i would probably omit it. For books, the city is often provided in citations, almost as a matter of convention. For more obscure publications, it may even be important. >> ok? > no objection from me. Same here, but i recommend the change explained above. Also, you are deleting information from the source code comment that would probably be misplaced in the manual: "Scheme 7". You might wish to leave that piece of information in the code unless it happens to be incorrect or irrelevant. Yours, Ingo >> Index: share/man/man9/timeout.9 >> === >> RCS file: /cvs/src/share/man/man9/timeout.9,v >> retrieving revision 1.46 >> diff -u -p -r1.46 timeout.9 >> --- share/man/man9/timeout.9 14 Apr 2019 08:51:31 - 1.46 >> +++ share/man/man9/timeout.9 2 Nov 2019 17:14:48 - >> @@ -282,3 +282,15 @@ These functions are implemented in the f >> .Xr splclock 9 , >> .Xr tsleep 9 , >> .Xr tvtohz 9 >> +.Rs >> +.%A George Varghese >> +.%A Anthony Lauck >> +.%B Hashed and hierarchical timing wheels: efficient data structures for \ >> +implementing a timer facility >> +.%I IEEE/ACM >> +.%J Transactions on Networking >> +.%V 5 >> +.%N 6 >> +.%P pp. 824\(en834 >> +.%D December 1997 >> +.Re >> Index: sys/kern/kern_timeout.c >> === >> RCS file: /cvs/src/sys/kern/kern_timeout.c,v >> retrieving revision 1.60 >> diff -u -p -r1.60 kern_timeout.c >> --- sys/kern/kern_timeout.c 2 Nov 2019 16:56:17 - 1.60 >> +++ sys/kern/kern_timeout.c 2 Nov 2019 17:14:48 - >> @@ -45,9 +45,7 @@ >> /* >> * Timeouts are kept in a hierarchical timing wheel. The to_time is the >> value >> * of the global variable "ticks" when the timeout should be called. There >> are >> - * four levels with 256 buckets each. See 'Scheme 7' in >> - * "Hashed and Hierarchical Timing Wheels: Efficient Data Structures for >> - * Implementing a Timer Facility" by George Varghese and Tony Lauck. >> + * four levels with 256 buckets each. >> */ >> #define BUCKETS 1024 >> #define WHEELSIZE 256
Re: fix amd64 pmap comment
On Sat, Nov 2, 2019 at 4:34 AM Martin Pieuchot wrote: > uvm_km_alloc(9) has never been used in amd64's pmap. pool_get(9) is the > thing since its import by mickey@. > > ok? > ok guenther@
Re: ftp: use stdio for TLS connections
On Sat, Nov 02 2019, Klemens Nanni wrote: > On Sat, Nov 02, 2019 at 12:32:09PM +0100, Jeremie Courreges-Anglas wrote: >> ftp(1) is not nc(1), I'd be surprised if our current ftp(1) was ported >> to another OS. :) > Meh, stupid me. > > Diff looks good so far, I can test it with miniroot and/or bsd.rd on > amd64 and/or macppc if you want. Thanks for the proposal. Testing on powerpc could be nice since iirc that platform doesn't use ftp-ssl. But the changes shouldn't negatively affect non-TLS connections. I have tested /usr/src/distrib/special/ftp and /usr/src/distrib/special/ftp-ssl, and I could not spot regressions. /usr/src/usr.bin/ftp fared well in a dpb -F run too. Throughput for TLS connections doesn't seem positively nor negatively affected either, the numbers don't change much even for connections to localhost. This change is really about making the code simpler and cleaner, which can't hurt when looking at fetch.c. PS: my initial diff also implemented a "closefn" function which would properly close the tls connection and the underlying fd so we could just call fclose(fin). But in the end ftp_close() lead to shorter code, and I wanted to keep the TLS session ticket logging, which looked weird in a supposedly pure close(2) wrapper. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: timeout.9: cite our sources
On Sat, Nov 02, 2019 at 12:32:30PM -0500, Scott Cheloha wrote: > Cite the paper describing the timing wheel. PDF here: > > http://www.cs.columbia.edu/~nahum/w6998/papers/ton97-timing-wheels.pdf > > The authors have an older paper describing the same idea, from 1987: > > http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf > > but the 1997 version contains additional information gathered over ten > years of praxis. The typesetting is also way nicer in 1997. > > Once question about the .Rs block: why is the issue number rendered > before the volume number? Isn't it usually the other way around? > IIRC the issue is a subset of a given volume. > hi. the ordering of these blocks is kind of set in stone. so mandoc will do what groff does. i guess a reordering will involve persuading other people that it makes sense. > Oh, another question: is it standard to mention the city of publication > for an academic journal in a citation? ToN is published from Piscataway, > NJ, fwiw. > i don;t know, but i think the amount of info used in these blocks is determined by the person adding it - how much info is useful? for rfcs, for example, we settled on a standard blurb that both gave credit and allowed readers to find the docs. whether you need all the refs you've given i guess it decided by you (i think often a title suffices). > ok? > no objection from me. jmc > Index: share/man/man9/timeout.9 > === > RCS file: /cvs/src/share/man/man9/timeout.9,v > retrieving revision 1.46 > diff -u -p -r1.46 timeout.9 > --- share/man/man9/timeout.9 14 Apr 2019 08:51:31 - 1.46 > +++ share/man/man9/timeout.9 2 Nov 2019 17:14:48 - > @@ -282,3 +282,15 @@ These functions are implemented in the f > .Xr splclock 9 , > .Xr tsleep 9 , > .Xr tvtohz 9 > +.Rs > +.%A George Varghese > +.%A Anthony Lauck > +.%B Hashed and hierarchical timing wheels: efficient data structures for \ > +implementing a timer facility > +.%I IEEE/ACM > +.%J Transactions on Networking > +.%V 5 > +.%N 6 > +.%P pp. 824\(en834 > +.%D December 1997 > +.Re > Index: sys/kern/kern_timeout.c > === > RCS file: /cvs/src/sys/kern/kern_timeout.c,v > retrieving revision 1.60 > diff -u -p -r1.60 kern_timeout.c > --- sys/kern/kern_timeout.c 2 Nov 2019 16:56:17 - 1.60 > +++ sys/kern/kern_timeout.c 2 Nov 2019 17:14:48 - > @@ -45,9 +45,7 @@ > /* > * Timeouts are kept in a hierarchical timing wheel. The to_time is the value > * of the global variable "ticks" when the timeout should be called. There > are > - * four levels with 256 buckets each. See 'Scheme 7' in > - * "Hashed and Hierarchical Timing Wheels: Efficient Data Structures for > - * Implementing a Timer Facility" by George Varghese and Tony Lauck. > + * four levels with 256 buckets each. > */ > #define BUCKETS 1024 > #define WHEELSIZE 256
timeout.9: cite our sources
Cite the paper describing the timing wheel. PDF here: http://www.cs.columbia.edu/~nahum/w6998/papers/ton97-timing-wheels.pdf The authors have an older paper describing the same idea, from 1987: http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf but the 1997 version contains additional information gathered over ten years of praxis. The typesetting is also way nicer in 1997. Once question about the .Rs block: why is the issue number rendered before the volume number? Isn't it usually the other way around? IIRC the issue is a subset of a given volume. Oh, another question: is it standard to mention the city of publication for an academic journal in a citation? ToN is published from Piscataway, NJ, fwiw. ok? Index: share/man/man9/timeout.9 === RCS file: /cvs/src/share/man/man9/timeout.9,v retrieving revision 1.46 diff -u -p -r1.46 timeout.9 --- share/man/man9/timeout.914 Apr 2019 08:51:31 - 1.46 +++ share/man/man9/timeout.92 Nov 2019 17:14:48 - @@ -282,3 +282,15 @@ These functions are implemented in the f .Xr splclock 9 , .Xr tsleep 9 , .Xr tvtohz 9 +.Rs +.%A George Varghese +.%A Anthony Lauck +.%B Hashed and hierarchical timing wheels: efficient data structures for \ +implementing a timer facility +.%I IEEE/ACM +.%J Transactions on Networking +.%V 5 +.%N 6 +.%P pp. 824\(en834 +.%D December 1997 +.Re Index: sys/kern/kern_timeout.c === RCS file: /cvs/src/sys/kern/kern_timeout.c,v retrieving revision 1.60 diff -u -p -r1.60 kern_timeout.c --- sys/kern/kern_timeout.c 2 Nov 2019 16:56:17 - 1.60 +++ sys/kern/kern_timeout.c 2 Nov 2019 17:14:48 - @@ -45,9 +45,7 @@ /* * Timeouts are kept in a hierarchical timing wheel. The to_time is the value * of the global variable "ticks" when the timeout should be called. There are - * four levels with 256 buckets each. See 'Scheme 7' in - * "Hashed and Hierarchical Timing Wheels: Efficient Data Structures for - * Implementing a Timer Facility" by George Varghese and Tony Lauck. + * four levels with 256 buckets each. */ #define BUCKETS 1024 #define WHEELSIZE 256
Re: fix rpki-client regress
On Sat, Nov 02, 2019 at 02:24:26PM +0100, Claudio Jeker wrote:
> Refactor the TAL loading code a bit (move the file parsing back into
> tal.c) and adjust the regress test to use this new function. This fixes
> the regress test and makes the code a bit nicer.
>
> OK?
> --
> :wq Claudio
>
> Index: usr.sbin/rpki-client/extern.h
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 extern.h
> --- usr.sbin/rpki-client/extern.h 31 Oct 2019 08:36:43 - 1.10
> +++ usr.sbin/rpki-client/extern.h 1 Nov 2019 19:59:50 -
> @@ -230,6 +230,7 @@ extern int verbose;
> void tal_buffer(char **, size_t *, size_t *, const struct tal *);
> void tal_free(struct tal *);
> struct tal *tal_parse(const char *, char *);
> +char *tal_read_file(const char *);
> struct tal *tal_read(int);
>
> void cert_buffer(char **, size_t *, size_t *, const struct cert *);
> Index: usr.sbin/rpki-client/main.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 main.c
> --- usr.sbin/rpki-client/main.c 31 Oct 2019 08:36:43 - 1.21
> +++ usr.sbin/rpki-client/main.c 1 Nov 2019 20:01:35 -
> @@ -22,7 +22,6 @@
> #include
>
> #include
> -#include
> #include
> #include
> #include
> @@ -463,59 +462,11 @@ queue_add_from_mft_set(int fd, struct en
> static void
> queue_add_tal(int fd, struct entityq *q, const char *file, size_t *eid)
> {
> - char*nfile, *nbuf, *line = NULL, *buf = NULL;
> - FILE*in;
> - ssize_t n, i;
> - size_t sz = 0, bsz = 0;
> - int optcomment = 1;
> -
> - if ((in = fopen(file, "r")) == NULL)
> - err(EXIT_FAILURE, "fopen: %s", file);
> -
> - while ((n = getline(, , in)) != -1) {
> - /* replace CRLF with just LF */
> - if (n > 1 && line[n - 1] == '\n' && line[n - 2] == '\r') {
> - line[n - 2] = '\n';
> - line[n - 1] = '\0';
> - n--;
> - }
> - if (optcomment) {
> - /* if this is comment, just eat the line */
> - if (line[0] == '#')
> - continue;
> - optcomment = 0;
> - /*
> - * Empty line is end of section and needs
> - * to be eaten as well.
> - */
> - if (line[0] == '\n')
> - continue;
> - }
> -
> - /* make sure every line is valid ascii */
> - for (i = 0; i < n; i++)
> - if (!isprint(line[i]) && !isspace(line[i]))
> - errx(EXIT_FAILURE, "getline: %s: "
> - "invalid content", file);
> -
> - /* concat line to buf */
> - if ((nbuf = realloc(buf, bsz + n + 1)) == NULL)
> - err(EXIT_FAILURE, NULL);
> - buf = nbuf;
> - bsz += n + 1;
> - strlcat(buf, line, bsz);
> - /* limit the buffer size */
> - if (bsz > 4096)
> - errx(EXIT_FAILURE, "%s: file too big", file);
> - }
> -
> - free(line);
> - if (ferror(in))
> - err(EXIT_FAILURE, "getline: %s", file);
> - fclose(in);
> + char*nfile, *buf;
>
> if ((nfile = strdup(file)) == NULL)
> err(EXIT_FAILURE, "strdup");
> + buf = tal_read_file(file);
>
> /* Not in a repository, so directly add to queue. */
> entityq_add(fd, q, nfile, RTYPE_TAL, NULL, NULL, NULL, 0, buf, eid);
> Index: usr.sbin/rpki-client/tal.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/tal.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 tal.c
> --- usr.sbin/rpki-client/tal.c31 Oct 2019 08:36:43 - 1.8
> +++ usr.sbin/rpki-client/tal.c1 Nov 2019 20:01:27 -
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -154,6 +155,63 @@ tal_parse(const char *fn, char *buf)
> p->descr[dlen] = 0;
>
> return p;
> +}
> +
> +char *
> +tal_read_file(const char *file)
> +{
> + char*nbuf, *line = NULL, *buf = NULL;
> + FILE*in;
> + ssize_t n, i;
> + size_t sz = 0, bsz = 0;
> + int optcomment = 1;
> +
> + if ((in = fopen(file, "r")) == NULL)
> + err(EXIT_FAILURE, "fopen: %s", file);
> +
> + while ((n = getline(, , in)) != -1) {
> + /* replace CRLF with just LF */
> + if (n > 1 && line[n - 1] == '\n' && line[n - 2] ==
Re: _pbuild user to have priority=5
On Sat, Nov 02, 2019 at 01:18:53PM +, Stuart Henderson wrote: > On 2019/11/01 19:16, Theo de Raadt wrote: > > Ted Unangst wrote: > > > > > Theo de Raadt wrote: > > > > What about all the other users who aren't in staff? > > > > > > > > I think the approach is right. Push non-interactive down. > > > > > > The same then for src build user? > > > > Well, that's different. Most of us building the src tree are waiting > > eagerly for it to finish aren't we? > > That's the same for ports building! > if you don't do anything else than compiling ports, that shouldn't be slower. If you are doing something else (GUI user, web server, community server with people connected doing IRC) , then you don't get angry due to unresponsive system. Lowering staff priority would only help the one user case.
fix rpki-client regress
Refactor the TAL loading code a bit (move the file parsing back into
tal.c) and adjust the regress test to use this new function. This fixes
the regress test and makes the code a bit nicer.
OK?
--
:wq Claudio
Index: usr.sbin/rpki-client/extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.10
diff -u -p -r1.10 extern.h
--- usr.sbin/rpki-client/extern.h 31 Oct 2019 08:36:43 - 1.10
+++ usr.sbin/rpki-client/extern.h 1 Nov 2019 19:59:50 -
@@ -230,6 +230,7 @@ extern int verbose;
voidtal_buffer(char **, size_t *, size_t *, const struct tal *);
voidtal_free(struct tal *);
struct tal *tal_parse(const char *, char *);
+char *tal_read_file(const char *);
struct tal *tal_read(int);
voidcert_buffer(char **, size_t *, size_t *, const struct cert *);
Index: usr.sbin/rpki-client/main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.21
diff -u -p -r1.21 main.c
--- usr.sbin/rpki-client/main.c 31 Oct 2019 08:36:43 - 1.21
+++ usr.sbin/rpki-client/main.c 1 Nov 2019 20:01:35 -
@@ -22,7 +22,6 @@
#include
#include
-#include
#include
#include
#include
@@ -463,59 +462,11 @@ queue_add_from_mft_set(int fd, struct en
static void
queue_add_tal(int fd, struct entityq *q, const char *file, size_t *eid)
{
- char*nfile, *nbuf, *line = NULL, *buf = NULL;
- FILE*in;
- ssize_t n, i;
- size_t sz = 0, bsz = 0;
- int optcomment = 1;
-
- if ((in = fopen(file, "r")) == NULL)
- err(EXIT_FAILURE, "fopen: %s", file);
-
- while ((n = getline(, , in)) != -1) {
- /* replace CRLF with just LF */
- if (n > 1 && line[n - 1] == '\n' && line[n - 2] == '\r') {
- line[n - 2] = '\n';
- line[n - 1] = '\0';
- n--;
- }
- if (optcomment) {
- /* if this is comment, just eat the line */
- if (line[0] == '#')
- continue;
- optcomment = 0;
- /*
-* Empty line is end of section and needs
-* to be eaten as well.
-*/
- if (line[0] == '\n')
- continue;
- }
-
- /* make sure every line is valid ascii */
- for (i = 0; i < n; i++)
- if (!isprint(line[i]) && !isspace(line[i]))
- errx(EXIT_FAILURE, "getline: %s: "
- "invalid content", file);
-
- /* concat line to buf */
- if ((nbuf = realloc(buf, bsz + n + 1)) == NULL)
- err(EXIT_FAILURE, NULL);
- buf = nbuf;
- bsz += n + 1;
- strlcat(buf, line, bsz);
- /* limit the buffer size */
- if (bsz > 4096)
- errx(EXIT_FAILURE, "%s: file too big", file);
- }
-
- free(line);
- if (ferror(in))
- err(EXIT_FAILURE, "getline: %s", file);
- fclose(in);
+ char*nfile, *buf;
if ((nfile = strdup(file)) == NULL)
err(EXIT_FAILURE, "strdup");
+ buf = tal_read_file(file);
/* Not in a repository, so directly add to queue. */
entityq_add(fd, q, nfile, RTYPE_TAL, NULL, NULL, NULL, 0, buf, eid);
Index: usr.sbin/rpki-client/tal.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/tal.c,v
retrieving revision 1.8
diff -u -p -r1.8 tal.c
--- usr.sbin/rpki-client/tal.c 31 Oct 2019 08:36:43 - 1.8
+++ usr.sbin/rpki-client/tal.c 1 Nov 2019 20:01:27 -
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -154,6 +155,63 @@ tal_parse(const char *fn, char *buf)
p->descr[dlen] = 0;
return p;
+}
+
+char *
+tal_read_file(const char *file)
+{
+ char*nbuf, *line = NULL, *buf = NULL;
+ FILE*in;
+ ssize_t n, i;
+ size_t sz = 0, bsz = 0;
+ int optcomment = 1;
+
+ if ((in = fopen(file, "r")) == NULL)
+ err(EXIT_FAILURE, "fopen: %s", file);
+
+ while ((n = getline(, , in)) != -1) {
+ /* replace CRLF with just LF */
+ if (n > 1 && line[n - 1] == '\n' && line[n - 2] == '\r') {
+ line[n - 2] = '\n';
+ line[n - 1] = '\0';
+ n--;
+ }
+ if (optcomment) {
+ /* if this is comment,
fix amd64 pmap comment
uvm_km_alloc(9) has never been used in amd64's pmap. pool_get(9) is the thing since its import by mickey@. ok? Index: arch/amd64/amd64/pmap.c === RCS file: /cvs/src/sys/arch/amd64/amd64/pmap.c,v retrieving revision 1.135 diff -u -p -r1.135 pmap.c --- arch/amd64/amd64/pmap.c 20 Sep 2019 09:38:22 - 1.135 +++ arch/amd64/amd64/pmap.c 2 Nov 2019 12:00:41 - @@ -180,15 +180,11 @@ * * [A] new process' page directory page (PDP) * - plan 1: done at pmap_create() we use - * uvm_km_alloc(kernel_map, PAGE_SIZE) [fka kmem_alloc] to do this - * allocation. + * pool_get(_pmap_pool, PR_WAITOK) to do this allocation. * * if we are low in free physical memory then we sleep in - * uvm_km_alloc -- in this case this is ok since we are creating + * pool_get() -- in this case this is ok since we are creating * a new pmap and should not be holding any locks. - * - * if the kernel is totally out of virtual space - * (i.e. uvm_km_alloc returns NULL), then we panic. * * XXX: the fork code currently has no way to return an "out of * memory, try again" error code since uvm_fork [fka vm_fork]
Re: _pbuild user to have priority=5
On 2019/11/01 19:16, Theo de Raadt wrote: > Ted Unangst wrote: > > > Theo de Raadt wrote: > > > What about all the other users who aren't in staff? > > > > > > I think the approach is right. Push non-interactive down. > > > > The same then for src build user? > > Well, that's different. Most of us building the src tree are waiting > eagerly for it to finish aren't we? That's the same for ports building!
Re: ftp: use stdio for TLS connections
On Sat, Nov 02, 2019 at 12:32:09PM +0100, Jeremie Courreges-Anglas wrote: > ftp(1) is not nc(1), I'd be surprised if our current ftp(1) was ported > to another OS. :) Meh, stupid me. Diff looks good so far, I can test it with miniroot and/or bsd.rd on amd64 and/or macppc if you want.
Re: ftp: use stdio for TLS connections
On Sat, Nov 02 2019, Klemens Nanni wrote: > On Sat, Nov 02, 2019 at 12:03:17PM +0100, Jeremie Courreges-Anglas wrote: >> The magic trick is funopen, which is not portable but I doubt that's >> a problem. > A lot of Linux distributions use or at least package our netcat and I'm > really glad they do; no idea what how those would work around > funopen(3) and how much we care about this, but it's worth mentioning. ftp(1) is not nc(1), I'd be surprised if our current ftp(1) was ported to another OS. :) Anyway, the glibc provides fopencookie for use cases similar to funopen. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ftp: use stdio for TLS connections
On Sat, Nov 02, 2019 at 12:03:17PM +0100, Jeremie Courreges-Anglas wrote: > The magic trick is funopen, which is not portable but I doubt that's > a problem. A lot of Linux distributions use or at least package our netcat and I'm really glad they do; no idea what how those would work around funopen(3) and how much we care about this, but it's worth mentioning.
ftp: use stdio for TLS connections
This unifies the TLS/non-TLS code paths, kills a bunch of local code,
saves some precious text size and makes the code easier to follow IMO.
The magic trick is funopen, which is not portable but I doubt that's
a problem. I added a tls_handshake() call so that TLS errors are
spotted earlier (else they would be caught by the fflush() == EOF
check).
Size decrease:
russell /usr/src/usr.bin/ftp$ size 1/fetch.o 2/fetch.o
textdatabss dec hex
17529 128 5 17662 44fe1/fetch.o
16425 120 5 16550 40a62/fetch.o
russell /usr/src/distrib/special/ftp$ size 1/fetch.o 2/fetch.o
textdatabss dec hex
10399 0 5 10404 28a41/fetch.o
10043 0 5 10048 27402/fetch.o
This went through an mkr on amd64.
ok?
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.175
diff -u -p -r1.175 fetch.c
--- fetch.c 23 Oct 2019 16:47:53 - 1.175
+++ fetch.c 2 Nov 2019 10:55:09 -
@@ -74,14 +74,13 @@ voidabortfile(int);
char hextochar(const char *);
char *urldecode(const char *);
char *recode_credentials(const char *_userinfo);
-intftp_printf(FILE *, struct tls *, const char *, ...)
__attribute__((format(printf, 3, 4)));
-char *ftp_readline(FILE *, struct tls *, size_t *);
-size_t ftp_read(FILE *, struct tls *, char *, size_t);
+char *ftp_readline(FILE *, size_t *);
void ftp_close(FILE **fin, struct tls **tls, volatile int *fd);
+const char *sockerror(struct tls *);
#ifndef NOSSL
intproxy_connect(int, char *, char *);
-intSSL_vprintf(struct tls *, const char *, va_list);
-char *SSL_readline(struct tls *, size_t *);
+intstdio_tls_write_wrapper(void *, const char *, int);
+intstdio_tls_read_wrapper(void *, char *, int);
#endif /* !NOSSL */
#defineFTP_URL "ftp://;/* ftp URL prefix */
@@ -638,6 +637,12 @@ noslash:
fprintf(ttyout, "SSL failure: %s\n", tls_error(tls));
goto cleanup_url_get;
}
+ if (tls_handshake(tls) != 0) {
+ fprintf(ttyout, "SSL failure: %s\n", tls_error(tls));
+ goto cleanup_url_get;
+ }
+ fin = funopen(tls, stdio_tls_read_wrapper,
+ stdio_tls_write_wrapper, NULL, NULL);
} else {
fin = fdopen(fd, "r+");
fd = -1;
@@ -682,13 +687,13 @@ noslash:
* the original URI (path).
*/
if (credentials)
- ftp_printf(fin, tls, "GET %s HTTP/1.0\r\n"
+ fprintf(fin, "GET %s HTTP/1.0\r\n"
"Proxy-Authorization: Basic %s\r\n"
"Host: %s\r\n%s%s\r\n\r\n",
epath, credentials,
proxyhost, buf ? buf : "", httpuseragent);
else
- ftp_printf(fin, tls, "GET %s HTTP/1.0\r\n"
+ fprintf(fin, "GET %s HTTP/1.0\r\n"
"Host: %s\r\n%s%s\r\n\r\n",
epath, proxyhost, buf ? buf : "", httpuseragent);
} else {
@@ -706,7 +711,7 @@ noslash:
#endif /* SMALL */
#ifndef NOSSL
if (credentials) {
- ftp_printf(fin, tls,
+ fprintf(fin,
"GET /%s %s\r\nAuthorization: Basic %s\r\nHost: ",
epath, restart_point ?
"HTTP/1.1\r\nConnection: close" : "HTTP/1.0",
@@ -715,13 +720,13 @@ noslash:
credentials = NULL;
} else
#endif /* NOSSL */
- ftp_printf(fin, tls, "GET /%s %s\r\nHost: ", epath,
+ fprintf(fin, "GET /%s %s\r\nHost: ", epath,
#ifndef SMALL
restart_point ? "HTTP/1.1\r\nConnection: close" :
#endif /* !SMALL */
"HTTP/1.0");
if (proxyhost) {
- ftp_printf(fin, tls, "%s", proxyhost);
+ fprintf(fin, "%s", proxyhost);
port = NULL;
} else if (strchr(host, ':')) {
/*
@@ -733,10 +738,10 @@ noslash:
errx(1, "Can't allocate memory.");
if ((p = strchr(h, '%')) != NULL)
*p = '\0';
- ftp_printf(fin, tls, "[%s]", h);
+ fprintf(fin, "[%s]", h);
free(h);
} else
- ftp_printf(fin, tls, "%s", host);
+ fprintf(fin, "%s", host);
/*
Re: Opportunistic DoT for unwind(8)
On Sat, Nov 02, 2019 at 08:20:08AM +0100, Otto Moerbeek wrote:
> On Fri, Nov 01, 2019 at 10:43:27PM +0100, Remi Locherer wrote:
>
> > On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote:
> > > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote:
> > > > On Fri, Nov 01, 2019 at 09:35:07PM +0100, Remi Locherer wrote:
> > > > > On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote:
> > > > > > Hi,
> > > > > >
> > > > > > So here's a new diff that incorporates the bug fix mentioned plus
> > > > > > debug printf line changes suggested by Stuart.
> > > > > >
> > > > > > Please note that this is a diff on top of very recent current, i.e.
> > > > > > florian's work he committed today. That means that you need to be
> > > > > > up-to-date (including a recent libc update that was committed a few
> > > > > > days ago) to be able to test this version.
> > > > >
> > > > > I upgraded to a snapshot from today, updated the source and applied
> > > > > your diff. Then I did the same test as last time using pf to block
> > > > > port 53
> > > > > (block return out log inet proto {tcp udp} to !9.9.9.9 port 53).
> > > > >
> > > > > Result: the non functional type asr is selected instead of the
> > > > > forwarder.
> > > > >
> > > > > $ doas unwindctl status
> > > > > captive portal is unknown
> > > > >
> > > > > selected type status
> > > > > recursor dead
> > > > > forwarder validating (OppDoT)
> > > > > dhcp unknown (OppDoT)
> > > > >* asr dead
> > > > > $
> > > > > $ getent hosts undeadly.org
> > > > > $ echo $?
> > > > > 2
> > > > > $ dig +short undeadly.org @9.9.9.9
> > > > > 94.142.241.173
> > > > > $
> > > > >
> > > > > Without your patch unwind behaves similar regarding the type
> > > > > selection:
> > > > >
> > > > > $ doas unwindctl status
> > > > > captive portal is unknown
> > > >
> > > > ^ you are creating a not supported configuration.
> > > >
> > > > When we are behind a captive portal or don't know yet if we are behind
> > > > a captive portal resolving is forced to asr.
> > > >
> > > > That might not be very wise if asr is dead but I currently don't see
> > > > how this can happen in practice except with a well aimed foot-gun.
> > >
> > > Actually, I have an idea how this can happen in practice, please try this:
> > >
> > > diff --git resolver.c resolver.c
> > > index f59860a5e98..5bbc63f60fa 100644
> > > --- resolver.c
> > > +++ resolver.c
> > > @@ -1282,7 +1282,8 @@ best_resolver(void)
> > >
> > > if (captive_portal_state == PORTAL_UNKNOWN || captive_portal_state ==
> > > BEHIND) {
> > > - if (resolvers[UW_RES_ASR] != NULL) {
> > > + if (resolvers[UW_RES_ASR] != NULL && resolvers[UW_RES_ASR]->
> > > +state != DEAD) {
> > > res = resolvers[UW_RES_ASR];
> > > goto out;
> > > }
> > >
> > >
> >
> > Yes, this makes unwind cope with this situation:
> >
> > $ unwindctl status
> > not behind captive portal
> >
> > selected type status
> > recursor dead
> >*forwarder validating
> > dhcp dead
> > asr dead
> > $
> >
> > OK remi@
> >
>
> And with my diff on top of that?
Yes, now it works as expected.
OK remi@
Re: iwm: switch 7260 devices to new firmware
seems to be working fine on my gen2 X1 On Wed, Oct 30, 2019 at 02:44:17PM +0100, Stefan Sperling wrote: > This switches 7260 iwm(4) devices to the iwm-7260-17 firmware image > which has been available via fw_update in -current for a while. > > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x73, msi > iwm0: hw rev 0x140, fw ver 17.-1078622920.0, address xx:xx:xx:xx:xx:xx > > This firmware seems to work fine since my most recent commits to the driver. > Tested also in bsd.rd. > > ok? > > diff 7e2975b685e9b68ec42d557370a6fe7d530ff8d5 /usr/src > blob - da9a807015a64cd002bbcae5dd9a14de9c462c4c > file + sys/dev/pci/if_iwm.c > --- sys/dev/pci/if_iwm.c > +++ sys/dev/pci/if_iwm.c > @@ -8153,7 +8153,7 @@ iwm_attach(struct device *parent, struct device *self, > break; > case PCI_PRODUCT_INTEL_WL_7260_1: > case PCI_PRODUCT_INTEL_WL_7260_2: > - sc->sc_fwname = "iwm-7260-16"; > + sc->sc_fwname = "iwm-7260-17"; > sc->host_interrupt_operation_mode = 1; > sc->sc_device_family = IWM_DEVICE_FAMILY_7000; > sc->sc_fwdmasegsz = IWM_FWDMASEGSZ; > -- I'm not entirely sure you are real.
Re: Kill uvm_deallocate()
> Date: Sat, 2 Nov 2019 10:55:30 +0100
> From: Martin Pieuchot
>
> This function is just a wrapper on top of uvm_unmap(), it has its own
> file and is called only 3 times in the kernel. Getting rid of it makes
> the overall UVM simpler, ok?
>
> Index: sys/conf/files
> ===
> RCS file: /cvs/src/sys/conf/files,v
> retrieving revision 1.675
> diff -u -p -r1.675 files
> --- sys/conf/files5 Oct 2019 05:33:14 - 1.675
> +++ sys/conf/files2 Nov 2019 09:40:31 -
> @@ -970,7 +970,6 @@ file uvm/uvm_stat.c
> file uvm/uvm_swap.c
> file uvm/uvm_swap_encrypt.c uvm_swap_encrypt
> file uvm/uvm_unix.c
> -file uvm/uvm_user.c
> file uvm/uvm_vnode.c
>
> # IPv6
> Index: sys/kern/kern_exec.c
> ===
> RCS file: /cvs/src/sys/kern/kern_exec.c,v
> retrieving revision 1.208
> diff -u -p -r1.208 kern_exec.c
> --- sys/kern/kern_exec.c 2 Aug 2019 02:17:35 - 1.208
> +++ sys/kern/kern_exec.c 2 Nov 2019 09:40:31 -
> @@ -749,8 +749,7 @@ exec_abort:
>* get rid of the (new) address space we have created, if any, get rid
>* of our namei data and vnode, and exit noting failure
>*/
> - uvm_deallocate(>vm_map, VM_MIN_ADDRESS,
> - VM_MAXUSER_ADDRESS - VM_MIN_ADDRESS);
> + uvm_unmap(>vm_map, VM_MIN_ADDRESS, VM_MAXUSER_ADDRESS);
> if (pack.ep_interp != NULL)
> pool_put(_pool, pack.ep_interp);
> if (pack.ep_emul_arg != NULL)
> Index: sys/kern/sysv_shm.c
> ===
> RCS file: /cvs/src/sys/kern/sysv_shm.c,v
> retrieving revision 1.72
> diff -u -p -r1.72 sysv_shm.c
> --- sys/kern/sysv_shm.c 28 Oct 2019 19:57:50 - 1.72
> +++ sys/kern/sysv_shm.c 2 Nov 2019 09:40:31 -
> @@ -160,14 +160,14 @@ shm_delete_mapping(struct vmspace *vm, s
> {
> struct shmid_ds *shmseg;
> int segnum;
> - size_t size;
> + vaddr_t end;
>
> segnum = IPCID_TO_IX(shmmap_s->shmid);
> if (segnum < 0 || segnum >= shminfo.shmmni ||
> (shmseg = shmsegs[segnum]) == NULL)
> return (EINVAL);
> - size = round_page(shmseg->shm_segsz);
> - uvm_deallocate(>vm_map, shmmap_s->va, size);
> + end = round_page(shmmap_s->va+shmseg->shm_segsz);
Please add spaces around the '+'. Otherwise ok kettenis@
> + uvm_unmap(>vm_map, trunc_page(shmmap_s->va), end);
> shmmap_s->shmid = -1;
> shmseg->shm_dtime = time_second;
> if ((--shmseg->shm_nattch <= 0) &&
> Index: sys/uvm/uvm_extern.h
> ===
> RCS file: /cvs/src/sys/uvm/uvm_extern.h,v
> retrieving revision 1.148
> diff -u -p -r1.148 uvm_extern.h
> --- sys/uvm/uvm_extern.h 1 Jul 2019 21:13:03 - 1.148
> +++ sys/uvm/uvm_extern.h 2 Nov 2019 09:40:31 -
> @@ -455,7 +455,6 @@ int uvm_coredump_walkmap(struct
> proc *
> uvm_coredump_setup_cb *_setup,
> uvm_coredump_walk_cb *_walk, void *_cookie);
> void uvm_grow(struct proc *, vaddr_t);
> -void uvm_deallocate(vm_map_t, vaddr_t, vsize_t);
> struct uvm_object*uvn_attach(struct vnode *, vm_prot_t);
> void uvm_pagezero_thread(void *);
> void kmeminit_nkmempages(void);
> Index: sys/uvm/uvm_unix.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_unix.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 uvm_unix.c
> --- sys/uvm/uvm_unix.c21 Jun 2019 09:39:49 - 1.66
> +++ sys/uvm/uvm_unix.c2 Nov 2019 09:40:31 -
> @@ -94,7 +94,7 @@ sys_obreak(struct proc *p, void *v, regi
> }
> vm->vm_dsize += atop(new - old);
> } else {
> - uvm_deallocate(>vm_map, new, old - new);
> + uvm_unmap(>vm_map, new, old);
> vm->vm_dsize -= atop(old - new);
> }
>
> Index: sys/uvm/uvm_user.c
> ===
> RCS file: sys/uvm/uvm_user.c
> diff -N sys/uvm/uvm_user.c
> --- sys/uvm/uvm_user.c14 Sep 2014 14:17:27 - 1.14
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,55 +0,0 @@
> -/* $OpenBSD: uvm_user.c,v 1.14 2014/09/14 14:17:27 jsg Exp $ */
> -/* $NetBSD: uvm_user.c,v 1.8 2000/06/27 17:29:37 mrg Exp $ */
> -
> -/*
> - * Copyright (c) 1997 Charles D. Cranor and Washington University.
> - * All rights reserved.
> - *
> - * Redistribution and use in source and binary forms, with or without
> - * modification, are permitted provided that the following conditions
> - * are met:
> - * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of conditions and the following disclaimer.
> - * 2. Redistributions in binary
Kill uvm_deallocate()
This function is just a wrapper on top of uvm_unmap(), it has its own
file and is called only 3 times in the kernel. Getting rid of it makes
the overall UVM simpler, ok?
Index: sys/conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.675
diff -u -p -r1.675 files
--- sys/conf/files 5 Oct 2019 05:33:14 - 1.675
+++ sys/conf/files 2 Nov 2019 09:40:31 -
@@ -970,7 +970,6 @@ file uvm/uvm_stat.c
file uvm/uvm_swap.c
file uvm/uvm_swap_encrypt.cuvm_swap_encrypt
file uvm/uvm_unix.c
-file uvm/uvm_user.c
file uvm/uvm_vnode.c
# IPv6
Index: sys/kern/kern_exec.c
===
RCS file: /cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.208
diff -u -p -r1.208 kern_exec.c
--- sys/kern/kern_exec.c2 Aug 2019 02:17:35 - 1.208
+++ sys/kern/kern_exec.c2 Nov 2019 09:40:31 -
@@ -749,8 +749,7 @@ exec_abort:
* get rid of the (new) address space we have created, if any, get rid
* of our namei data and vnode, and exit noting failure
*/
- uvm_deallocate(>vm_map, VM_MIN_ADDRESS,
- VM_MAXUSER_ADDRESS - VM_MIN_ADDRESS);
+ uvm_unmap(>vm_map, VM_MIN_ADDRESS, VM_MAXUSER_ADDRESS);
if (pack.ep_interp != NULL)
pool_put(_pool, pack.ep_interp);
if (pack.ep_emul_arg != NULL)
Index: sys/kern/sysv_shm.c
===
RCS file: /cvs/src/sys/kern/sysv_shm.c,v
retrieving revision 1.72
diff -u -p -r1.72 sysv_shm.c
--- sys/kern/sysv_shm.c 28 Oct 2019 19:57:50 - 1.72
+++ sys/kern/sysv_shm.c 2 Nov 2019 09:40:31 -
@@ -160,14 +160,14 @@ shm_delete_mapping(struct vmspace *vm, s
{
struct shmid_ds *shmseg;
int segnum;
- size_t size;
+ vaddr_t end;
segnum = IPCID_TO_IX(shmmap_s->shmid);
if (segnum < 0 || segnum >= shminfo.shmmni ||
(shmseg = shmsegs[segnum]) == NULL)
return (EINVAL);
- size = round_page(shmseg->shm_segsz);
- uvm_deallocate(>vm_map, shmmap_s->va, size);
+ end = round_page(shmmap_s->va+shmseg->shm_segsz);
+ uvm_unmap(>vm_map, trunc_page(shmmap_s->va), end);
shmmap_s->shmid = -1;
shmseg->shm_dtime = time_second;
if ((--shmseg->shm_nattch <= 0) &&
Index: sys/uvm/uvm_extern.h
===
RCS file: /cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision 1.148
diff -u -p -r1.148 uvm_extern.h
--- sys/uvm/uvm_extern.h1 Jul 2019 21:13:03 - 1.148
+++ sys/uvm/uvm_extern.h2 Nov 2019 09:40:31 -
@@ -455,7 +455,6 @@ int uvm_coredump_walkmap(struct proc *
uvm_coredump_setup_cb *_setup,
uvm_coredump_walk_cb *_walk, void *_cookie);
void uvm_grow(struct proc *, vaddr_t);
-void uvm_deallocate(vm_map_t, vaddr_t, vsize_t);
struct uvm_object *uvn_attach(struct vnode *, vm_prot_t);
void uvm_pagezero_thread(void *);
void kmeminit_nkmempages(void);
Index: sys/uvm/uvm_unix.c
===
RCS file: /cvs/src/sys/uvm/uvm_unix.c,v
retrieving revision 1.66
diff -u -p -r1.66 uvm_unix.c
--- sys/uvm/uvm_unix.c 21 Jun 2019 09:39:49 - 1.66
+++ sys/uvm/uvm_unix.c 2 Nov 2019 09:40:31 -
@@ -94,7 +94,7 @@ sys_obreak(struct proc *p, void *v, regi
}
vm->vm_dsize += atop(new - old);
} else {
- uvm_deallocate(>vm_map, new, old - new);
+ uvm_unmap(>vm_map, new, old);
vm->vm_dsize -= atop(old - new);
}
Index: sys/uvm/uvm_user.c
===
RCS file: sys/uvm/uvm_user.c
diff -N sys/uvm/uvm_user.c
--- sys/uvm/uvm_user.c 14 Sep 2014 14:17:27 - 1.14
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,55 +0,0 @@
-/* $OpenBSD: uvm_user.c,v 1.14 2014/09/14 14:17:27 jsg Exp $ */
-/* $NetBSD: uvm_user.c,v 1.8 2000/06/27 17:29:37 mrg Exp $ */
-
-/*
- * Copyright (c) 1997 Charles D. Cranor and Washington University.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
- * IMPLIED WARRANTIES,
Re: Opportunistic DoT for unwind(8)
On Fri, Nov 01, 2019 at 10:43:27PM +0100, Remi Locherer wrote:
> On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote:
> > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote:
> > > On Fri, Nov 01, 2019 at 09:35:07PM +0100, Remi Locherer wrote:
> > > > On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote:
> > > > > Hi,
> > > > >
> > > > > So here's a new diff that incorporates the bug fix mentioned plus
> > > > > debug printf line changes suggested by Stuart.
> > > > >
> > > > > Please note that this is a diff on top of very recent current, i.e.
> > > > > florian's work he committed today. That means that you need to be
> > > > > up-to-date (including a recent libc update that was committed a few
> > > > > days ago) to be able to test this version.
> > > >
> > > > I upgraded to a snapshot from today, updated the source and applied
> > > > your diff. Then I did the same test as last time using pf to block port
> > > > 53
> > > > (block return out log inet proto {tcp udp} to !9.9.9.9 port 53).
> > > >
> > > > Result: the non functional type asr is selected instead of the
> > > > forwarder.
> > > >
> > > > $ doas unwindctl status
> > > > captive portal is unknown
> > > >
> > > > selected type status
> > > > recursor dead
> > > > forwarder validating (OppDoT)
> > > > dhcp unknown (OppDoT)
> > > >* asr dead
> > > > $
> > > > $ getent hosts undeadly.org
> > > > $ echo $?
> > > > 2
> > > > $ dig +short undeadly.org @9.9.9.9
> > > > 94.142.241.173
> > > > $
> > > >
> > > > Without your patch unwind behaves similar regarding the type selection:
> > > >
> > > > $ doas unwindctl status
> > > > captive portal is unknown
> > >
> > > ^ you are creating a not supported configuration.
> > >
> > > When we are behind a captive portal or don't know yet if we are behind
> > > a captive portal resolving is forced to asr.
> > >
> > > That might not be very wise if asr is dead but I currently don't see
> > > how this can happen in practice except with a well aimed foot-gun.
> >
> > Actually, I have an idea how this can happen in practice, please try this:
> >
> > diff --git resolver.c resolver.c
> > index f59860a5e98..5bbc63f60fa 100644
> > --- resolver.c
> > +++ resolver.c
> > @@ -1282,7 +1282,8 @@ best_resolver(void)
> >
> > if (captive_portal_state == PORTAL_UNKNOWN || captive_portal_state ==
> > BEHIND) {
> > - if (resolvers[UW_RES_ASR] != NULL) {
> > + if (resolvers[UW_RES_ASR] != NULL && resolvers[UW_RES_ASR]->
> > +state != DEAD) {
> > res = resolvers[UW_RES_ASR];
> > goto out;
> > }
> >
> >
>
> Yes, this makes unwind cope with this situation:
>
> $ unwindctl status
> not behind captive portal
>
> selected type status
> recursor dead
>*forwarder validating
> dhcp dead
> asr dead
> $
>
> OK remi@
>
And with my diff on top of that?
-Otto
