macppc clang: fix va_arg in Objective-C
Hello tech list, clang for 32-bit powerpc has a bug that breaks va_arg(3) when the argument type is an object or block in Objective-C. This breaks GNUstep on macppc. This clang diff fixes GNUstep. Objective-C uses pointers to represent objects and blocks, so this diff tells clang's va_arg to handle things with pointer representations as pointers. Anthony Richardby found and reported the bug, https://bugs.llvm.org/show_bug.cgi?id=47921 I posted this diff at https://reviews.llvm.org/D90329 but upstream llvm might do something else. I used a clang with this diff to rebuild src and xenocara on macppc. ok to commit? --George Index: clang/lib/CodeGen/TargetInfo.cpp === RCS file: /cvs/src/gnu/llvm/clang/lib/CodeGen/TargetInfo.cpp,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 TargetInfo.cpp --- clang/lib/CodeGen/TargetInfo.cpp9 Aug 2020 15:51:11 - 1.1.1.2 +++ clang/lib/CodeGen/TargetInfo.cpp28 Oct 2020 23:43:54 - @@ -4248,8 +4248,8 @@ Address PPC32_SVR4_ABIInfo::EmitVAArg(Co // }; bool isI64 = Ty->isIntegerType() && getContext().getTypeSize(Ty) == 64; - bool isInt = - Ty->isIntegerType() || Ty->isPointerType() || Ty->isAggregateType(); + bool isInt = Ty->isIntegerType() || Ty->hasPointerRepresentation() || + Ty->isAggregateType(); bool isF64 = Ty->isFloatingType() && getContext().getTypeSize(Ty) == 64; // All aggregates are passed indirectly? That doesn't seem consistent
Re: Lenovo X1 gen 8 touchpad interrupt: pchgpio(4)
On 10/14/20, Mark Kettenis wrote:
>> From: James Hastings
>> Date: Sun, 11 Oct 2020 03:49:11 -0400 (EDT)
>>
>> On Thu, 08 Oct 2020 20:29:38 + Mark Kettenis wrote:
>> > Diff below adds a driver for the GPIO controller found on the Intel
>> > 400 Series PCH as found on (for example) the Lenovo X1 gen 8 laptop.
>> > Since I don't have such hardware, I'd appreciate some tests on laptops
>> > that current show:
>> >
>> > "INT34BB" at acpi0 not configured
>> >
>>
>> Thanks for the driver Mark! Compiles fine here but panics like this:
>> ihidev0 at iic0 addr 0x2c gpio 291panic: kernel diagnostic assertion "pin
>> >= 0 && pin < sc->sc_npins" failed: file
>> "/usr/src/sys/dev/acpi/pchgpio.c", line 335
>>
>> Let me know any way I can help.
>
> Can you figure out what pin number it is trying to use?
>
> Thanks,
>
> Mark
>
> P.S. Feel free to finish the driver yourself if you have time. This
> sort of thing is way easier if you have the hardware. The
> hardware itself should be very similar to aplgpio(4). It's just
> that the registers moved around a bit and there is a single ACPI
> device for all the pin "communities" instead of the model of
> separate ACPI devices for each community that aplgpio(4) uses.
>
Election day surprise! Touchpad now works on my 400 Series laptop INT34BB.
Please test on Sunrisepoint/100 Series INT344B as I do not have that hardware.
The Cannonlake INT34BB controller is numbered as if there are 32 GPIO pins
per group. The real pins are packed together and vary from 8 to 25 pins per
group. In my case, GPIO 291 maps to pin 208, offset 27, bank 1, bar 2 (GPP_E).
dmesg and vmstat -zi included. Interrupt count is after moving cursor to xterm.
Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.494
diff -u -p -u -r1.494 GENERIC
--- arch/amd64/conf/GENERIC 27 Oct 2020 02:39:07 - 1.494
+++ arch/amd64/conf/GENERIC 4 Nov 2020 02:03:06 -
@@ -66,6 +66,7 @@ aplgpio* at acpi?
bytgpio* at acpi?
chvgpio* at acpi?
glkgpio* at acpi?
+pchgpio* at acpi?
sdhc* at acpi?
acpicbkbd* at acpi?
acpials* at acpi?
Index: dev/acpi/files.acpi
===
RCS file: /cvs/src/sys/dev/acpi/files.acpi,v
retrieving revision 1.58
diff -u -p -u -r1.58 files.acpi
--- dev/acpi/files.acpi 27 Oct 2020 02:39:07 - 1.58
+++ dev/acpi/files.acpi 4 Nov 2020 02:03:07 -
@@ -151,6 +151,11 @@ device glkgpio
attach glkgpio at acpi
file dev/acpi/glkgpio.c glkgpio
+# Intel PCH GPIO
+device pchgpio
+attach pchgpio at acpi
+file dev/acpi/pchgpio.c pchgpio
+
# "Intel" Dollar Cove TI PMIC
device tipmic
attach tipmic at i2c
Index: dev/acpi/pchgpio.c
===
RCS file: dev/acpi/pchgpio.c
diff -N dev/acpi/pchgpio.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/acpi/pchgpio.c 4 Nov 2020 02:03:07 -
@@ -0,0 +1,415 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2020 Mark Kettenis
+ * Copyright (c) 2020 James Hastings
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define PCHGPIO_MAXCOM 4
+
+#define PCHGPIO_CONF_TXSTATE 0x0001
+#define PCHGPIO_CONF_RXSTATE 0x0002
+#define PCHGPIO_CONF_RXINV 0x0080
+#define PCHGPIO_CONF_RXEV_EDGE 0x0200
+#define PCHGPIO_CONF_RXEV_ZERO 0x0400
+#define PCHGPIO_CONF_RXEV_MASK 0x0600
+
+#define PCHGPIO_PADBAR 0x00c
+
+struct pchgpio_group {
+ uint8_t bar;
+ uint8_t bank;
+ uint16_tbase;
+ uint16_tlimit;
+ uint16_toffset;
+ int16_t gpiobase;
+};
+
+struct pchgpio_device {
+ uint16_tpad_own;
+ uint16_tpad_size;
+ uint16_tpadcfglock;
+ uint16_thostsw_own;
+ uint16_tgpi_is;
+ uint16_tgpi_ie;
+ struct pchgpio_group *groups;
+ int ngroups;
+ int npins;
+};
+
+struct pchgpio_match {
+
Re: Mellanox ConnectX-6 Driver no working
Nilson Lopes [noslin...@gmail.com] wrote: > > If we look carefully in the list of PCI codes in '/sys/dev/pci/pcidevs' > source code here > https://github.com/openbsd/src/blob/master/sys/dev/pci/pcidevs#L6323-L6335, > we see that the card I'm using is known as MELLANOX MT28908. > [image: image.png] > > > But, the source code for the 'mcx' driver does not have that particular > model: > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_mcx.c#L2536-L2546 It may be as simple as adding the pci device to the matching list in sys/dev/pci/if_mcx.c and installing your new kernel. You could just put the new if_mcx.o file into the kernel relink directory and relink if you want to do quick tests. Also you are best using 6.8-current as it has some mcx fixes that are post 6.8-release. Chris
Re: acme-client(1): replace httpd(8) location block in manpage by better match
Florian Obser(flor...@openbsd.org) on 2020.11.03 14:52:55 +0100:
> On Tue, Nov 03, 2020 at 10:37:04AM +0100, Matthias Pressfreund wrote:
> >
> > On 2020-11-03 09:56, Florian Obser wrote:
> > > On Mon, Nov 02, 2020 at 02:35:48PM +0100, Matthias Pressfreund wrote:
> > >> The patch below updates the acme-client(1) manpage by providing a
> > >> closer match for the httpd(8) location block accepting acme challenge
> > >> responses.
> > >
> > > How is this better?
> > >
> > > When the requested file exits in /var/www/acme/ I get a 200 in both cases.
> > > When the file does not exists I get a 404 in both cases.
> > >
> >
> > It is better because I may not want the server to return 404 if the file
> > does not exist. Instead, I may want to let the server fall back to its
> > default behavior as shown in the example below where it would simply drop
> > the connection.
> >
> > server "example.com" {
> > ...
> > block drop
> > location found "/.well-known/acme-challenge/*" { ... }
> > ...
> > }
>
> I don't know, I'm not buying it, this doesn't feel neccesary for acme.
> We wanted to have a minimal example that gets people going with
> acme-client and httpd, now we have more fluff.
>
> But I guess it's just me, so meh.
Its not just you.
I think the example is fine.
Re: Refactor bgpd control code
Claudio Jeker(cje...@diehard.n-r-g.com) on 2020.11.03 09:09:47 +0100:
> On Wed, Oct 21, 2020 at 07:16:07PM +0200, Claudio Jeker wrote:
> > This refactors the control code a bit and removes the common var from the
> > session.h header. The session engine no longer walks the control
> > connection list. Additionally cleanup the control.c code around
> > control_dispatch_msg(). E.g. don't do double lookups of control sessions
> > by fd to close them.
> >
> > OK?
ok
>
> Ping
>
> --
> :wq Claudio
>
> Index: control.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
> retrieving revision 1.100
> diff -u -p -r1.100 control.c
> --- control.c 10 May 2020 13:38:46 - 1.100
> +++ control.c 21 Oct 2020 16:57:53 -
> @@ -29,11 +29,13 @@
> #include "session.h"
> #include "log.h"
>
> +TAILQ_HEAD(ctl_conns, ctl_conn) ctl_conns =
> TAILQ_HEAD_INITIALIZER(ctl_conns);
> +
> #define CONTROL_BACKLOG 5
>
> struct ctl_conn *control_connbyfd(int);
> struct ctl_conn *control_connbypid(pid_t);
> -int control_close(int);
> +int control_close(struct ctl_conn *);
> void control_result(struct ctl_conn *, u_int);
> ssize_t imsg_read_nofd(struct imsgbuf *);
>
> @@ -136,6 +138,22 @@ control_shutdown(int fd)
> close(fd);
> }
>
> +size_t
> +control_fill_pfds(struct pollfd *pfd, size_t size)
> +{
> + struct ctl_conn *ctl_conn;
> + size_t i = 0;
> +
> + TAILQ_FOREACH(ctl_conn, &ctl_conns, entry) {
> + pfd[i].fd = ctl_conn->ibuf.fd;
> + pfd[i].events = POLLIN;
> + if (ctl_conn->ibuf.w.queued > 0)
> + pfd[i].events |= POLLOUT;
> + i++;
> + }
> + return i;
> +}
> +
> unsigned int
> control_accept(int listenfd, int restricted)
> {
> @@ -198,15 +216,8 @@ control_connbypid(pid_t pid)
> }
>
> int
> -control_close(int fd)
> +control_close(struct ctl_conn *c)
> {
> - struct ctl_conn *c;
> -
> - if ((c = control_connbyfd(fd)) == NULL) {
> - log_warn("control_close: fd %d: not found", fd);
> - return (0);
> - }
> -
> if (c->terminate && c->ibuf.pid)
> imsg_ctl_rde(IMSG_CTL_TERMINATE, c->ibuf.pid, NULL, 0);
>
> @@ -220,8 +231,7 @@ control_close(int fd)
> }
>
> int
> -control_dispatch_msg(struct pollfd *pfd, u_int *ctl_cnt,
> -struct peer_head *peers)
> +control_dispatch_msg(struct pollfd *pfd, struct peer_head *peers)
> {
> struct imsg imsg;
> struct ctl_conn *c;
> @@ -237,10 +247,8 @@ control_dispatch_msg(struct pollfd *pfd,
> }
>
> if (pfd->revents & POLLOUT) {
> - if (msgbuf_write(&c->ibuf.w) <= 0 && errno != EAGAIN) {
> - *ctl_cnt -= control_close(pfd->fd);
> - return (1);
> - }
> + if (msgbuf_write(&c->ibuf.w) <= 0 && errno != EAGAIN)
> + return control_close(c);
> if (c->throttled && c->ibuf.w.queued < CTL_MSG_LOW_MARK) {
> if (imsg_ctl_rde(IMSG_XON, c->ibuf.pid, NULL, 0) != -1)
> c->throttled = 0;
> @@ -251,16 +259,12 @@ control_dispatch_msg(struct pollfd *pfd,
> return (0);
>
> if (((n = imsg_read_nofd(&c->ibuf)) == -1 && errno != EAGAIN) ||
> - n == 0) {
> - *ctl_cnt -= control_close(pfd->fd);
> - return (1);
> - }
> + n == 0)
> + return control_close(c);
>
> for (;;) {
> - if ((n = imsg_get(&c->ibuf, &imsg)) == -1) {
> - *ctl_cnt -= control_close(pfd->fd);
> - return (1);
> - }
> + if ((n = imsg_get(&c->ibuf, &imsg)) == -1)
> + return control_close(c);
>
> if (n == 0)
> break;
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.402
> diff -u -p -r1.402 session.c
> --- session.c 27 Jun 2020 07:24:42 - 1.402
> +++ session.c 21 Oct 2020 16:49:10 -
> @@ -196,7 +196,6 @@ session_main(int debug, int verbose)
> struct peer *p, **peer_l = NULL, *next;
> struct mrt *m, *xm, **mrt_l = NULL;
> struct pollfd *pfd = NULL;
> - struct ctl_conn *ctl_conn;
> struct listen_addr *la;
> void*newp;
> time_t now;
> @@ -237,7 +236,6 @@ session_main(int debug, int verbose)
> fatal(NULL);
> imsg_init(ibuf_main, 3);
>
> - TAILQ_INIT(&ctl_conns);
> LIST_INIT(&mrthead);
> listener_cnt = 0;
> peer_cnt = 0;
> @@ -438,13 +436,10 @@ session_main(int debug, int verbose)
>
> idx_mrts = i;
>
> - TAILQ_FOREACH(ctl_conn,
Re: cleanup bgpd commons first step
ok
Claudio Jeker(cje...@diehard.n-r-g.com) on 2020.11.03 09:07:31 +0100:
> On Wed, Oct 21, 2020 at 06:08:05PM +0200, Claudio Jeker wrote:
> > Bgpd uses many common symbols and the latest compilers are being picky
> > about these common symbols.
> > This removes the global bgpd_process variable and cleans up the filter_set
> > code to not depend on process knowledge (instead use a new type and don't
> > overload another one).
>
> Ping
>
> --
> :wq Claudio
>
> Index: bgpd.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
> retrieving revision 1.229
> diff -u -p -r1.229 bgpd.c
> --- bgpd.c11 May 2020 16:59:19 - 1.229
> +++ bgpd.c21 Oct 2020 07:18:00 -
> @@ -117,10 +117,9 @@ main(int argc, char *argv[])
> int pipe_m2r[2];
>
> conffile = CONFFILE;
> - bgpd_process = PROC_MAIN;
>
> log_init(1, LOG_DAEMON);/* log to stderr until daemonized */
> - log_procinit(log_procnames[bgpd_process]);
> + log_procinit(log_procnames[PROC_MAIN]);
> log_setverbose(1);
>
> saved_argv0 = argv[0];
> Index: bgpd.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> retrieving revision 1.403
> diff -u -p -r1.403 bgpd.h
> --- bgpd.h10 May 2020 13:38:46 - 1.403
> +++ bgpd.h21 Oct 2020 07:29:53 -
> @@ -120,7 +120,7 @@ enum bgpd_process {
> PROC_MAIN,
> PROC_SE,
> PROC_RDE
> -} bgpd_process;
> +};
>
> enum reconf_action {
> RECONF_NONE,
> @@ -995,6 +995,7 @@ enum action_types {
> ACTION_SET_PREPEND_PEER,
> ACTION_SET_AS_OVERRIDE,
> ACTION_SET_NEXTHOP,
> + ACTION_SET_NEXTHOP_REF,
> ACTION_SET_NEXTHOP_REJECT,
> ACTION_SET_NEXTHOP_BLACKHOLE,
> ACTION_SET_NEXTHOP_NOMODIFY,
> @@ -1017,7 +1018,7 @@ struct filter_set {
> u_int32_tmetric;
> int32_t relative;
> struct bgpd_addr nexthop;
> - struct nexthop *nh;
> + struct nexthop *nh_ref;
> struct community community;
> char pftable[PFTABLE_LEN];
> char rtlabel[RTLABEL_LEN];
> Index: printconf.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/printconf.c,v
> retrieving revision 1.142
> diff -u -p -r1.142 printconf.c
> --- printconf.c 23 Apr 2020 16:13:11 - 1.142
> +++ printconf.c 21 Oct 2020 07:32:06 -
> @@ -356,6 +356,7 @@ print_set(struct filter_set_head *set)
> break;
> case ACTION_RTLABEL_ID:
> case ACTION_PFTABLE_ID:
> + case ACTION_SET_NEXTHOP_REF:
> /* not possible */
> printf("king bula saiz: config broken");
> break;
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.503
> diff -u -p -r1.503 rde.c
> --- rde.c 21 Oct 2020 06:56:32 - 1.503
> +++ rde.c 21 Oct 2020 09:39:49 -
> @@ -157,8 +157,7 @@ rde_main(int debug, int verbose)
> log_init(debug, LOG_DAEMON);
> log_setverbose(verbose);
>
> - bgpd_process = PROC_RDE;
> - log_procinit(log_procnames[bgpd_process]);
> + log_procinit(log_procnames[PROC_RDE]);
>
> if ((pw = getpwnam(BGPD_USER)) == NULL)
> fatal("getpwnam");
> @@ -509,8 +508,11 @@ badnetdel:
> if ((s = malloc(sizeof(struct filter_set))) == NULL)
> fatal(NULL);
> memcpy(s, imsg.data, sizeof(struct filter_set));
> - if (s->type == ACTION_SET_NEXTHOP)
> - s->action.nh = nexthop_get(&s->action.nexthop);
> + if (s->type == ACTION_SET_NEXTHOP) {
> + s->action.nh_ref =
> + nexthop_get(&s->action.nexthop);
> + s->type = ACTION_SET_NEXTHOP_REF;
> + }
> TAILQ_INSERT_TAIL(&session_set, s, entry);
> break;
> case IMSG_CTL_SHOW_NETWORK:
> @@ -922,8 +924,11 @@ rde_dispatch_imsg_parent(struct imsgbuf
> if ((s = malloc(sizeof(struct filter_set))) == NULL)
> fatal(NULL);
> memcpy(s, imsg.data, sizeof(struct filter_set));
> - if (s->type == ACTION_SET_NEXTHOP)
> - s->action.nh = nexthop_get(&s->action.nexthop);
> + if (s->type == ACTION_SET_NEXTHOP) {
> + s->action.nh
Re: [PATCH] tcpdump: Fix missing argument from icmp_print call in print-skip.c
On Tue, Nov 03 2020, Theo Buehler wrote: > On Tue, Nov 03, 2020 at 04:19:34PM +0530, Neeraj Pal wrote: >> Hi all, >> >> It seems that there is a typo, 2nd argument - length is missing from >> the function call icmp_print in print-skip.c > > There is quite a bit more that is wrong with print-skip.c than just > that (try to add it to the Makefile and compile it). It was unhooked > from the build in 1996. > > Shouldn't it rather be sent to the attic? I think it can be safely removed. ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: accton(8) requires a reboot after being enabled
I don't think we should do that. Alexander Bluhm wrote: > On Fri, Oct 30, 2020 at 09:59:09AM -0600, Theo de Raadt wrote: > > 1 - historically it requires a file to be pre-created. In the rc scripts, > > this is a touch. That grabs the umask and ownership of root's run of > > /etc/rc. > > 2 - could we do better, in some way? > > We could do the same as we do with other logfiles. Create them > during installation like syslog log files. User can simply enable > accounting. Nothing changes for existing installations. > > bluhm > > Index: distrib/sets/lists/etc/mi > === > RCS file: /data/mirror/openbsd/cvs/src/distrib/sets/lists/etc/mi,v > retrieving revision 1.218 > diff -u -p -r1.218 mi > --- distrib/sets/lists/etc/mi 2 Dec 2019 02:45:18 - 1.218 > +++ distrib/sets/lists/etc/mi 3 Nov 2020 16:55:31 - > @@ -50,6 +50,7 @@ > ./root/.login > ./root/.profile > ./root/.ssh/authorized_keys > +./var/account/acct > ./var/crash/minfree > ./var/cron/at.deny > ./var/cron/cron.deny >
Re: accton(8) requires a reboot after being enabled
On Fri, Oct 30, 2020 at 09:59:09AM -0600, Theo de Raadt wrote: > 1 - historically it requires a file to be pre-created. In the rc scripts, > this is a touch. That grabs the umask and ownership of root's run of > /etc/rc. > 2 - could we do better, in some way? We could do the same as we do with other logfiles. Create them during installation like syslog log files. User can simply enable accounting. Nothing changes for existing installations. bluhm Index: distrib/sets/lists/etc/mi === RCS file: /data/mirror/openbsd/cvs/src/distrib/sets/lists/etc/mi,v retrieving revision 1.218 diff -u -p -r1.218 mi --- distrib/sets/lists/etc/mi 2 Dec 2019 02:45:18 - 1.218 +++ distrib/sets/lists/etc/mi 3 Nov 2020 16:55:31 - @@ -50,6 +50,7 @@ ./root/.login ./root/.profile ./root/.ssh/authorized_keys +./var/account/acct ./var/crash/minfree ./var/cron/at.deny ./var/cron/cron.deny
Re: acme-client(1): replace httpd(8) location block in manpage by better match
On Tue, Nov 03, 2020 at 10:37:04AM +0100, Matthias Pressfreund wrote:
>
> On 2020-11-03 09:56, Florian Obser wrote:
> > On Mon, Nov 02, 2020 at 02:35:48PM +0100, Matthias Pressfreund wrote:
> >> The patch below updates the acme-client(1) manpage by providing a
> >> closer match for the httpd(8) location block accepting acme challenge
> >> responses.
> >
> > How is this better?
> >
> > When the requested file exits in /var/www/acme/ I get a 200 in both cases.
> > When the file does not exists I get a 404 in both cases.
> >
>
> It is better because I may not want the server to return 404 if the file
> does not exist. Instead, I may want to let the server fall back to its
> default behavior as shown in the example below where it would simply drop
> the connection.
>
> server "example.com" {
> ...
> block drop
> location found "/.well-known/acme-challenge/*" { ... }
> ...
> }
I don't know, I'm not buying it, this doesn't feel neccesary for acme.
We wanted to have a minimal example that gets people going with
acme-client and httpd, now we have more fluff.
But I guess it's just me, so meh.
>
> > If /var/www/acme itself is missing I get 404 without this and 500 with
> > this patch. Why is 500 better?
> >
>
> Even in this case I like the 500 better as it reflects the state of my
> server, like if I point a location's root to a directory that does not
> exist, my server truly suffers from an 'internal server error'.
>
>
> > Thanks,
> > Florian
> >>
> >>
> >> Index: usr.sbin/acme-client/acme-client.1
> >> ===
> >> RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
> >> retrieving revision 1.34
> >> diff -u -p -u -p -r1.34 acme-client.1
> >> --- usr.sbin/acme-client/acme-client.1 10 May 2020 12:06:18 -
> >> 1.34
> >> +++ usr.sbin/acme-client/acme-client.1 2 Nov 2020 13:18:12 -
> >> @@ -14,7 +14,7 @@
> >> .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
> >> OF
> >> .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> >> .\"
> >> -.Dd $Mdocdate: May 10 2020 $
> >> +.Dd $Mdocdate: November 2 2020 $
> >> .Dt ACME-CLIENT 1
> >> .Os
> >> .Sh NAME
> >> @@ -58,7 +58,7 @@ can be served by
> >> with this location block,
> >> which will properly map response challenges:
> >> .Bd -literal -offset indent
> >> -location "/.well-known/acme-challenge/*" {
> >> +location found "/.well-known/acme-challenge/*" {
> >>root "/acme"
> >>request strip 2
> >> }
> >>
> >
>
--
I'm not entirely sure you are real.
Re: [PATCH] tcpdump: Fix missing argument from icmp_print call in print-skip.c
On Tue, Nov 03, 2020 at 04:19:34PM +0530, Neeraj Pal wrote: > Hi all, > > It seems that there is a typo, 2nd argument - length is missing from > the function call icmp_print in print-skip.c There is quite a bit more that is wrong with print-skip.c than just that (try to add it to the Makefile and compile it). It was unhooked from the build in 1996. Shouldn't it rather be sent to the attic?
[PATCH] tcpdump: Fix missing argument from icmp_print call in print-skip.c
Hi all,
It seems that there is a typo, 2nd argument - length is missing from
the function call icmp_print in print-skip.c
File: usr.sbin/tcpdump/print-skip.c
577void skip_print_next(u_char nxt, const u_char *p, int len,
const u_char *bp2)
578{
579switch(nxt) {
580case IPPROTO_IP: ip_print(p,len); break;
581case IPPROTO_ICMP: icmp_print(p,bp2); break;
File: usr.sbin/tcpdump/print-icmp.c
165void
166icmp_print(const u_char *bp, u_int length, const u_char *bp2)
167{
168const struct icmp *dp;
169const struct ip *ip;
This patch fixes the same.
Regards,
Neeraj Pal
Index: usr.sbin/tcpdump/print-skip.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-skip.c,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 print-skip.c
--- usr.sbin/tcpdump/print-skip.c16 Nov 2015 00:16:39 -1.6
+++ usr.sbin/tcpdump/print-skip.c3 Nov 2020 10:25:32 -
@@ -578,7 +578,7 @@ void skip_print_next(u_char nxt, const u
{
switch(nxt) {
case IPPROTO_IP: ip_print(p,len); break;
-case IPPROTO_ICMP: icmp_print(p,bp2); break;
+case IPPROTO_ICMP: icmp_print(p,len,bp2); break;
case IPPROTO_TCP: tcp_print(p,len,bp2); break;
case IPPROTO_UDP: udp_print(p,len,bp2); break;
case IPPROTO_ESP: esp_print(p,len,bp2); break;
Re: acme-client(1): replace httpd(8) location block in manpage by better match
On 2020-11-03 09:56, Florian Obser wrote:
> On Mon, Nov 02, 2020 at 02:35:48PM +0100, Matthias Pressfreund wrote:
>> The patch below updates the acme-client(1) manpage by providing a
>> closer match for the httpd(8) location block accepting acme challenge
>> responses.
>
> How is this better?
>
> When the requested file exits in /var/www/acme/ I get a 200 in both cases.
> When the file does not exists I get a 404 in both cases.
>
It is better because I may not want the server to return 404 if the file
does not exist. Instead, I may want to let the server fall back to its
default behavior as shown in the example below where it would simply drop
the connection.
server "example.com" {
...
block drop
location found "/.well-known/acme-challenge/*" { ... }
...
}
> If /var/www/acme itself is missing I get 404 without this and 500 with
> this patch. Why is 500 better?
>
Even in this case I like the 500 better as it reflects the state of my
server, like if I point a location's root to a directory that does not
exist, my server truly suffers from an 'internal server error'.
> Thanks,
> Florian
>>
>>
>> Index: usr.sbin/acme-client/acme-client.1
>> ===
>> RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
>> retrieving revision 1.34
>> diff -u -p -u -p -r1.34 acme-client.1
>> --- usr.sbin/acme-client/acme-client.1 10 May 2020 12:06:18 -
>> 1.34
>> +++ usr.sbin/acme-client/acme-client.1 2 Nov 2020 13:18:12 -
>> @@ -14,7 +14,7 @@
>> .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>> .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>> .\"
>> -.Dd $Mdocdate: May 10 2020 $
>> +.Dd $Mdocdate: November 2 2020 $
>> .Dt ACME-CLIENT 1
>> .Os
>> .Sh NAME
>> @@ -58,7 +58,7 @@ can be served by
>> with this location block,
>> which will properly map response challenges:
>> .Bd -literal -offset indent
>> -location "/.well-known/acme-challenge/*" {
>> +location found "/.well-known/acme-challenge/*" {
>> root "/acme"
>> request strip 2
>> }
>>
>
Re: accton(8) requires a reboot after being enabled
Hi Jason, Jason McIntyre wrote on Mon, Nov 02, 2020 at 05:29:37PM +: > - adding EXIT STATUS makes sense. i agree. So i added just the .Sh and .Ex lines. All the rest (both regarding "file" and "install") seems controversial and hardly worth have a long discussion, so i dropped all the rest. Yours, Ingo
Re: acme-client(1): replace httpd(8) location block in manpage by better match
On Mon, Nov 02, 2020 at 02:35:48PM +0100, Matthias Pressfreund wrote:
> The patch below updates the acme-client(1) manpage by providing a
> closer match for the httpd(8) location block accepting acme challenge
> responses.
How is this better?
When the requested file exits in /var/www/acme/ I get a 200 in both cases.
When the file does not exists I get a 404 in both cases.
If /var/www/acme itself is missing I get 404 without this and 500 with
this patch. Why is 500 better?
Thanks,
Florian
>
>
> Index: usr.sbin/acme-client/acme-client.1
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
> retrieving revision 1.34
> diff -u -p -u -p -r1.34 acme-client.1
> --- usr.sbin/acme-client/acme-client.110 May 2020 12:06:18 -
> 1.34
> +++ usr.sbin/acme-client/acme-client.12 Nov 2020 13:18:12 -
> @@ -14,7 +14,7 @@
> .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> .\"
> -.Dd $Mdocdate: May 10 2020 $
> +.Dd $Mdocdate: November 2 2020 $
> .Dt ACME-CLIENT 1
> .Os
> .Sh NAME
> @@ -58,7 +58,7 @@ can be served by
> with this location block,
> which will properly map response challenges:
> .Bd -literal -offset indent
> -location "/.well-known/acme-challenge/*" {
> +location found "/.well-known/acme-challenge/*" {
> root "/acme"
> request strip 2
> }
>
--
I'm not entirely sure you are real.
Re: Refactor bgpd control code
On Wed, Oct 21, 2020 at 07:16:07PM +0200, Claudio Jeker wrote:
> This refactors the control code a bit and removes the common var from the
> session.h header. The session engine no longer walks the control
> connection list. Additionally cleanup the control.c code around
> control_dispatch_msg(). E.g. don't do double lookups of control sessions
> by fd to close them.
>
> OK?
Ping
--
:wq Claudio
Index: control.c
===
RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
retrieving revision 1.100
diff -u -p -r1.100 control.c
--- control.c 10 May 2020 13:38:46 - 1.100
+++ control.c 21 Oct 2020 16:57:53 -
@@ -29,11 +29,13 @@
#include "session.h"
#include "log.h"
+TAILQ_HEAD(ctl_conns, ctl_conn) ctl_conns = TAILQ_HEAD_INITIALIZER(ctl_conns);
+
#defineCONTROL_BACKLOG 5
struct ctl_conn*control_connbyfd(int);
struct ctl_conn*control_connbypid(pid_t);
-int control_close(int);
+int control_close(struct ctl_conn *);
voidcontrol_result(struct ctl_conn *, u_int);
ssize_t imsg_read_nofd(struct imsgbuf *);
@@ -136,6 +138,22 @@ control_shutdown(int fd)
close(fd);
}
+size_t
+control_fill_pfds(struct pollfd *pfd, size_t size)
+{
+ struct ctl_conn *ctl_conn;
+ size_t i = 0;
+
+ TAILQ_FOREACH(ctl_conn, &ctl_conns, entry) {
+ pfd[i].fd = ctl_conn->ibuf.fd;
+ pfd[i].events = POLLIN;
+ if (ctl_conn->ibuf.w.queued > 0)
+ pfd[i].events |= POLLOUT;
+ i++;
+ }
+ return i;
+}
+
unsigned int
control_accept(int listenfd, int restricted)
{
@@ -198,15 +216,8 @@ control_connbypid(pid_t pid)
}
int
-control_close(int fd)
+control_close(struct ctl_conn *c)
{
- struct ctl_conn *c;
-
- if ((c = control_connbyfd(fd)) == NULL) {
- log_warn("control_close: fd %d: not found", fd);
- return (0);
- }
-
if (c->terminate && c->ibuf.pid)
imsg_ctl_rde(IMSG_CTL_TERMINATE, c->ibuf.pid, NULL, 0);
@@ -220,8 +231,7 @@ control_close(int fd)
}
int
-control_dispatch_msg(struct pollfd *pfd, u_int *ctl_cnt,
-struct peer_head *peers)
+control_dispatch_msg(struct pollfd *pfd, struct peer_head *peers)
{
struct imsg imsg;
struct ctl_conn *c;
@@ -237,10 +247,8 @@ control_dispatch_msg(struct pollfd *pfd,
}
if (pfd->revents & POLLOUT) {
- if (msgbuf_write(&c->ibuf.w) <= 0 && errno != EAGAIN) {
- *ctl_cnt -= control_close(pfd->fd);
- return (1);
- }
+ if (msgbuf_write(&c->ibuf.w) <= 0 && errno != EAGAIN)
+ return control_close(c);
if (c->throttled && c->ibuf.w.queued < CTL_MSG_LOW_MARK) {
if (imsg_ctl_rde(IMSG_XON, c->ibuf.pid, NULL, 0) != -1)
c->throttled = 0;
@@ -251,16 +259,12 @@ control_dispatch_msg(struct pollfd *pfd,
return (0);
if (((n = imsg_read_nofd(&c->ibuf)) == -1 && errno != EAGAIN) ||
- n == 0) {
- *ctl_cnt -= control_close(pfd->fd);
- return (1);
- }
+ n == 0)
+ return control_close(c);
for (;;) {
- if ((n = imsg_get(&c->ibuf, &imsg)) == -1) {
- *ctl_cnt -= control_close(pfd->fd);
- return (1);
- }
+ if ((n = imsg_get(&c->ibuf, &imsg)) == -1)
+ return control_close(c);
if (n == 0)
break;
Index: session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.402
diff -u -p -r1.402 session.c
--- session.c 27 Jun 2020 07:24:42 - 1.402
+++ session.c 21 Oct 2020 16:49:10 -
@@ -196,7 +196,6 @@ session_main(int debug, int verbose)
struct peer *p, **peer_l = NULL, *next;
struct mrt *m, *xm, **mrt_l = NULL;
struct pollfd *pfd = NULL;
- struct ctl_conn *ctl_conn;
struct listen_addr *la;
void*newp;
time_t now;
@@ -237,7 +236,6 @@ session_main(int debug, int verbose)
fatal(NULL);
imsg_init(ibuf_main, 3);
- TAILQ_INIT(&ctl_conns);
LIST_INIT(&mrthead);
listener_cnt = 0;
peer_cnt = 0;
@@ -438,13 +436,10 @@ session_main(int debug, int verbose)
idx_mrts = i;
- TAILQ_FOREACH(ctl_conn, &ctl_conns, entry) {
- pfd[i].fd = ctl_conn->ibuf.fd;
- pfd[i].events = POLLIN;
- if (ctl_conn->ibuf.w.queued > 0)
- pfd[i].events
Re: cleanup bgpd commons first step
On Wed, Oct 21, 2020 at 06:08:05PM +0200, Claudio Jeker wrote:
> Bgpd uses many common symbols and the latest compilers are being picky
> about these common symbols.
> This removes the global bgpd_process variable and cleans up the filter_set
> code to not depend on process knowledge (instead use a new type and don't
> overload another one).
Ping
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.229
diff -u -p -r1.229 bgpd.c
--- bgpd.c 11 May 2020 16:59:19 - 1.229
+++ bgpd.c 21 Oct 2020 07:18:00 -
@@ -117,10 +117,9 @@ main(int argc, char *argv[])
int pipe_m2r[2];
conffile = CONFFILE;
- bgpd_process = PROC_MAIN;
log_init(1, LOG_DAEMON);/* log to stderr until daemonized */
- log_procinit(log_procnames[bgpd_process]);
+ log_procinit(log_procnames[PROC_MAIN]);
log_setverbose(1);
saved_argv0 = argv[0];
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.403
diff -u -p -r1.403 bgpd.h
--- bgpd.h 10 May 2020 13:38:46 - 1.403
+++ bgpd.h 21 Oct 2020 07:29:53 -
@@ -120,7 +120,7 @@ enum bgpd_process {
PROC_MAIN,
PROC_SE,
PROC_RDE
-} bgpd_process;
+};
enum reconf_action {
RECONF_NONE,
@@ -995,6 +995,7 @@ enum action_types {
ACTION_SET_PREPEND_PEER,
ACTION_SET_AS_OVERRIDE,
ACTION_SET_NEXTHOP,
+ ACTION_SET_NEXTHOP_REF,
ACTION_SET_NEXTHOP_REJECT,
ACTION_SET_NEXTHOP_BLACKHOLE,
ACTION_SET_NEXTHOP_NOMODIFY,
@@ -1017,7 +1018,7 @@ struct filter_set {
u_int32_tmetric;
int32_t relative;
struct bgpd_addr nexthop;
- struct nexthop *nh;
+ struct nexthop *nh_ref;
struct community community;
char pftable[PFTABLE_LEN];
char rtlabel[RTLABEL_LEN];
Index: printconf.c
===
RCS file: /cvs/src/usr.sbin/bgpd/printconf.c,v
retrieving revision 1.142
diff -u -p -r1.142 printconf.c
--- printconf.c 23 Apr 2020 16:13:11 - 1.142
+++ printconf.c 21 Oct 2020 07:32:06 -
@@ -356,6 +356,7 @@ print_set(struct filter_set_head *set)
break;
case ACTION_RTLABEL_ID:
case ACTION_PFTABLE_ID:
+ case ACTION_SET_NEXTHOP_REF:
/* not possible */
printf("king bula saiz: config broken");
break;
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.503
diff -u -p -r1.503 rde.c
--- rde.c 21 Oct 2020 06:56:32 - 1.503
+++ rde.c 21 Oct 2020 09:39:49 -
@@ -157,8 +157,7 @@ rde_main(int debug, int verbose)
log_init(debug, LOG_DAEMON);
log_setverbose(verbose);
- bgpd_process = PROC_RDE;
- log_procinit(log_procnames[bgpd_process]);
+ log_procinit(log_procnames[PROC_RDE]);
if ((pw = getpwnam(BGPD_USER)) == NULL)
fatal("getpwnam");
@@ -509,8 +508,11 @@ badnetdel:
if ((s = malloc(sizeof(struct filter_set))) == NULL)
fatal(NULL);
memcpy(s, imsg.data, sizeof(struct filter_set));
- if (s->type == ACTION_SET_NEXTHOP)
- s->action.nh = nexthop_get(&s->action.nexthop);
+ if (s->type == ACTION_SET_NEXTHOP) {
+ s->action.nh_ref =
+ nexthop_get(&s->action.nexthop);
+ s->type = ACTION_SET_NEXTHOP_REF;
+ }
TAILQ_INSERT_TAIL(&session_set, s, entry);
break;
case IMSG_CTL_SHOW_NETWORK:
@@ -922,8 +924,11 @@ rde_dispatch_imsg_parent(struct imsgbuf
if ((s = malloc(sizeof(struct filter_set))) == NULL)
fatal(NULL);
memcpy(s, imsg.data, sizeof(struct filter_set));
- if (s->type == ACTION_SET_NEXTHOP)
- s->action.nh = nexthop_get(&s->action.nexthop);
+ if (s->type == ACTION_SET_NEXTHOP) {
+ s->action.nh_ref =
+ nexthop_get(&s->action.nexthop);
+ s->type = ACTION_SET_NEXTHOP_REF;
+ }
