Re: if_mue.c: loop -> memset
On Fri, Aug 03, 2018 at 01:00:57PM +0800, Michael W. Bombardieri wrote: > > Hello, > > When reading over the mue(4) code I noticed that memset() can be used > for clearing hashtbl. Also the switch case for IFM_100_TX was the same > code as for IFM_1000_T so it can be rolled into one. Committed, thanks. > - Michael
Re: correct nd6_timer_next accounting
Anyone brave enough to OK this? I haven't heard from anyone that it
breaks their internet...
On Wed, Aug 01, 2018 at 11:18:02PM +0200, Florian Obser wrote:
> I'm chasing a bug in IPv6 where ndp reports an entry as (incomplete)
> but when you try to reach that target no neighbor solicitation is
> send.
>
> I think the reason for that is that no new nd6_timer is scheduled
> because the code thinks it is already scheduled. Maybe. I'm having a
> hard time reproducing this. The stars need to align just right or
> something.
>
> nd6_llinfo_settimer() does the following accounting:
>
> if (!timeout_pending(&nd6_timer_to) || expire < nd6_timer_next) {
> nd6_timer_next = expire;
> timeout_add_sec(&nd6_timer_to, secs);
> }
>
> i.e. it keeps track of when the timeout will fire in nd6_timer_next.
>
> However, when the timeout fires and nd6_timer() runs it works out when
> to schedule the next timeout, but it doesn't keep track of when that
> is.
>
> This seems better, I have no idea if it improves things though.
>
> While here change nd_timer_next to time_t because seing an int there
> made my skin crawl. It probably doesn't matter though.
>
> Test? Comments? OKs?
>
> diff --git netinet6/nd6.c netinet6/nd6.c
> index bce15ad5135..a123d4e2f93 100644
> --- netinet6/nd6.c
> +++ netinet6/nd6.c
> @@ -67,7 +67,7 @@
> #define ND6_RECALC_REACHTM_INTERVAL (60 * 120) /* 2 hours */
>
> /* timer values */
> -int nd6_timer_next = -1; /* at which time_uptime nd6_timer runs */
> +time_t nd6_timer_next = -1; /* at which time_uptime nd6_timer runs
> */
> time_t nd6_expire_next = -1; /* at which time_uptime nd6_expire runs
> */
> int nd6_delay = 5;/* delay first probe time 5 second */
> int nd6_umaxtries = 3;/* maximum unicast query */
> @@ -336,8 +336,10 @@ nd6_timer(void *arg)
> secs = expire - time_uptime;
> if (secs < 0)
> secs = 0;
> - if (!TAILQ_EMPTY(&nd6_list))
> + if (!TAILQ_EMPTY(&nd6_list)) {
> + nd6_timer_next = time_uptime + secs;
> timeout_add_sec(&nd6_timer_to, secs);
> + }
>
> NET_UNLOCK();
> }
>
> --
> I'm not entirely sure you are real.
>
--
I'm not entirely sure you are real.
if_mue.c: loop -> memset
Hello,
When reading over the mue(4) code I noticed that memset() can be used
for clearing hashtbl. Also the switch case for IFM_100_TX was the same
code as for IFM_1000_T so it can be rolled into one.
- Michael
Index: if_mue.c
===
RCS file: /cvs/src/sys/dev/usb/if_mue.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 if_mue.c
--- if_mue.c3 Aug 2018 01:50:15 - 1.1
+++ if_mue.c3 Aug 2018 04:50:51 -
@@ -301,8 +301,6 @@ mue_miibus_statchg(struct device *dev)
switch (IFM_SUBTYPE(mii->mii_media_active)) {
case IFM_10_T:
case IFM_100_TX:
- sc->mue_link++;
- break;
case IFM_1000_T:
sc->mue_link++;
break;
@@ -969,7 +967,6 @@ mue_iff(struct mue_softc *sc)
struct ether_multi *enm;
struct ether_multistep step;
uint32_t h = 0, hashtbl[MUE_DP_SEL_VHF_HASH_LEN], reg, rxfilt;
- int i;
if (usbd_is_dying(sc->mue_udev))
return;
@@ -992,8 +989,7 @@ mue_iff(struct mue_softc *sc)
rxfilt |= MUE_RFE_CTL_PERFECT | MUE_RFE_CTL_MULTICAST_HASH;
/* Clear hash table. */
- for (i = 0; i < MUE_DP_SEL_VHF_HASH_LEN; i++)
- hashtbl[i] = 0;
+ memset(hashtbl, 0, sizeof(hashtbl));
/* Now program new ones. */
ETHER_FIRST_MULTI(step, ac, enm);
Re: unveil: incomplete unveil_flagmatch semantic
On Thu, Aug 02, 2018 at 03:42:03PM +0200, Sebastien Marie wrote: > On Mon, Jul 30, 2018 at 07:55:35AM -0600, Bob Beck wrote: > > yeah the latter will be the way to go > > > > new diff with direct lookup using an indirection table. > new (emergency) version with PLEDGE_CHOWN consideration for unveil(2). sorry for having missed it. Thanks. -- Sebastien Marie Index: sys/pledge.h === RCS file: /cvs/src/sys/sys/pledge.h,v retrieving revision 1.37 diff -u -p -r1.37 pledge.h --- sys/pledge.h13 Jul 2018 09:25:23 - 1.37 +++ sys/pledge.h3 Aug 2018 04:19:55 - @@ -23,54 +23,64 @@ #include /* - * pledge(2) requests + * pledge(2) promises */ #define PLEDGE_ALWAYS 0xULL + +/* promises used in ni_pledge */ #define PLEDGE_RPATH 0x0001ULL /* allow open for read */ #define PLEDGE_WPATH 0x0002ULL /* allow open for write */ #define PLEDGE_CPATH 0x0004ULL /* allow creat, mkdir, unlink etc */ -#define PLEDGE_STDIO 0x0008ULL /* operate on own pid */ -#define PLEDGE_TMPPATH 0x0010ULL /* for mk*temp() */ -#define PLEDGE_DNS 0x0020ULL /* DNS services */ -#define PLEDGE_INET0x0040ULL /* AF_INET/AF_INET6 sockets */ -#define PLEDGE_FLOCK 0x0080ULL /* file locking */ -#define PLEDGE_UNIX0x0100ULL /* AF_UNIX sockets */ -#define PLEDGE_ID 0x0200ULL /* allow setuid, setgid, etc */ -#define PLEDGE_TAPE0x0400ULL /* Tape ioctl */ -#define PLEDGE_GETPW 0x0800ULL /* YP enables if ypbind.lock */ -#define PLEDGE_PROC0x1000ULL /* fork, waitpid, etc */ -#define PLEDGE_SETTIME 0x2000ULL /* able to set/adj time/freq */ -#define PLEDGE_FATTR 0x4000ULL /* allow explicit file st_* mods */ -#define PLEDGE_PROTEXEC0x8000ULL /* allow use of PROT_EXEC */ -#define PLEDGE_TTY 0x0001ULL /* tty setting */ -#define PLEDGE_SENDFD 0x0002ULL /* AF_UNIX CMSG fd sending */ -#define PLEDGE_RECVFD 0x0004ULL /* AF_UNIX CMSG fd receiving */ -#define PLEDGE_EXEC0x0008ULL /* execve, child is free of pledge */ -#define PLEDGE_ROUTE 0x0010ULL /* routing lookups */ -#define PLEDGE_MCAST 0x0020ULL /* multicast joins */ -#define PLEDGE_VMINFO 0x0040ULL /* vminfo listings */ -#define PLEDGE_PS 0x0080ULL /* ps listings */ -#define PLEDGE_DISKLABEL 0x0200ULL /* disklabels */ -#define PLEDGE_PF 0x0400ULL /* pf ioctls */ -#define PLEDGE_AUDIO 0x0800ULL /* audio ioctls */ -#define PLEDGE_DPATH 0x1000ULL /* mknod & mkfifo */ -#define PLEDGE_DRM 0x2000ULL /* drm ioctls */ -#define PLEDGE_VMM 0x4000ULL /* vmm ioctls */ -#define PLEDGE_CHOWN 0x8000ULL /* chown(2) family */ -#define PLEDGE_CHOWNUID0x0001ULL /* allow owner/group changes */ -#define PLEDGE_BPF 0x0002ULL /* bpf ioctl */ -#define PLEDGE_ERROR 0x0004ULL /* ENOSYS instead of kill */ -#define PLEDGE_WROUTE 0x0008ULL /* interface address ioctls */ -#define PLEDGE_UNVEIL 0x0010ULL /* allow unveil() */ +#define PLEDGE_DPATH 0x0008ULL /* mknod & mkfifo */ +#define PLEDGE_FATTR 0x0010ULL /* allow explicit file st_* mods */ +#define PLEDGE_TTY 0x0020ULL /* tty setting */ +#define PLEDGE_UNIX0x0040ULL /* AF_UNIX sockets */ +#define PLEDGE_EXEC0x0080ULL /* execve, child is free of pledge */ +#define PLEDGE_CHOWN 0x0100ULL /* chown(2) family */ + +#define UNVEIL_PLDGMASK0x01ffULL + +/* these could occurs in ni_pledge but are ignored */ +#define PLEDGE_UNVEIL 0x0200ULL /* allow unveil() */ +#define PLEDGE_STAT0x0400ULL /* XXX this is a stat */ +#define PLEDGE_STATLIE 0x0800ULL + +#define UNVEIL_PLDGIGN (PLEDGE_UNVEIL|PLEDGE_STAT|PLEDGE_STATLIE) + +/* others promises */ +#define PLEDGE_STDIO 0x1000ULL /* operate on own pid */ +#define PLEDGE_TMPPATH 0x2000ULL /* for mk*temp() */ +#define PLEDGE_DNS 0x4000ULL /* DNS services */ +#define PLEDGE_INET0x8000ULL /* AF_INET/AF_INET6 sockets */ +#define PLEDGE_FLOCK 0x0001ULL /* file locking */ +#define PLEDGE_ID 0x0002ULL /* allow setuid, setgid, etc */ +#define PLEDGE_TAPE0x0004ULL /* Tape ioctl */ +#define PLEDGE_GETPW 0x0008ULL /* YP enables if ypbind.lock */ +#define PLEDGE_PROC0x0010ULL /* fork, waitpid, etc */ +#define PLEDGE_SETTIME 0x002
Re: panic: unveil_nipledge_lookup: unexpected pledge bits: 8589934592 after update to recent -current
Reported it here: https://marc.info/?l=openbsd-bugs&m=153324017411435&w=2 Should I have posted to tech@ instead? I can confirm the next snapshot fixed the panic.
Re: panic: unveil_nipledge_lookup: unexpected pledge bits: 8589934592 after update to recent -current
On Fri, Aug 03, 2018 at 12:02:17AM +0200, Felix Maschek wrote: > Hi, > > I've updated to the recent -current on my Lenovo T450 and get a kernel panic > panic: unveil_nipledge_lookup: unexpected pledge bits: 8589934592 this panic is from my diff I recently sent to tech@. it seems it has been put in snapshots. it also means I was wrong in some place, and that I didn't check enough it before sending the diff. I am really sorry about that. The bit I missed is: 8589934592 => 0x2 which is PLEDGE_CHOWN. It means all syscalls using this pledge annotation could generate the panic if the program is used with unveil(2)... bad. > Any idea how to bring up my system again? wait for a new snapshot or rebuild a kernel from source (possibly from another system, as using chown(2) with unveil(2) will generate the panic). Sorry. -- Sebastien Marie
panic: unveil_nipledge_lookup: unexpected pledge bits: 8589934592 after update to recent -current
Hi, I've updated to the recent -current on my Lenovo T450 and get a kernel panic at the following point: starting local daemons: apmd cron xenodm. Thu Aug 2 23:44:13 CEST 2018 -> at this point it is starting X but fall back to panic. This is the output directly after the panic message: Stopped at db_enter+0x12: popq %r11 TIDPIDUIDPRFLAGSPFLAGSCPU COMMAND 52492 30180 0 0x2 0 0 getty 50658 51951 0 0x2 0 2 getty *273210 59371 0 0x2 0 3K getty 213631 9301 0 0x2 0 1 getty db_enter() at db_enter+0x12 panic() at panic+0x120 unveil_check_component(717dcd5addc519e1,ff025bf0de10,800043c4fc88) at unveil_check_component+0x18e vfs_lookup(27dc50307a7045d2) at vfs_lookup+0x296 namei(c6110ecd0e5b1a65) at namei+0x297 dofchownat(5195e973b86aec18,100,800043b25058,10,800043c4fef0,7f7dee28) at dofchownat0x91 syscall(717dcd5add7470f3) at syscall+0x32a Xsyscall(6,10,bf8189078f0,10,3,7f7deee8) at Xsyscall+0x128 end of kernel One more observation: the needed iwm0 firmware is missing on my system. Any idea how to bring up my system again? Kind regards Felix
Re: Floating point exception on boot after using syspatch(8)
On Wed, 1 Aug 2018, Philip Guenther wrote: > This smells like some compatibility issue with the eager-FPU change. One > thought is whether the Xen presents the guest with a correctly reset FPU > state on all CPUs, or if there's some odd state that we're not clearing. > > I made a later commit in that area (sys/arch/amd64/amd64/cpu.c rev 1.124) > so it would be interesting to know if -current shows the same issue or if > the symptoms have improved (or changed at all) there. I applied this diff to my system running on a t2.medium running GENERIC.MP and it fixed the problem I was having post 010_intelfpu errata. Would be great to see this as an Errata. -ME
DVFS for arm64
The diff below adds support for changing the CPU frequency on arm64.
The code is generic and uses the operating points (frequency-voltage
combinaties) given in tables in "operating-points-v2" format. All
that is needed to make this work on a particular board are the drivers
to set the clock frequency and regulator voltage. The code does a
fairly thorough job at making sure that setting to clock frequency and
regulator voltage is actually supported.
I developed the code on an Rockchip RK3399 board. The RK3399 is a
so-called big.LITTLE design with two CPU clusters that support
different speeds. This implementation simply scales the clock
frequency of both clusters based on hw.setperf.
ok?
Index: arch/arm64/arm64/cpu.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
retrieving revision 1.19
diff -u -p -r1.19 cpu.c
--- arch/arm64/arm64/cpu.c 5 Jun 2018 09:45:08 - 1.19
+++ arch/arm64/arm64/cpu.c 2 Aug 2018 19:10:24 -
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
@@ -30,6 +31,7 @@
#include
#include
+#include
#include
#include
@@ -119,6 +121,8 @@ struct cfdriver cpu_cd = {
NULL, "cpu", DV_DULL
};
+void cpu_opp_init(struct cpu_info *, uint32_t);
+
void cpu_flush_bp_noop(void);
void cpu_flush_bp_psci(void);
@@ -222,6 +226,7 @@ cpu_attach(struct device *parent, struct
struct fdt_attach_args *faa = aux;
struct cpu_info *ci;
uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
+ uint32_t opp;
KASSERT(faa->fa_nreg > 0);
@@ -295,6 +300,10 @@ cpu_attach(struct device *parent, struct
}
#endif
+ opp = OF_getpropint(ci->ci_node, "operating-points-v2", 0);
+ if (opp)
+ cpu_opp_init(ci, opp);
+
printf("\n");
}
@@ -472,3 +481,267 @@ cpu_unidle(struct cpu_info *ci)
}
#endif
+
+/*
+ * Dynamic voltage and frequency scaling implementation.
+ */
+
+extern int perflevel;
+
+struct opp {
+ uint64_t opp_hz;
+ uint32_t opp_microvolt;
+};
+
+struct opp_table {
+ LIST_ENTRY(opp_table) ot_list;
+ uint32_t ot_phandle;
+
+ struct opp *ot_opp;
+ u_int ot_nopp;
+ uint64_t ot_opp_hz_min;
+ uint64_t ot_opp_hz_max;
+
+ struct cpu_info *ot_master;
+};
+
+LIST_HEAD(, opp_table) opp_tables = LIST_HEAD_INITIALIZER(opp_tables);
+struct task cpu_opp_task;
+
+void cpu_opp_mountroot(struct device *);
+void cpu_opp_dotask(void *);
+void cpu_opp_setperf(int);
+
+void
+cpu_opp_init(struct cpu_info *ci, uint32_t phandle)
+{
+ struct opp_table *ot;
+ int count, node, child;
+ int i;
+
+ LIST_FOREACH(ot, &opp_tables, ot_list) {
+ if (ot->ot_phandle == phandle) {
+ ci->ci_opp_table = ot;
+ return;
+ }
+ }
+
+ node = OF_getnodebyphandle(phandle);
+ if (node == 0)
+ return;
+
+ if (!OF_is_compatible(node, "operating-points-v2"))
+ return;
+
+ count = 0;
+ for (child = OF_child(node); child != 0; child = OF_peer(child)) {
+ if (OF_getproplen(child, "turbo-mode") == 0)
+ continue;
+ count++;
+ }
+ if (count == 0)
+ return;
+
+ ot = malloc(sizeof(struct opp_table), M_DEVBUF, M_ZERO | M_WAITOK);
+ ot->ot_phandle = phandle;
+ ot->ot_opp = mallocarray(count, sizeof(struct opp),
+ M_DEVBUF, M_ZERO | M_WAITOK);
+ ot->ot_nopp = count;
+
+ count = 0;
+ for (child = OF_child(node); child != 0; child = OF_peer(child)) {
+ if (OF_getproplen(child, "turbo-mode") == 0)
+ continue;
+ ot->ot_opp[count].opp_hz =
+ OF_getpropint64(child, "opp-hz", 0);
+ ot->ot_opp[count].opp_microvolt =
+ OF_getpropint(child, "opp-microvolt", 0);
+ count++;
+ }
+
+ ot->ot_opp_hz_min = ot->ot_opp[0].opp_hz;
+ ot->ot_opp_hz_max = ot->ot_opp[0].opp_hz;
+ for (i = 1; i < ot->ot_nopp; i++) {
+ if (ot->ot_opp[i].opp_hz < ot->ot_opp_hz_min)
+ ot->ot_opp_hz_min = ot->ot_opp[i].opp_hz;
+ if (ot->ot_opp[i].opp_hz > ot->ot_opp_hz_max)
+ ot->ot_opp_hz_max = ot->ot_opp[i].opp_hz;
+ }
+
+ if (OF_getproplen(node, "opp-shared") == 0)
+ ot->ot_master = ci;
+
+ LIST_INSERT_HEAD(&opp_tables, ot, ot_list);
+
+ ci->ci_opp_table = ot;
+ ci->ci_cpu_supply = OF_getpropint(ci->ci_node, "cpu-supply", 0);
+
+ /*
+* Do addional checks at mountroot when all the clocks and
+* regulators are available.
+*/
+ config_mountroot(ci->ci_dev, cpu_opp_mountroot);
+}
+
+void
+cpu_opp_mountroot(struct device *self)
+{
+ struct cpu_info *ci;
+ CPU_INFO_ITERATO
Re: please test: unveil for ifconfig
this one's better
- use the correct unveil pattern, pointed out by brynet@
- argv[0] vs. argv[i], pointed out by Matthew Martin and Mario Campos
diff --git ifconfig.c ifconfig.c
index 9bfb1751aab..20154059394 100644
--- ifconfig.c
+++ ifconfig.c
@@ -676,10 +676,15 @@ main(int argc, char *argv[])
int create = 0;
int Cflag = 0;
int gflag = 0;
+ int found_rulefile = 0;
int i;
/* If no args at all, print all interfaces. */
if (argc < 2) {
+ if (unveil("/", "") == -1)
+ err(1, "unveil");
+ if (unveil(NULL, NULL) == -1)
+ err(1, "unveil");
aflag = 1;
printif(NULL, 0);
return (0);
@@ -721,6 +726,21 @@ main(int argc, char *argv[])
} else if (strlcpy(name, *argv, sizeof(name)) >= IFNAMSIZ)
errx(1, "interface name '%s' too long", *argv);
argc--, argv++;
+
+ for (i = 0; i < argc; i++) {
+ if (strcmp(argv[i], "rulefile") == 0) {
+ found_rulefile = 1;
+ break;
+ }
+ }
+
+ if (!found_rulefile) {
+ if (unveil("/", "") == -1)
+ err(1, "unveil");
+ if (unveil(NULL, NULL) == -1)
+ err(1, "unveil");
+ }
+
if (argc > 0) {
for (afp = rafp = afs; rafp->af_name; rafp++)
if (strcmp(rafp->af_name, *argv) == 0) {
--
I'm not entirely sure you are real.
Re: please test: unveil for ifconfig
Is argv[0] a typo? Shouldn't it be argv[i]?
On Thu, Aug 2, 2018, 12:05 PM Florian Obser wrote:
> I have been told that this is going to fall into snaps soon. If you
> are doing weird (or normal) things with ifconfig, please test.
>
> In particular if you use rulefile.
>
> Thanks!
>
> diff --git ifconfig.c ifconfig.c
> index 9bfb1751aab..873aed5bcc7 100644
> --- ifconfig.c
> +++ ifconfig.c
> @@ -676,10 +676,13 @@ main(int argc, char *argv[])
> int create = 0;
> int Cflag = 0;
> int gflag = 0;
> + int found_rulefile = 0;
> int i;
>
> /* If no args at all, print all interfaces. */
> if (argc < 2) {
> + if (unveil(NULL, NULL) == -1)
> + err(1, "unveil");
> aflag = 1;
> printif(NULL, 0);
> return (0);
> @@ -721,6 +724,18 @@ main(int argc, char *argv[])
> } else if (strlcpy(name, *argv, sizeof(name)) >= IFNAMSIZ)
> errx(1, "interface name '%s' too long", *argv);
> argc--, argv++;
> +
> + for (i = 0; i < argc; i++) {
> + if (strcmp(argv[0], "rulefile") == 0) {
> + found_rulefile = 1;
> + break;
> + }
> + }
> +
> + if (!found_rulefile)
> + if (unveil(NULL, NULL) == -1)
> + err(1, "unveil");
> +
> if (argc > 0) {
> for (afp = rafp = afs; rafp->af_name; rafp++)
> if (strcmp(rafp->af_name, *argv) == 0) {
>
>
> --
> I'm not entirely sure you are real.
>
>
Re: please test: unveil for ifconfig
- Original Message -
> From: "Rob Pierce"
> To: "Bryan Steele"
> Cc: "tech"
> Sent: Thursday, August 2, 2018 1:30:15 PM
> Subject: Re: please test: unveil for ifconfig
> - Original Message -
> > From: "Bryan Steele"
> > To: "tech"
> > Sent: Thursday, August 2, 2018 1:24:48 PM
> > Subject: Re: please test: unveil for ifconfig
> > On Thu, Aug 02, 2018 at 07:04:31PM +0200, Florian Obser wrote:
> > > I have been told that this is going to fall into snaps soon. If you
> > > are doing weird (or normal) things with ifconfig, please test.
> > > In particular if you use rulefile.
> > > Thanks!
> > > diff --git ifconfig.c ifconfig.c
> > > index 9bfb1751aab..873aed5bcc7 100644
> > > --- ifconfig.c
> > > +++ ifconfig.c
> > > @@ -676,10 +676,13 @@ main(int argc, char *argv[])
> > > int create = 0;
> > > int Cflag = 0;
> > > int gflag = 0;
> > > + int found_rulefile = 0;
> > > int i;
> > > /* If no args at all, print all interfaces. */
> > > if (argc < 2) {
> > > + if (unveil(NULL, NULL) == -1)
> > > + err(1, "unveil");
> > > aflag = 1;
> > > printif(NULL, 0);
> > > return (0);
> > > @@ -721,6 +724,18 @@ main(int argc, char *argv[])
> > > } else if (strlcpy(name, *argv, sizeof(name)) >= IFNAMSIZ)
> > > errx(1, "interface name '%s' too long", *argv);
> > > argc--, argv++;
> > > +
> > > + for (i = 0; i < argc; i++) {
> > > + if (strcmp(argv[0], "rulefile") == 0) {
> > > + found_rulefile = 1;
> > > + break;
> > > + }
> > > + }
> > > +
> > > + if (!found_rulefile)
> > > + if (unveil(NULL, NULL) == -1)
> > > + err(1, "unveil");
> > > +
> > > if (argc > 0) {
> > > for (afp = rafp = afs; rafp->af_name; rafp++)
> > > if (strcmp(rafp->af_name, *argv) == 0) {
> > Are these the only two unveil(2) calls in ifconfig(8)? If not mistaken,
> > unless you unveil something before the call to disable unveil, it never
> > actually restricts access to the filesystem, instead you need:
> > if (unveil("/", "") == -1)
> > err(1, "unveil");
> > if (unveil(NULL, NULL) == -1)
> > err(1, "unveil");
> > -Bryan.
> Ah, yes. unveil(NULL, NULL) does not activate unveil. A recent man page update
> captures this a little better.
> I will test again. with your addition.
> Rob
ifstated regress passes with modified unveil calls.
They are pretty basic use cases though.
Rob
Re: tweaks to namei.9
On Thu, Aug 02, 2018 at 07:41:01PM +0200, Ingo Schwarze wrote: > Hi Jason, > > Jason McIntyre wrote on Thu, Aug 02, 2018 at 05:41:22PM +0100: > > > ok by me. > > Thanks for checking, committed. > > > you might get away with removing the last sentence of BUGS > > now, since HISTORY almost provides the same. > > Maybe, but i don't know enough about ufs and vfs to judge whether > it really says the same or hides some additional, useful information > behind a clumsy wording. > > So i'll leave cleaning that up to someone more knowlegeable, if it > needs cleanup. > > > while we're chopping, i'd prefer to see the one line section > > that is CODE REFERENCES integrated into DESCRIPTION. > > Maybe, but it is kind of conventional in section 9 manual pages: > >$ grep CODE * > autoconf.9:.Sh CODE REFERENCES > buffercache.9:.Sh CODE REFERENCES > disk.9:.Sh CODE REFERENCES > extent.9:.Sh CODE REFERENCES > file.9:.Sh CODE REFERENCES > hardclock.9:.Sh CODE REFERENCES > intro.9:.Sh CODE REFERENCES > ktrace.9:.Sh CODE REFERENCES > mbuf.9:.Sh CODE REFERENCES > mbuf_tags.9:.Sh CODE REFERENCES > microtime.9:.Sh CODE REFERENCES > namei.9:.Sh CODE REFERENCES > pool.9:.Sh CODE REFERENCES > pool_cache_init.9:.Sh CODE REFERENCES > printf.9:.Sh CODE REFERENCES > psignal.9:.Sh CODE REFERENCES > rasops.9:.Sh CODE REFERENCES > rssadapt.9:.Sh CODE REFERENCES > syscall.9:.Sh CODE REFERENCES > tc_init.9:.Sh CODE REFERENCES > tfind.9:.Sh CODE REFERENCES > timeout.9:.Sh CODE REFERENCES > tsleep.9:.Sh CODE REFERENCES > tvtohz.9:.Sh CODE REFERENCES > vfs_cache.9:.Sh CODE REFERENCES > vinvalbuf.9:.Sh PSEUDOCODE > vnsubr.9:.Sh CODE REFERENCES > wdog_register.9:.Sh CODE REFERENCES > > NetBSD has it, too: > > > https://man.openbsd.org/?query=Sh%3DCODE\+REFERENCES&apropos=1&manpath=NetBSD-7.1 > > On the one hand, i agree that very short sections aren't very pretty. > On the other hand, the purpose of CODE REFERENCES is sufficiently > different from DESCRIPTION, and its use sufficiently widespread, > that it may help kernel hackers to quickly locate this information. > > I'm not sure in this respect. > > Yours, > Ingo these sections are generally from imported netbsd pages. there's enough that we never killed them (like LIBRARY) but never officially supported them either. i think my request to kill it was unfair, since it'd be better done consistently rather than picking on one page. jmc
Re: tweaks to namei.9
Hi Jason, Jason McIntyre wrote on Thu, Aug 02, 2018 at 05:41:22PM +0100: > ok by me. Thanks for checking, committed. > you might get away with removing the last sentence of BUGS > now, since HISTORY almost provides the same. Maybe, but i don't know enough about ufs and vfs to judge whether it really says the same or hides some additional, useful information behind a clumsy wording. So i'll leave cleaning that up to someone more knowlegeable, if it needs cleanup. > while we're chopping, i'd prefer to see the one line section > that is CODE REFERENCES integrated into DESCRIPTION. Maybe, but it is kind of conventional in section 9 manual pages: $ grep CODE * autoconf.9:.Sh CODE REFERENCES buffercache.9:.Sh CODE REFERENCES disk.9:.Sh CODE REFERENCES extent.9:.Sh CODE REFERENCES file.9:.Sh CODE REFERENCES hardclock.9:.Sh CODE REFERENCES intro.9:.Sh CODE REFERENCES ktrace.9:.Sh CODE REFERENCES mbuf.9:.Sh CODE REFERENCES mbuf_tags.9:.Sh CODE REFERENCES microtime.9:.Sh CODE REFERENCES namei.9:.Sh CODE REFERENCES pool.9:.Sh CODE REFERENCES pool_cache_init.9:.Sh CODE REFERENCES printf.9:.Sh CODE REFERENCES psignal.9:.Sh CODE REFERENCES rasops.9:.Sh CODE REFERENCES rssadapt.9:.Sh CODE REFERENCES syscall.9:.Sh CODE REFERENCES tc_init.9:.Sh CODE REFERENCES tfind.9:.Sh CODE REFERENCES timeout.9:.Sh CODE REFERENCES tsleep.9:.Sh CODE REFERENCES tvtohz.9:.Sh CODE REFERENCES vfs_cache.9:.Sh CODE REFERENCES vinvalbuf.9:.Sh PSEUDOCODE vnsubr.9:.Sh CODE REFERENCES wdog_register.9:.Sh CODE REFERENCES NetBSD has it, too: https://man.openbsd.org/?query=Sh%3DCODE\+REFERENCES&apropos=1&manpath=NetBSD-7.1 On the one hand, i agree that very short sections aren't very pretty. On the other hand, the purpose of CODE REFERENCES is sufficiently different from DESCRIPTION, and its use sufficiently widespread, that it may help kernel hackers to quickly locate this information. I'm not sure in this respect. Yours, Ingo
Re: please test: unveil for ifconfig
- Original Message -
> From: "Bryan Steele"
> To: "tech"
> Sent: Thursday, August 2, 2018 1:24:48 PM
> Subject: Re: please test: unveil for ifconfig
> On Thu, Aug 02, 2018 at 07:04:31PM +0200, Florian Obser wrote:
> > I have been told that this is going to fall into snaps soon. If you
> > are doing weird (or normal) things with ifconfig, please test.
> > In particular if you use rulefile.
> > Thanks!
> > diff --git ifconfig.c ifconfig.c
> > index 9bfb1751aab..873aed5bcc7 100644
> > --- ifconfig.c
> > +++ ifconfig.c
> > @@ -676,10 +676,13 @@ main(int argc, char *argv[])
> > int create = 0;
> > int Cflag = 0;
> > int gflag = 0;
> > + int found_rulefile = 0;
> > int i;
> > /* If no args at all, print all interfaces. */
> > if (argc < 2) {
> > + if (unveil(NULL, NULL) == -1)
> > + err(1, "unveil");
> > aflag = 1;
> > printif(NULL, 0);
> > return (0);
> > @@ -721,6 +724,18 @@ main(int argc, char *argv[])
> > } else if (strlcpy(name, *argv, sizeof(name)) >= IFNAMSIZ)
> > errx(1, "interface name '%s' too long", *argv);
> > argc--, argv++;
> > +
> > + for (i = 0; i < argc; i++) {
> > + if (strcmp(argv[0], "rulefile") == 0) {
> > + found_rulefile = 1;
> > + break;
> > + }
> > + }
> > +
> > + if (!found_rulefile)
> > + if (unveil(NULL, NULL) == -1)
> > + err(1, "unveil");
> > +
> > if (argc > 0) {
> > for (afp = rafp = afs; rafp->af_name; rafp++)
> > if (strcmp(rafp->af_name, *argv) == 0) {
> Are these the only two unveil(2) calls in ifconfig(8)? If not mistaken,
> unless you unveil something before the call to disable unveil, it never
> actually restricts access to the filesystem, instead you need:
> if (unveil("/", "") == -1)
> err(1, "unveil");
> if (unveil(NULL, NULL) == -1)
> err(1, "unveil");
> -Bryan.
Ah, yes. unveil(NULL, NULL) does not activate unveil. A recent man page update
captures this a little better.
I will test again. with your addition.
Rob
Re: please test: unveil for ifconfig
On Thu, Aug 02, 2018 at 07:04:31PM +0200, Florian Obser wrote:
> I have been told that this is going to fall into snaps soon. If you
> are doing weird (or normal) things with ifconfig, please test.
I am running a kernel with some unveil error condition debugging, and with that
I proceeded to test the ifstated regression test (which exercises some basic
ifconfig operations). Everything worked as expected, and no strange unveil
kernel messages in my logs.
Rob
> In particular if you use rulefile.
>
> Thanks!
>
> diff --git ifconfig.c ifconfig.c
> index 9bfb1751aab..873aed5bcc7 100644
> --- ifconfig.c
> +++ ifconfig.c
> @@ -676,10 +676,13 @@ main(int argc, char *argv[])
> int create = 0;
> int Cflag = 0;
> int gflag = 0;
> + int found_rulefile = 0;
> int i;
>
> /* If no args at all, print all interfaces. */
> if (argc < 2) {
> + if (unveil(NULL, NULL) == -1)
> + err(1, "unveil");
> aflag = 1;
> printif(NULL, 0);
> return (0);
> @@ -721,6 +724,18 @@ main(int argc, char *argv[])
> } else if (strlcpy(name, *argv, sizeof(name)) >= IFNAMSIZ)
> errx(1, "interface name '%s' too long", *argv);
> argc--, argv++;
> +
> + for (i = 0; i < argc; i++) {
> + if (strcmp(argv[0], "rulefile") == 0) {
> + found_rulefile = 1;
> + break;
> + }
> + }
> +
> + if (!found_rulefile)
> + if (unveil(NULL, NULL) == -1)
> + err(1, "unveil");
> +
> if (argc > 0) {
> for (afp = rafp = afs; rafp->af_name; rafp++)
> if (strcmp(rafp->af_name, *argv) == 0) {
>
>
> --
> I'm not entirely sure you are real.
>
Re: please test: unveil for ifconfig
On Thu, Aug 02, 2018 at 07:04:31PM +0200, Florian Obser wrote:
> I have been told that this is going to fall into snaps soon. If you
> are doing weird (or normal) things with ifconfig, please test.
>
> In particular if you use rulefile.
>
> Thanks!
>
> diff --git ifconfig.c ifconfig.c
> index 9bfb1751aab..873aed5bcc7 100644
> --- ifconfig.c
> +++ ifconfig.c
> @@ -676,10 +676,13 @@ main(int argc, char *argv[])
> int create = 0;
> int Cflag = 0;
> int gflag = 0;
> + int found_rulefile = 0;
> int i;
>
> /* If no args at all, print all interfaces. */
> if (argc < 2) {
> + if (unveil(NULL, NULL) == -1)
> + err(1, "unveil");
> aflag = 1;
> printif(NULL, 0);
> return (0);
> @@ -721,6 +724,18 @@ main(int argc, char *argv[])
> } else if (strlcpy(name, *argv, sizeof(name)) >= IFNAMSIZ)
> errx(1, "interface name '%s' too long", *argv);
> argc--, argv++;
> +
> + for (i = 0; i < argc; i++) {
> + if (strcmp(argv[0], "rulefile") == 0) {
> + found_rulefile = 1;
> + break;
> + }
> + }
> +
> + if (!found_rulefile)
> + if (unveil(NULL, NULL) == -1)
> + err(1, "unveil");
> +
> if (argc > 0) {
> for (afp = rafp = afs; rafp->af_name; rafp++)
> if (strcmp(rafp->af_name, *argv) == 0) {
>
Are these the only two unveil(2) calls in ifconfig(8)? If not mistaken,
unless you unveil something before the call to disable unveil, it never
actually restricts access to the filesystem, instead you need:
if (unveil("/", "") == -1)
err(1, "unveil");
if (unveil(NULL, NULL) == -1)
err(1, "unveil");
-Bryan.
please test: unveil for ifconfig
I have been told that this is going to fall into snaps soon. If you
are doing weird (or normal) things with ifconfig, please test.
In particular if you use rulefile.
Thanks!
diff --git ifconfig.c ifconfig.c
index 9bfb1751aab..873aed5bcc7 100644
--- ifconfig.c
+++ ifconfig.c
@@ -676,10 +676,13 @@ main(int argc, char *argv[])
int create = 0;
int Cflag = 0;
int gflag = 0;
+ int found_rulefile = 0;
int i;
/* If no args at all, print all interfaces. */
if (argc < 2) {
+ if (unveil(NULL, NULL) == -1)
+ err(1, "unveil");
aflag = 1;
printif(NULL, 0);
return (0);
@@ -721,6 +724,18 @@ main(int argc, char *argv[])
} else if (strlcpy(name, *argv, sizeof(name)) >= IFNAMSIZ)
errx(1, "interface name '%s' too long", *argv);
argc--, argv++;
+
+ for (i = 0; i < argc; i++) {
+ if (strcmp(argv[0], "rulefile") == 0) {
+ found_rulefile = 1;
+ break;
+ }
+ }
+
+ if (!found_rulefile)
+ if (unveil(NULL, NULL) == -1)
+ err(1, "unveil");
+
if (argc > 0) {
for (afp = rafp = afs; rafp->af_name; rafp++)
if (strcmp(rafp->af_name, *argv) == 0) {
--
I'm not entirely sure you are real.
Re: tweaks to namei.9
On Thu, Aug 02, 2018 at 05:16:18PM +0200, Ingo Schwarze wrote:
> Hi,
>
> the first paragraph of the DESCRIPTION is all fluff.
> Let's just wipe it away completely, we always want
> the DESCRIPTION to be concise and get to the point.
>
> Instead, provide some real HISTORY.
>
> DESCRIPTION: minus five lines, same amount of information.
> HISTORY: plus three lines, but now containing some real data.
>
> OK?
> Ingo
>
ok by me. you might get away with removing the last sentence of BUGS
now, since HISTORY almost provides the same. while we're chopping, i'd
prefer to see the one line section that is CODE REFERENCES integrated
into DESCRIPTION.
jmc
>
> Index: namei.9
> ===
> RCS file: /cvs/src/share/man/man9/namei.9,v
> retrieving revision 1.18
> diff -u -r1.18 namei.9
> --- namei.9 23 Nov 2015 17:53:57 - 1.18
> +++ namei.9 2 Aug 2018 15:07:03 -
> @@ -57,20 +57,9 @@
> .Sh DESCRIPTION
> The
> .Fn namei
> -function is used to convert pathnames to file system vnodes.
> -The
> -name of the function is actually a contraction of the words
> -.Em name
> -and
> -.Em inode
> -for name-to-inode conversion, in the days before the
> -.Xr vfs 9
> -interface was implemented.
> -.Pp
> -The arguments passed to the functions are encapsulated in the
> -.Em nameidata
> -structure.
> -It has the following structure:
> +function converts a pathname to a
> +.Xr vnode 9 .
> +It uses the following structure:
> .Bd -literal
> struct nameidata {
> /*
> @@ -309,6 +298,16 @@
> .Xr vfs 9 ,
> .Xr vnode 9 ,
> .Xr VOP_LOOKUP 9
> +.Sh HISTORY
> +The
> +.Fn namei
> +function first appeared in
> +.At v4 .
> +Its name is an abbreviation for the name-to-inode conversion
> +which it performed before the appearance of
> +.Xr vfs 9
> +in
> +.Bx 4.3 Reno .
> .Sh BUGS
> It is unfortunate that much of the
> .Nm
>
Re: Unlock pipe(2) and pipe2(2)
On 01/08/18(Wed) 01:53, Mark Kettenis wrote:
> > Date: Tue, 31 Jul 2018 14:55:45 -0300
> > From: Martin Pieuchot
> >
> > On 26/06/18(Tue) 12:31, Martin Pieuchot wrote:
> > > These syscalls do two operations: they allocate FDs and some buffers.
> > > Thanks to the work done for sockets the file-related bits are now
> > > mp-safe, so we can push the KERNEL_LOCK() down.
> > >
> > > Diff below adds some KERNEL_LOCK/UNLOCK() dances around km_alloc(9) and
> > > km_free(9). It also makes some counters use atomic operations.
> > >
> > > My goals for this diff are to prepare the terrain to unlock read(2) &
> > > write(2) for pipes and push the KERNEL_LOCK() at UVM borders, to
> > > hopefully motivate other hackers to push further down!
> >
> > The only objection that I received to this diff is that `fd_ofilesflags'
> > wasn't always protected. Which meant that fdexpand() couldn't be taken
> > out of the KERNEL_LOCK(). This has been fixed since then. So any other
> > comment or ok?
> >
> [...]
> > @@ -443,14 +445,13 @@ pipe_write(struct file *fp, off_t *poff,
> > * If it is advantageous to resize the pipe buffer, do
> > * so.
> > */
> > - if ((uio->uio_resid > PIPE_SIZE) &&
> > - (nbigpipe < LIMITBIGPIPES) &&
> > + if ((uio->uio_resid > PIPE_SIZE) && (nbigpipe < LIMITBIGPIPES) &&
> > (wpipe->pipe_buffer.size <= PIPE_SIZE) &&
> > (wpipe->pipe_buffer.cnt == 0)) {
> >
> > if ((error = pipelock(wpipe)) == 0) {
> > if (pipespace(wpipe, BIG_PIPE_SIZE) == 0)
> > - nbigpipe++;
> > + atomic_inc_int(&nbigpipe);
>
> There is a TOCTTOU issue here. Threads can run through here in
> parallel and nbigpipe can become larger than LIMITBIGPIPES. You need
> to use atomic_inc_int_nv() and back off if you pushed it over the
> limit.
Thanks, updated diff below, how does it looks like?
Index: kern/sys_pipe.c
===
RCS file: /cvs/src/sys/kern/sys_pipe.c,v
retrieving revision 1.82
diff -u -p -r1.82 sys_pipe.c
--- kern/sys_pipe.c 10 Jul 2018 08:58:50 - 1.82
+++ kern/sys_pipe.c 2 Aug 2018 16:02:08 -
@@ -91,8 +91,8 @@ struct filterops pipe_wfiltops =
* Limit the number of "big" pipes
*/
#define LIMITBIGPIPES 32
-int nbigpipe;
-static int amountpipekva;
+unsigned int nbigpipe;
+static unsigned int amountpipekva;
struct pool pipe_pool;
@@ -214,7 +214,9 @@ pipespace(struct pipe *cpipe, u_int size
{
caddr_t buffer;
+ KERNEL_LOCK();
buffer = km_alloc(size, &kv_any, &kp_pageable, &kd_waitok);
+ KERNEL_UNLOCK();
if (buffer == NULL) {
return (ENOMEM);
}
@@ -227,7 +229,7 @@ pipespace(struct pipe *cpipe, u_int size
cpipe->pipe_buffer.out = 0;
cpipe->pipe_buffer.cnt = 0;
- amountpipekva += cpipe->pipe_buffer.size;
+ atomic_add_int(&amountpipekva, cpipe->pipe_buffer.size);
return (0);
}
@@ -444,15 +446,17 @@ pipe_write(struct file *fp, off_t *poff,
* so.
*/
if ((uio->uio_resid > PIPE_SIZE) &&
- (nbigpipe < LIMITBIGPIPES) &&
(wpipe->pipe_buffer.size <= PIPE_SIZE) &&
(wpipe->pipe_buffer.cnt == 0)) {
+ unsigned int npipe;
- if ((error = pipelock(wpipe)) == 0) {
- if (pipespace(wpipe, BIG_PIPE_SIZE) == 0)
- nbigpipe++;
+ npipe = atomic_inc_int_nv(&nbigpipe);
+ if ((npipe < LIMITBIGPIPES) && (error = pipelock(wpipe)) == 0) {
+ if (pipespace(wpipe, BIG_PIPE_SIZE) != 0)
+ atomic_dec_int(&nbigpipe);
pipeunlock(wpipe);
- }
+ } else
+ atomic_dec_int(&nbigpipe);
}
/*
@@ -759,12 +763,15 @@ pipe_close(struct file *fp, struct proc
void
pipe_free_kmem(struct pipe *cpipe)
{
+ u_int size = cpipe->pipe_buffer.size;
+
if (cpipe->pipe_buffer.buffer != NULL) {
- if (cpipe->pipe_buffer.size > PIPE_SIZE)
- --nbigpipe;
- amountpipekva -= cpipe->pipe_buffer.size;
- km_free(cpipe->pipe_buffer.buffer, cpipe->pipe_buffer.size,
- &kv_any, &kp_pageable);
+ if (size > PIPE_SIZE)
+ atomic_dec_int(&nbigpipe);
+ KERNEL_LOCK();
+ km_free(cpipe->pipe_buffer.buffer, size, &kv_any, &kp_pageable);
+ KERNEL_UNLOCK();
+ atomic_sub_int(&amountpipekva, size);
cpipe->pipe_buffer.buffer = NULL;
}
}
@@ -777,7 +784,6 @@ pipeclose(struct pipe *cpipe)
{
struct pipe *ppipe;
if (cpipe) {
-
pipeselwakeup(cpipe);
/*
Index: kern/syscalls.master
=
Re: correct nd6_timer_next accounting
Note that the neighbor entry is in state S (stale). Whatever that means... On Thu, Aug 02, 2018 at 04:44:57PM +0100, Stuart Henderson wrote: > On 2018/08/01 23:18, Florian Obser wrote: > > I'm chasing a bug in IPv6 where ndp reports an entry as (incomplete) > > but when you try to reach that target no neighbor solicitation is > > send. > > Not sure if it's related or not but I've seen weird v6 behaviour on > my workstation for a while which I've been trying to figure out in order > to get enough information together to make a useful report. But since you > have problems in a similar area I'll mention it now before figuring any > more out in case it's relevant. > > Trying to connect to any host (directly connected or remote) fails with > EHOSTUNREACH, but the route is there, ndp is there, PF is not in the way > (I see the same with pfctl -d). No difference with the nd6_timer_next diff. > > > $ cat /etc/mygate > 82.68.199.142 > 2a02:8011:7003:1::1 > $ ifconfig vlan2 > vlan2: flags=8843 mtu 1500 > lladdr f8:b1:56:ac:32:76 > index 6 priority 0 llprio 3 > encap: vnetid 2 parent em0 > groups: vlan egress > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > status: active > inet 82.68.199.130 netmask 0xfff0 broadcast 82.68.199.143 > inet6 fe80::78d8:e34b:df38:885e%vlan2 prefixlen 64 scopeid 0x6 > inet6 2a02:8011:7003:1:fab1:56ff:feac:3276 prefixlen 64 > $ ifconfig -A|grep inet6 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 fe80::78d8:e34b:df38:885e%vlan2 prefixlen 64 scopeid 0x6 > inet6 2a02:8011:7003:1:fab1:56ff:feac:3276 prefixlen 64 > $ netstat -rnfinet6 > Routing tables > > Internet6: > DestinationGatewayFlags > Refs Use Mtu Prio Iface > default2a02:8011:7003:1::1UGS > 1 2560 - 8 vlan2 > ::/96 ::1UGRS > 00 32768 8 lo0 > ::1::1UHhl > 10 22 32768 1 lo0 > :::0.0.0.0/96 ::1UGRS > 00 32768 8 lo0 > 2002::/24 ::1UGRS > 00 32768 8 lo0 > 2002:7f00::/24 ::1UGRS > 00 32768 8 lo0 > 2002:e000::/20 ::1UGRS > 00 32768 8 lo0 > 2002:ff00::/24 ::1UGRS > 00 32768 8 lo0 > 2a02:8011:7003:1::/64 2a02:8011:7003:1:fab1:56ff:feac:3276 UCn > 20 - 4 vlan2 > 2a02:8011:7003:1::100:0d:b9:41:7e:48 UHLch > 1 13 - 3 vlan2 > 2a02:8011:7003:1:20d:93ff:fe63:da5a 00:0d:b9:14:30:ec UHLc > 1 12 - 3 vlan2 > 2a02:8011:7003:1:fab1:56ff:feac:3276 f8:b1:56:ac:32:76 UHLl > 1 36 - 1 vlan2 > fe80::/10 ::1UGRS > 01 32768 8 lo0 > fec0::/10 ::1UGRS > 00 32768 8 lo0 > fe80::1%lo0fe80::1%lo0UHl > 00 32768 1 lo0 > fe80::%vlan2/64fe80::78d8:e34b:df38:885e%vlan2 UCn > 00 - 4 vlan2 > fe80::78d8:e34b:df38:885e%vlan2f8:b1:56:ac:32:76 UHLl > 00 - 1 vlan2 > ff01::/16 ::1UGRS > 01 32768 8 lo0 > ff01::%lo0/32 ::1Um > 01 32768 4 lo0 > ff01::%vlan2/32fe80::78d8:e34b:df38:885e%vlan2 Um > 01 - 4 vlan2 > ff02::/16 ::1UGRS > 01 32768 8 lo0 > ff02::%lo0/32 ::1Um > 01 32768 4 lo0 > ff02::%vlan2/32fe80::78d8:e34b:df38:885e%vlan2 Um > 01 - 4 vlan2 > $ ndp -na > Neighbor Linklayer Address Netif ExpireS > Flags > 2a02:8011:7003:1::1 00:0d:b9:41:7e:48 vlan2 23h54m6s S R > 2a02:8011:7003:1:20d:93ff:fe63:da5a 00:0d:b9:14:30:ec vlan2 23h54m9s S > 2a02:8011:7003:1:fab1:56ff:feac:3276 f8:b1:56:ac:32:76 vlan2 permanent R l > fe80::78d8:e34b:df38:885e%vlan2 f8:b1:56:ac:32:76 vlan2 permanent R l > $ ping6 mala > PING mala.spacehopper.org (2a02:8011:7003:1:20d:93ff:fe63:da5a): 56 data bytes > ping6: sendmsg: No route to host > ping: wrote mala.spacehopper.org 64 chars, ret=-1 > ^C >
Re: correct nd6_timer_next accounting
On 2018/08/01 23:18, Florian Obser wrote: > I'm chasing a bug in IPv6 where ndp reports an entry as (incomplete) > but when you try to reach that target no neighbor solicitation is > send. Not sure if it's related or not but I've seen weird v6 behaviour on my workstation for a while which I've been trying to figure out in order to get enough information together to make a useful report. But since you have problems in a similar area I'll mention it now before figuring any more out in case it's relevant. Trying to connect to any host (directly connected or remote) fails with EHOSTUNREACH, but the route is there, ndp is there, PF is not in the way (I see the same with pfctl -d). No difference with the nd6_timer_next diff. $ cat /etc/mygate 82.68.199.142 2a02:8011:7003:1::1 $ ifconfig vlan2 vlan2: flags=8843 mtu 1500 lladdr f8:b1:56:ac:32:76 index 6 priority 0 llprio 3 encap: vnetid 2 parent em0 groups: vlan egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 82.68.199.130 netmask 0xfff0 broadcast 82.68.199.143 inet6 fe80::78d8:e34b:df38:885e%vlan2 prefixlen 64 scopeid 0x6 inet6 2a02:8011:7003:1:fab1:56ff:feac:3276 prefixlen 64 $ ifconfig -A|grep inet6 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 fe80::78d8:e34b:df38:885e%vlan2 prefixlen 64 scopeid 0x6 inet6 2a02:8011:7003:1:fab1:56ff:feac:3276 prefixlen 64 $ netstat -rnfinet6 Routing tables Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface default2a02:8011:7003:1::1UGS1 2560 - 8 vlan2 ::/96 ::1UGRS 0 0 32768 8 lo0 ::1::1UHhl 10 22 32768 1 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 2a02:8011:7003:1::/64 2a02:8011:7003:1:fab1:56ff:feac:3276 UCn 20 - 4 vlan2 2a02:8011:7003:1::100:0d:b9:41:7e:48 UHLch 1 13 - 3 vlan2 2a02:8011:7003:1:20d:93ff:fe63:da5a 00:0d:b9:14:30:ec UHLc 1 12 - 3 vlan2 2a02:8011:7003:1:fab1:56ff:feac:3276 f8:b1:56:ac:32:76 UHLl 1 36 - 1 vlan2 fe80::/10 ::1UGRS 0 1 32768 8 lo0 fec0::/10 ::1UGRS 0 0 32768 8 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 fe80::%vlan2/64fe80::78d8:e34b:df38:885e%vlan2 UCn0 0 - 4 vlan2 fe80::78d8:e34b:df38:885e%vlan2f8:b1:56:ac:32:76 UHLl 0 0 - 1 vlan2 ff01::/16 ::1UGRS 0 1 32768 8 lo0 ff01::%lo0/32 ::1Um 0 1 32768 4 lo0 ff01::%vlan2/32fe80::78d8:e34b:df38:885e%vlan2 Um 0 1 - 4 vlan2 ff02::/16 ::1UGRS 0 1 32768 8 lo0 ff02::%lo0/32 ::1Um 0 1 32768 4 lo0 ff02::%vlan2/32fe80::78d8:e34b:df38:885e%vlan2 Um 0 1 - 4 vlan2 $ ndp -na Neighbor Linklayer Address Netif ExpireS Flags 2a02:8011:7003:1::1 00:0d:b9:41:7e:48 vlan2 23h54m6s S R 2a02:8011:7003:1:20d:93ff:fe63:da5a 00:0d:b9:14:30:ec vlan2 23h54m9s S 2a02:8011:7003:1:fab1:56ff:feac:3276 f8:b1:56:ac:32:76 vlan2 permanent R l fe80::78d8:e34b:df38:885e%vlan2 f8:b1:56:ac:32:76 vlan2 permanent R l $ ping6 mala PING mala.spacehopper.org (2a02:8011:7003:1:20d:93ff:fe63:da5a): 56 data bytes ping6: sendmsg: No route to host ping: wrote mala.spacehopper.org 64 chars, ret=-1 ^C --- mala.spacehopper.org ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss $ telnet -6 mala 22 Trying 2a02:8011:7003:1:20d:93ff:fe63:da5a... telnet: connect to address 2a02:8011:7003:1:20d:93ff:fe63:da5a: No route to host $ route -n get -inet6 mala route to: 2a02:8011:7003:1:20d:93
Re: tweaks to namei.9
Hi,
the first paragraph of the DESCRIPTION is all fluff.
Let's just wipe it away completely, we always want
the DESCRIPTION to be concise and get to the point.
Instead, provide some real HISTORY.
DESCRIPTION: minus five lines, same amount of information.
HISTORY: plus three lines, but now containing some real data.
OK?
Ingo
Index: namei.9
===
RCS file: /cvs/src/share/man/man9/namei.9,v
retrieving revision 1.18
diff -u -r1.18 namei.9
--- namei.9 23 Nov 2015 17:53:57 - 1.18
+++ namei.9 2 Aug 2018 15:07:03 -
@@ -57,20 +57,9 @@
.Sh DESCRIPTION
The
.Fn namei
-function is used to convert pathnames to file system vnodes.
-The
-name of the function is actually a contraction of the words
-.Em name
-and
-.Em inode
-for name-to-inode conversion, in the days before the
-.Xr vfs 9
-interface was implemented.
-.Pp
-The arguments passed to the functions are encapsulated in the
-.Em nameidata
-structure.
-It has the following structure:
+function converts a pathname to a
+.Xr vnode 9 .
+It uses the following structure:
.Bd -literal
struct nameidata {
/*
@@ -309,6 +298,16 @@
.Xr vfs 9 ,
.Xr vnode 9 ,
.Xr VOP_LOOKUP 9
+.Sh HISTORY
+The
+.Fn namei
+function first appeared in
+.At v4 .
+Its name is an abbreviation for the name-to-inode conversion
+which it performed before the appearance of
+.Xr vfs 9
+in
+.Bx 4.3 Reno .
.Sh BUGS
It is unfortunate that much of the
.Nm
Re: bgpd: fix rde_filter_equal
On 2018/08/02 14:32, Claudio Jeker wrote:
> Currently if anyone uses the example bgpd filter rules all neighbors will
> do a full softreconfiguration even when no rule have been changed. This is
> because the skip logic was wrongly implemented and so rules like 'pass to
> ebgp' will result in non equality of the ruleset even though it is fine.
>
> By introducing a rde_filter_skip_rule() function the skip logic goes into
> a single place and so less errors should happen.
>
> OK?
It reads well, and is much clearer split off to a function this way.
Testing while watching bgpd -dv output it detects filter changes when
I expect them and does the right thing. OK sthen@
> --
> :wq Claudio
>
> PS: this may speed up config reloads in some cases a fair amount
>
> Index: rde_filter.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 rde_filter.c
> --- rde_filter.c 22 Jul 2018 16:59:08 - 1.97
> +++ rde_filter.c 2 Aug 2018 12:22:10 -
> @@ -549,6 +549,37 @@ rde_prefix_match(struct filter_prefix *f
> return (0); /* should not be reached */
> }
>
> +/* return true when the rule f can never match for this peer */
> +static int
> +rde_filter_skip_rule(struct rde_peer *peer, struct filter_rule *f)
> +{
> + /* if any of the two is unset then rule can't be skipped */
> + if (peer == NULL || f == NULL)
> + return (0);
> +
> + if (f->peer.groupid != 0 &&
> + f->peer.groupid != peer->conf.groupid)
> + return (1);
> +
> + if (f->peer.peerid != 0 &&
> + f->peer.peerid != peer->conf.id)
> + return (1);
> +
> + if (f->peer.remote_as != 0 &&
> + f->peer.remote_as != peer->conf.remote_as)
> + return (1);
> +
> + if (f->peer.ebgp != 0 &&
> + f->peer.ebgp != peer->conf.ebgp)
> + return (1);
> +
> + if (f->peer.ibgp != 0 &&
> + f->peer.ibgp != !peer->conf.ebgp)
> + return (1);
> +
> + return (0);
> +}
> +
> int
> rde_filter_equal(struct filter_head *a, struct filter_head *b,
> struct rde_peer *peer, struct prefixset_head *psh)
> @@ -561,43 +592,12 @@ rde_filter_equal(struct filter_head *a,
>
> while (fa != NULL || fb != NULL) {
> /* skip all rules with wrong peer */
> - if (peer != NULL && fa != NULL && fa->peer.groupid != 0 &&
> - fa->peer.groupid != peer->conf.groupid) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> - if (peer != NULL && fa != NULL && fa->peer.peerid != 0 &&
> - fa->peer.peerid != peer->conf.id) {
> + if (rde_filter_skip_rule(peer, fa)) {
> fa = TAILQ_NEXT(fa, entry);
> continue;
> }
> -
> - if (peer != NULL && fb != NULL && fb->peer.groupid != 0 &&
> - fb->peer.groupid != peer->conf.groupid) {
> + if (rde_filter_skip_rule(peer, fb)) {
> fb = TAILQ_NEXT(fb, entry);
> - continue;
> - }
> - if (peer != NULL && fb != NULL && fb->peer.peerid != 0 &&
> - fb->peer.peerid != peer->conf.id) {
> - fb = TAILQ_NEXT(fb, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.remote_as != 0 &&
> - fa->peer.remote_as != peer->conf.remote_as) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.ebgp != 0 &&
> - fa->peer.ebgp != peer->conf.ebgp) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.ibgp != 0 &&
> - fa->peer.ibgp != !peer->conf.ebgp) {
> - fa = TAILQ_NEXT(fa, entry);
> continue;
> }
>
>
Re: tweaks to namei.9
Rob Pierce(r...@2keys.ca) on 2018.08.02 14:26:54 +:
> On Thu, Aug 02, 2018 at 03:15:14PM +0100, Jason McIntyre wrote:
> > On Thu, Aug 02, 2018 at 01:58:38PM +, Rob Pierce wrote:
> > > A little less wordy when introducing the namieidata structure.
> > >
> > > Ok?
> > >
> > > Index: namei.9
> > > ===
> > > RCS file: /cvs/src/share/man/man9/namei.9,v
> > > retrieving revision 1.18
> > > diff -u -p -r1.18 namei.9
> > > --- namei.9 23 Nov 2015 17:53:57 - 1.18
> > > +++ namei.9 2 Aug 2018 13:51:43 -
> > > @@ -67,10 +67,9 @@ for name-to-inode conversion, in the day
> > > .Xr vfs 9
> > > interface was implemented.
> > > .Pp
> > > -The arguments passed to the functions are encapsulated in the
> > > +Arguments passed to these functions are encapsulated in the following
> > > .Em nameidata
> > > -structure.
> > > -It has the following structure:
> > > +structure:
> > > .Bd -literal
> > > struct nameidata {
> > > /*
> > >
> >
> > hi.
> >
> > i'm not sure it's a big win - it's just another way of saying the same
> > thing. but now it can be interpreted to mean that there are more than one
> > type of namei structure.
> >
> > the use of "structure" twice isn;t ideal though, i agree.
> >
> > jmc
>
> I agree, this is not a big win, but when I read four instances of "the" and
> two
> instances of "structure" in two sentence where one would do, I start to lose
> focus. I don't see how this could be misinterpreted, but maybe I am missing
> something.
One could even drop the .Em nameidata because the
name of the structure is given just below.
And the functions signatures have struct nameidata *ndp, so there is no
reason to think there might be some other...
Re: tweaks to namei.9
On Thu, Aug 02, 2018 at 03:15:14PM +0100, Jason McIntyre wrote:
> On Thu, Aug 02, 2018 at 01:58:38PM +, Rob Pierce wrote:
> > A little less wordy when introducing the namieidata structure.
> >
> > Ok?
> >
> > Index: namei.9
> > ===
> > RCS file: /cvs/src/share/man/man9/namei.9,v
> > retrieving revision 1.18
> > diff -u -p -r1.18 namei.9
> > --- namei.9 23 Nov 2015 17:53:57 - 1.18
> > +++ namei.9 2 Aug 2018 13:51:43 -
> > @@ -67,10 +67,9 @@ for name-to-inode conversion, in the day
> > .Xr vfs 9
> > interface was implemented.
> > .Pp
> > -The arguments passed to the functions are encapsulated in the
> > +Arguments passed to these functions are encapsulated in the following
> > .Em nameidata
> > -structure.
> > -It has the following structure:
> > +structure:
> > .Bd -literal
> > struct nameidata {
> > /*
> >
>
> hi.
>
> i'm not sure it's a big win - it's just another way of saying the same
> thing. but now it can be interpreted to mean that there are more than one
> type of namei structure.
>
> the use of "structure" twice isn;t ideal though, i agree.
>
> jmc
I agree, this is not a big win, but when I read four instances of "the" and two
instances of "structure" in two sentence where one would do, I start to lose
focus. I don't see how this could be misinterpreted, but maybe I am missing
something.
Rob
Re: bgpd: fix rde_filter_equal
ouch!
and ok benno@
(still pondering the sofreconfig in reshuffle diff ;))
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.08.02 14:32:23 +0200:
> Currently if anyone uses the example bgpd filter rules all neighbors will
> do a full softreconfiguration even when no rule have been changed. This is
> because the skip logic was wrongly implemented and so rules like 'pass to
> ebgp' will result in non equality of the ruleset even though it is fine.
>
> By introducing a rde_filter_skip_rule() function the skip logic goes into
> a single place and so less errors should happen.
>
> OK?
> --
> :wq Claudio
>
> PS: this may speed up config reloads in some cases a fair amount
>
> Index: rde_filter.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 rde_filter.c
> --- rde_filter.c 22 Jul 2018 16:59:08 - 1.97
> +++ rde_filter.c 2 Aug 2018 12:22:10 -
> @@ -549,6 +549,37 @@ rde_prefix_match(struct filter_prefix *f
> return (0); /* should not be reached */
> }
>
> +/* return true when the rule f can never match for this peer */
> +static int
> +rde_filter_skip_rule(struct rde_peer *peer, struct filter_rule *f)
> +{
> + /* if any of the two is unset then rule can't be skipped */
> + if (peer == NULL || f == NULL)
> + return (0);
> +
> + if (f->peer.groupid != 0 &&
> + f->peer.groupid != peer->conf.groupid)
> + return (1);
> +
> + if (f->peer.peerid != 0 &&
> + f->peer.peerid != peer->conf.id)
> + return (1);
> +
> + if (f->peer.remote_as != 0 &&
> + f->peer.remote_as != peer->conf.remote_as)
> + return (1);
> +
> + if (f->peer.ebgp != 0 &&
> + f->peer.ebgp != peer->conf.ebgp)
> + return (1);
> +
> + if (f->peer.ibgp != 0 &&
> + f->peer.ibgp != !peer->conf.ebgp)
> + return (1);
> +
> + return (0);
> +}
> +
> int
> rde_filter_equal(struct filter_head *a, struct filter_head *b,
> struct rde_peer *peer, struct prefixset_head *psh)
> @@ -561,43 +592,12 @@ rde_filter_equal(struct filter_head *a,
>
> while (fa != NULL || fb != NULL) {
> /* skip all rules with wrong peer */
> - if (peer != NULL && fa != NULL && fa->peer.groupid != 0 &&
> - fa->peer.groupid != peer->conf.groupid) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> - if (peer != NULL && fa != NULL && fa->peer.peerid != 0 &&
> - fa->peer.peerid != peer->conf.id) {
> + if (rde_filter_skip_rule(peer, fa)) {
> fa = TAILQ_NEXT(fa, entry);
> continue;
> }
> -
> - if (peer != NULL && fb != NULL && fb->peer.groupid != 0 &&
> - fb->peer.groupid != peer->conf.groupid) {
> + if (rde_filter_skip_rule(peer, fb)) {
> fb = TAILQ_NEXT(fb, entry);
> - continue;
> - }
> - if (peer != NULL && fb != NULL && fb->peer.peerid != 0 &&
> - fb->peer.peerid != peer->conf.id) {
> - fb = TAILQ_NEXT(fb, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.remote_as != 0 &&
> - fa->peer.remote_as != peer->conf.remote_as) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.ebgp != 0 &&
> - fa->peer.ebgp != peer->conf.ebgp) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.ibgp != 0 &&
> - fa->peer.ibgp != !peer->conf.ebgp) {
> - fa = TAILQ_NEXT(fa, entry);
> continue;
> }
>
>
Re: tweaks to namei.9
On Thu, Aug 02, 2018 at 01:58:38PM +, Rob Pierce wrote:
> A little less wordy when introducing the namieidata structure.
>
> Ok?
>
> Index: namei.9
> ===
> RCS file: /cvs/src/share/man/man9/namei.9,v
> retrieving revision 1.18
> diff -u -p -r1.18 namei.9
> --- namei.9 23 Nov 2015 17:53:57 - 1.18
> +++ namei.9 2 Aug 2018 13:51:43 -
> @@ -67,10 +67,9 @@ for name-to-inode conversion, in the day
> .Xr vfs 9
> interface was implemented.
> .Pp
> -The arguments passed to the functions are encapsulated in the
> +Arguments passed to these functions are encapsulated in the following
> .Em nameidata
> -structure.
> -It has the following structure:
> +structure:
> .Bd -literal
> struct nameidata {
> /*
>
hi.
i'm not sure it's a big win - it's just another way of saying the same
thing. but now it can be interpreted to mean that there are more than one
type of namei structure.
the use of "structure" twice isn;t ideal though, i agree.
jmc
Re: delete switchd(8)'s unix control socket on shutdown
Please find below a better version and not so intrusive based on
httpd(8)
Index: control.c
===
RCS file: /cvs/src/usr.sbin/switchd/control.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 control.c
--- control.c 17 Jan 2017 22:10:56 - 1.8
+++ control.c 2 Aug 2018 14:11:06 -
@@ -70,11 +70,10 @@ control_run(struct privsep *ps, struct p
/*
* pledge in the control process:
* stdio - for malloc and basic I/O including events.
-* cpath - for managing the control socket.
* unix - for the control socket.
* recvfd - for the proc fd exchange.
*/
- if (pledge("stdio cpath unix recvfd", NULL) == -1)
+ if (pledge("stdio unix recvfd", NULL) == -1)
fatal("pledge");
}
@@ -203,7 +202,6 @@ control_cleanup(struct control_sock *cs)
return;
event_del(&cs->cs_ev);
event_del(&cs->cs_evt);
- (void)unlink(cs->cs_name);
}
/* ARGSUSED */
Index: switchd.c
===
RCS file: /cvs/src/usr.sbin/switchd/switchd.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 switchd.c
--- switchd.c 9 Jan 2017 14:49:22 - 1.15
+++ switchd.c 2 Aug 2018 14:11:06 -
@@ -196,11 +196,12 @@ main(int argc, char *argv[])
* stdio - for malloc and basic I/O including events.
* rpath - for reload to open and read the configuration files.
* wpath - for accessing the /dev/switch device.
+* cpath - for managing the control socket.
* inet - for opening OpenFlow and device sockets.
* dns - for resolving host in the configuration files.
* sendfd - send sockets to child processes on reload.
*/
- if (pledge("stdio rpath wpath inet dns sendfd", NULL) == -1)
+ if (pledge("stdio rpath wpath cpath inet dns sendfd", NULL) == -1)
fatal("pledge");
event_init();
@@ -472,6 +473,9 @@ parent_dispatch_control(int fd, struct p
void
parent_shutdown(struct switchd *sc)
{
+ if (sc->sc_ps.ps_csock.cs_name != NULL)
+ (void)unlink(sc->sc_ps.ps_csock.cs_name);
+
proc_kill(&sc->sc_ps);
free(sc);
On 10:42 Thu 02 Aug , Ricardo Mestre wrote:
> Hi,
>
> It seems that switchd(8) suffers from the same issue I reported yesterday
> about
> eigrpd(8), the daemon when it's shutdown never deletes the unix control socket
> because that is being done from a chrooted process.
>
> This one nevertheless took a little bit more effort since I had to disentangle
> 2 struct event and 1 fd from struct control_sock into their own
> struct control_state, just like we have on other daemons.
>
> Also updated the pledge(2)s accordingly moving "cpath" from the chrooted proc
> to the main proc.
>
> Regression tests passed without issues and switchctl(8) also didn't complain.
>
> Comments? OK?
>
tweaks to namei.9
A little less wordy when introducing the namieidata structure.
Ok?
Index: namei.9
===
RCS file: /cvs/src/share/man/man9/namei.9,v
retrieving revision 1.18
diff -u -p -r1.18 namei.9
--- namei.9 23 Nov 2015 17:53:57 - 1.18
+++ namei.9 2 Aug 2018 13:51:43 -
@@ -67,10 +67,9 @@ for name-to-inode conversion, in the day
.Xr vfs 9
interface was implemented.
.Pp
-The arguments passed to the functions are encapsulated in the
+Arguments passed to these functions are encapsulated in the following
.Em nameidata
-structure.
-It has the following structure:
+structure:
.Bd -literal
struct nameidata {
/*
Re: unveil: incomplete unveil_flagmatch semantic
On Mon, Jul 30, 2018 at 07:55:35AM -0600, Bob Beck wrote: > yeah the latter will be the way to go > new diff with direct lookup using an indirection table. first reorders PLEDGE flags to have: - PLEDGE promises that could occurs in ni_pledge and are used for unveil(2) - PLEDGE promises that could occurs in ni_pledge and aren't used for unveil(2) (as PLEDGE_UNVEIL, PLEDGE_STAT, PLEDGE_STATLIE) - others promises - so I redefined PLEDGE_USERSET a bit differently (as some of these flags are used in ni_pledge) there is 8 different promises for the first category. So we just need a 256 long array to have a table to direct lookup PLEDGE -> UNVEIL. for representing UNVEIL flags, I changed type from uint64_t to u_char. I hooked a init function in taskq_init() in order to properly initialize the lookup array, but I am unsure of the placement. some names for constants/variable could have better names, but I had no inspiration. Thanks. -- Sebastien Marie Index: sys/pledge.h === RCS file: /cvs/src/sys/sys/pledge.h,v retrieving revision 1.37 diff -u -p -r1.37 pledge.h --- sys/pledge.h13 Jul 2018 09:25:23 - 1.37 +++ sys/pledge.h2 Aug 2018 12:51:28 - @@ -23,54 +23,64 @@ #include /* - * pledge(2) requests + * pledge(2) promises */ #define PLEDGE_ALWAYS 0xULL + +/* promises used in ni_pledge */ #define PLEDGE_RPATH 0x0001ULL /* allow open for read */ #define PLEDGE_WPATH 0x0002ULL /* allow open for write */ #define PLEDGE_CPATH 0x0004ULL /* allow creat, mkdir, unlink etc */ -#define PLEDGE_STDIO 0x0008ULL /* operate on own pid */ -#define PLEDGE_TMPPATH 0x0010ULL /* for mk*temp() */ -#define PLEDGE_DNS 0x0020ULL /* DNS services */ -#define PLEDGE_INET0x0040ULL /* AF_INET/AF_INET6 sockets */ -#define PLEDGE_FLOCK 0x0080ULL /* file locking */ -#define PLEDGE_UNIX0x0100ULL /* AF_UNIX sockets */ -#define PLEDGE_ID 0x0200ULL /* allow setuid, setgid, etc */ -#define PLEDGE_TAPE0x0400ULL /* Tape ioctl */ -#define PLEDGE_GETPW 0x0800ULL /* YP enables if ypbind.lock */ -#define PLEDGE_PROC0x1000ULL /* fork, waitpid, etc */ -#define PLEDGE_SETTIME 0x2000ULL /* able to set/adj time/freq */ -#define PLEDGE_FATTR 0x4000ULL /* allow explicit file st_* mods */ -#define PLEDGE_PROTEXEC0x8000ULL /* allow use of PROT_EXEC */ -#define PLEDGE_TTY 0x0001ULL /* tty setting */ -#define PLEDGE_SENDFD 0x0002ULL /* AF_UNIX CMSG fd sending */ -#define PLEDGE_RECVFD 0x0004ULL /* AF_UNIX CMSG fd receiving */ -#define PLEDGE_EXEC0x0008ULL /* execve, child is free of pledge */ -#define PLEDGE_ROUTE 0x0010ULL /* routing lookups */ -#define PLEDGE_MCAST 0x0020ULL /* multicast joins */ -#define PLEDGE_VMINFO 0x0040ULL /* vminfo listings */ -#define PLEDGE_PS 0x0080ULL /* ps listings */ -#define PLEDGE_DISKLABEL 0x0200ULL /* disklabels */ -#define PLEDGE_PF 0x0400ULL /* pf ioctls */ -#define PLEDGE_AUDIO 0x0800ULL /* audio ioctls */ -#define PLEDGE_DPATH 0x1000ULL /* mknod & mkfifo */ -#define PLEDGE_DRM 0x2000ULL /* drm ioctls */ -#define PLEDGE_VMM 0x4000ULL /* vmm ioctls */ -#define PLEDGE_CHOWN 0x8000ULL /* chown(2) family */ -#define PLEDGE_CHOWNUID0x0001ULL /* allow owner/group changes */ -#define PLEDGE_BPF 0x0002ULL /* bpf ioctl */ -#define PLEDGE_ERROR 0x0004ULL /* ENOSYS instead of kill */ -#define PLEDGE_WROUTE 0x0008ULL /* interface address ioctls */ -#define PLEDGE_UNVEIL 0x0010ULL /* allow unveil() */ +#define PLEDGE_DPATH 0x0008ULL /* mknod & mkfifo */ +#define PLEDGE_FATTR 0x0010ULL /* allow explicit file st_* mods */ +#define PLEDGE_TTY 0x0020ULL /* tty setting */ +#define PLEDGE_UNIX0x0040ULL /* AF_UNIX sockets */ +#define PLEDGE_EXEC0x0080ULL /* execve, child is free of pledge */ + +#define UNVEIL_PLDGMASK0x00ffULL + +/* these could occurs in ni_pledge but are ignored */ +#define PLEDGE_UNVEIL 0x0100ULL /* allow unveil() */ +#define PLEDGE_STAT0x0200ULL /* XXX this is a stat */ +#define PLEDGE_STATLIE 0x0400ULL + +#define UNVEIL_PLDGIGN 0x0700ULL + +/* others promises */ +#define PLEDGE_STDIO 0x0800ULL /* operate on own pid */ +#define PLEDGE_TMPPATH 0x1000ULL /* for mk*temp() */ +#define PLEDGE_DNS
Re: bgpd: sofreconfig in reshuffle
On Tue, Jul 31, 2018 at 05:39:31PM +0200, Claudio Jeker wrote:
> Instead of walking the Adj-RIB-In per RIB walk it once and check per
> prefix if the RIB needs an update or not. This will make it easier to make
> this run without blocking the system for a long time.
>
Here is a bigger version that also reshuffles the softreconfig out case.
Now every rib is only walked at maximum once. I think this may be faster
than before but the big kicker will come once this is in. Because from
here it is only a small step to make the softreconfig task run in
background and so the RDE will no longer lock up during reload.
Still looking for OKs :)
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.406
diff -u -p -r1.406 rde.c
--- rde.c 2 Aug 2018 12:49:00 - 1.406
+++ rde.c 2 Aug 2018 12:51:16 -
@@ -90,6 +90,7 @@ void rde_rib_free(struct rib_desc *);
int rde_rdomain_import(struct rde_aspath *, struct rdomain *);
voidrde_reload_done(void);
+static void rde_softreconfig_done(void *);
static void rde_softreconfig_out(struct rib_entry *, void *);
static void rde_softreconfig_in(struct rib_entry *, void *);
static void rde_softreconfig_unload_peer(struct rib_entry *, void *);
@@ -124,7 +125,7 @@ struct bgpd_config *conf, *nconf;
time_t reloadtime;
struct rde_peer_headpeerlist;
struct rde_peer*peerself;
-struct prefixset_head *prefixsets_tmp;
+struct prefixset_head *prefixsets_tmp, *prefixsets_old;
struct filter_head *out_rules, *out_rules_tmp;
struct rdomain_head*rdomains_l, *newdomains;
struct imsgbuf *ibuf_se;
@@ -2697,7 +2698,6 @@ rde_reload_done(void)
struct rde_peer *peer;
struct filter_head *fh;
u_int16_trid;
- struct prefixset_head *prefixsets_old;
/* first merge the main config */
if ((nconf->flags & BGPD_FLAG_NO_EVALUATE)
@@ -2801,10 +2801,9 @@ rde_reload_done(void)
log_debug("in filter change: reloading RIB %s",
ribs[rid].name);
ribs[rid].state = RECONF_RELOAD;
- /* FALLTHROUGH */
+ break;
case RECONF_REINIT:
- rib_dump(&ribs[RIB_ADJ_IN].rib, rde_softreconfig_in,
- &ribs[rid], AID_UNSPEC);
+ ribs[rid].state = RECONF_RELOAD;
break;
case RECONF_RELOAD:
log_warnx("Bad rib reload state");
@@ -2812,22 +2811,40 @@ rde_reload_done(void)
case RECONF_NONE:
break;
}
+ filterlist_free(ribs[rid].in_rules_tmp);
+ ribs[rid].in_rules_tmp = NULL;
}
+ rib_dump(&ribs[RIB_ADJ_IN].rib, rde_softreconfig_in, NULL, AID_UNSPEC);
+
+ /* now do the Adj-RIB-Out sync */
+ for (rid = 0; rid < rib_size; rid++)
+ ribs[rid].state = RECONF_NONE;
+
LIST_FOREACH(peer, &peerlist, peer_l) {
if (peer->reconf_out)
- rib_dump(peer->rib, rde_softreconfig_out,
- peer, AID_UNSPEC);
+ ribs[rid].state = RECONF_RELOAD;
else if (peer->reconf_rib)
/* dump the full table to neighbors that changed rib */
peer_dump(peer->conf.id, AID_UNSPEC);
}
+
+ for (rid = 0; rid < rib_size; rid++)
+ rib_dump(&ribs[rid].rib, rde_softreconfig_out, NULL,
+ AID_UNSPEC);
+
+ rde_softreconfig_done(NULL);
+}
+
+static void
+rde_softreconfig_done(void *arg)
+{
+ u_int16_trid;
+
filterlist_free(out_rules_tmp);
out_rules_tmp = NULL;
for (rid = 0; rid < rib_size; rid++) {
if (*ribs[rid].name == '\0')
continue;
- filterlist_free(ribs[rid].in_rules_tmp);
- ribs[rid].in_rules_tmp = NULL;
ribs[rid].state = RECONF_NONE;
}
@@ -2840,16 +2857,17 @@ rde_reload_done(void)
}
static void
-rde_softreconfig_in(struct rib_entry *re, void *ptr)
+rde_softreconfig_in(struct rib_entry *re, void *bula)
{
struct filterstate state;
- struct rib_desc *rib = ptr;
+ struct rib_desc *rib;
struct prefix *p;
struct pt_entry *pt;
struct rde_peer *peer;
struct rde_aspath *asp;
enum filter_actions action;
struct bgpd_addr addr;
+ u_int16_ti;
pt = re->prefix;
pt_getaddr(pt, &addr);
@@ -2857,37 +2875,39 @@ rde_softreconfig_in(struct rib_entry *re
asp = prefix_aspath(p);
bgpd: fix rde_filter_equal
Currently if anyone uses the example bgpd filter rules all neighbors will
do a full softreconfiguration even when no rule have been changed. This is
because the skip logic was wrongly implemented and so rules like 'pass to
ebgp' will result in non equality of the ruleset even though it is fine.
By introducing a rde_filter_skip_rule() function the skip logic goes into
a single place and so less errors should happen.
OK?
--
:wq Claudio
PS: this may speed up config reloads in some cases a fair amount
Index: rde_filter.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v
retrieving revision 1.97
diff -u -p -r1.97 rde_filter.c
--- rde_filter.c22 Jul 2018 16:59:08 - 1.97
+++ rde_filter.c2 Aug 2018 12:22:10 -
@@ -549,6 +549,37 @@ rde_prefix_match(struct filter_prefix *f
return (0); /* should not be reached */
}
+/* return true when the rule f can never match for this peer */
+static int
+rde_filter_skip_rule(struct rde_peer *peer, struct filter_rule *f)
+{
+ /* if any of the two is unset then rule can't be skipped */
+ if (peer == NULL || f == NULL)
+ return (0);
+
+ if (f->peer.groupid != 0 &&
+ f->peer.groupid != peer->conf.groupid)
+ return (1);
+
+ if (f->peer.peerid != 0 &&
+ f->peer.peerid != peer->conf.id)
+ return (1);
+
+ if (f->peer.remote_as != 0 &&
+ f->peer.remote_as != peer->conf.remote_as)
+ return (1);
+
+ if (f->peer.ebgp != 0 &&
+ f->peer.ebgp != peer->conf.ebgp)
+ return (1);
+
+ if (f->peer.ibgp != 0 &&
+ f->peer.ibgp != !peer->conf.ebgp)
+ return (1);
+
+ return (0);
+}
+
int
rde_filter_equal(struct filter_head *a, struct filter_head *b,
struct rde_peer *peer, struct prefixset_head *psh)
@@ -561,43 +592,12 @@ rde_filter_equal(struct filter_head *a,
while (fa != NULL || fb != NULL) {
/* skip all rules with wrong peer */
- if (peer != NULL && fa != NULL && fa->peer.groupid != 0 &&
- fa->peer.groupid != peer->conf.groupid) {
- fa = TAILQ_NEXT(fa, entry);
- continue;
- }
- if (peer != NULL && fa != NULL && fa->peer.peerid != 0 &&
- fa->peer.peerid != peer->conf.id) {
+ if (rde_filter_skip_rule(peer, fa)) {
fa = TAILQ_NEXT(fa, entry);
continue;
}
-
- if (peer != NULL && fb != NULL && fb->peer.groupid != 0 &&
- fb->peer.groupid != peer->conf.groupid) {
+ if (rde_filter_skip_rule(peer, fb)) {
fb = TAILQ_NEXT(fb, entry);
- continue;
- }
- if (peer != NULL && fb != NULL && fb->peer.peerid != 0 &&
- fb->peer.peerid != peer->conf.id) {
- fb = TAILQ_NEXT(fb, entry);
- continue;
- }
-
- if (peer != NULL && fa != NULL && fa->peer.remote_as != 0 &&
- fa->peer.remote_as != peer->conf.remote_as) {
- fa = TAILQ_NEXT(fa, entry);
- continue;
- }
-
- if (peer != NULL && fa != NULL && fa->peer.ebgp != 0 &&
- fa->peer.ebgp != peer->conf.ebgp) {
- fa = TAILQ_NEXT(fa, entry);
- continue;
- }
-
- if (peer != NULL && fa != NULL && fa->peer.ibgp != 0 &&
- fa->peer.ibgp != !peer->conf.ebgp) {
- fa = TAILQ_NEXT(fa, entry);
continue;
}
delete ntpd(8)'s unix control socket on shutdown
Hi,
ntpd(8) also doesn't seem to delete its unix control socket, but in this case
it's not a matter of calling control_cleanup() from a chrooted process
but instead not calling it at all.
OK?
Index: ntpd.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
retrieving revision 1.113
diff -u -p -u -r1.113 ntpd.c
--- ntpd.c 9 Jan 2017 14:49:22 - 1.113
+++ ntpd.c 2 Aug 2018 10:17:11 -
@@ -244,7 +244,7 @@ main(int argc, char *argv[])
* Constraint processes are forked with certificates in memory,
* then privdrop into chroot before speaking to the outside world.
*/
- if (pledge("stdio rpath inet settime proc exec id", NULL) == -1)
+ if (pledge("stdio rpath cpath inet settime proc exec id", NULL) == -1)
err(1, "pledge");
while (quit == 0) {
@@ -327,6 +327,7 @@ main(int argc, char *argv[])
msgbuf_clear(&ibuf->w);
free(ibuf);
+ control_cleanup(CTLSOCKET);
log_info("Terminating");
return (0);
}
delete switchd(8)'s unix control socket on shutdown
Hi,
It seems that switchd(8) suffers from the same issue I reported yesterday about
eigrpd(8), the daemon when it's shutdown never deletes the unix control socket
because that is being done from a chrooted process.
This one nevertheless took a little bit more effort since I had to disentangle
2 struct event and 1 fd from struct control_sock into their own
struct control_state, just like we have on other daemons.
Also updated the pledge(2)s accordingly moving "cpath" from the chrooted proc
to the main proc.
Regression tests passed without issues and switchctl(8) also didn't complain.
Comments? OK?
Index: control.c
===
RCS file: /cvs/src/usr.sbin/switchd/control.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 control.c
--- control.c 17 Jan 2017 22:10:56 - 1.8
+++ control.c 2 Aug 2018 09:04:28 -
@@ -70,11 +70,10 @@ control_run(struct privsep *ps, struct p
/*
* pledge in the control process:
* stdio - for malloc and basic I/O including events.
-* cpath - for managing the control socket.
* unix - for the control socket.
* recvfd - for the proc fd exchange.
*/
- if (pledge("stdio cpath unix recvfd", NULL) == -1)
+ if (pledge("stdio unix recvfd", NULL) == -1)
fatal("pledge");
}
@@ -171,7 +170,7 @@ control_init(struct privsep *ps, struct
}
socket_set_blockmode(fd, BM_NONBLOCK);
- cs->cs_fd = fd;
+ control_state.fd = fd;
cs->cs_env = env;
return (0);
@@ -183,27 +182,27 @@ control_listen(struct control_sock *cs)
if (cs->cs_name == NULL)
return (0);
- if (listen(cs->cs_fd, CONTROL_BACKLOG) == -1) {
+ if (listen(control_state.fd, CONTROL_BACKLOG) == -1) {
log_warn("%s: listen", __func__);
return (-1);
}
- event_set(&cs->cs_ev, cs->cs_fd, EV_READ,
+ event_set(&control_state.ev, control_state.fd, EV_READ,
control_accept, cs);
- event_add(&cs->cs_ev, NULL);
- evtimer_set(&cs->cs_evt, control_accept, cs);
+ event_add(&control_state.ev, NULL);
+ evtimer_set(&control_state.evt, control_accept, cs);
return (0);
}
void
-control_cleanup(struct control_sock *cs)
+control_cleanup(char *path)
{
- if (cs->cs_name == NULL)
+ if (path == NULL)
return;
- event_del(&cs->cs_ev);
- event_del(&cs->cs_evt);
- (void)unlink(cs->cs_name);
+ event_del(&control_state.ev);
+ event_del(&control_state.evt);
+ (void)unlink(path);
}
/* ARGSUSED */
@@ -216,7 +215,7 @@ control_accept(int listenfd, short event
struct sockaddr_un sun;
struct ctl_conn *c;
- event_add(&cs->cs_ev, NULL);
+ event_add(&control_state.ev, NULL);
if ((event & EV_TIMEOUT))
return;
@@ -230,8 +229,8 @@ control_accept(int listenfd, short event
if (errno == ENFILE || errno == EMFILE) {
struct timeval evtpause = { 1, 0 };
- event_del(&cs->cs_ev);
- evtimer_add(&cs->cs_evt, &evtpause);
+ event_del(&control_state.ev);
+ evtimer_add(&control_state.evt, &evtpause);
} else if (errno != EWOULDBLOCK && errno != EINTR &&
errno != ECONNABORTED)
log_warn("%s: accept", __func__);
@@ -287,9 +286,9 @@ control_close(int fd, struct control_soc
close(c->iev.ibuf.fd);
/* Some file descriptors are available again. */
- if (evtimer_pending(&cs->cs_evt, NULL)) {
- evtimer_del(&cs->cs_evt);
- event_add(&cs->cs_ev, NULL);
+ if (evtimer_pending(&control_state.evt, NULL)) {
+ evtimer_del(&control_state.evt);
+ event_add(&control_state.ev, NULL);
}
free(c);
Index: proc.c
===
RCS file: /cvs/src/usr.sbin/switchd/proc.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 proc.c
--- proc.c 29 May 2017 12:56:26 - 1.12
+++ proc.c 2 Aug 2018 09:04:28 -
@@ -475,9 +475,6 @@ proc_shutdown(struct privsep_proc *p)
{
struct privsep *ps = p->p_ps;
- if (p->p_id == PROC_CONTROL && ps)
- control_cleanup(&ps->ps_csock);
-
if (p->p_shutdown != NULL)
(*p->p_shutdown)();
Index: proc.h
===
RCS file: /cvs/src/usr.sbin/switchd/proc.h,v
retrieving revision 1.6
diff -u -p -u -r1.6 proc.h
--- proc.h 9 Jan 2017 14:49:22 - 1.6
+++ proc.h 2 Aug 2018 09:04:28 -
@@ -23,11 +23,14 @@
#ifndef _PROC_H
#define _PROC_H
+struct {
+ struct eventev;
+ struct eventevt;
+ int fd;
+} control_stat
Re: acme-client.1 - fix mangled sentence and stray plural
All 3 are OK with me, if there are no objections I can commit them later (but would be happy if someone beats me to it :) On 2018/08/02 14:49, Ross L Richardson wrote: > > This is the first of several diffs containing separate bits of the > earlier combined diff. > > "X509" to "X.509" for correctness and consistency with acme-client.conf.5 > > > Index: acme-client.1 > === > RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v > retrieving revision 1.24 > diff -u -p -r1.24 acme-client.1 > --- acme-client.1 13 Jun 2018 15:08:24 - 1.24 > +++ acme-client.1 2 Aug 2018 04:29:36 - > @@ -44,7 +44,7 @@ Specify an alternative configuration fil > .It Fl n > No operation: check and print configuration. > .It Fl r > -Revoke the X509 certificate found in the certificates. > +Revoke the X.509 certificate. > .It Fl v > Verbose operation. > Specify twice to also trace communication and data transfers. > @@ -110,7 +110,7 @@ as above: > .Pp > A daily > .Xr cron 8 > -job can renew the certificates: > +job can renew the certificate: > .Pp > .Dl acme-client example.com && rcctl reload httpd > .Sh SEE ALSO > On 2018/08/02 14:57, Ross L Richardson wrote: > > It's an "X.509 certificate" rather than a "TLS certificate". > As pointed out by sthen@, TLS isn't the only possible use. > > > > Index: acme-client.1 > === > RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v > retrieving revision 1.24 > diff -u -p -r1.24 acme-client.1 > --- acme-client.1 13 Jun 2018 15:08:24 - 1.24 > +++ acme-client.1 2 Aug 2018 04:41:05 - > @@ -56,7 +56,7 @@ The domain name. > looks in its configuration for a > .Ar domain > section corresponding to the domain given as command line argument. > -It then uses that configuration to retrieve a TLS certificate. > +It then uses that configuration to retrieve an X.509 certificate. > If the certificate already exists and is less than 30 days from expiry, > .Nm > will attempt to refresh the signature. > On 2018/08/02 15:09, Ross L Richardson wrote: > > According to code (and testing), each is optional but at least > one must be present. > > > Index: acme-client.conf.5 > === > RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v > retrieving revision 1.13 > diff -u -p -r1.13 acme-client.conf.5 > --- acme-client.conf.58 Jul 2018 15:41:17 - 1.13 > +++ acme-client.conf.52 Aug 2018 04:33:57 - > @@ -120,6 +120,9 @@ plain domain name forms. > The private key file for which the certificate will be obtained. > .It Ic domain certificate Ar file > The filename of the certificate that will be issued. > +This is optional if > +.Ar domain full chain certificate > +is specified. > .It Ic domain chain certificate Ar file > The filename in which to store the certificate chain > that will be returned by the certificate authority. > @@ -137,6 +140,9 @@ This is a combination of the > and the > .Ar domain chain certificate > in one file, and is required by most browsers. > +This is optional if > +.Ar domain certificate > +is specified. > .It Ic sign with Ar authority > The certificate authority (as declared above in the > .Sx AUTHORITIES >
Re: Floating point exception on boot after using syspatch(8)
i have just created AMI from 6.3-current (snapshot from 1 Aug) - and it boots correctly. For eager-FPU - i have rolled-back syspatch(8) using -r up to first patch - and it was broken before eager-FPU which was introduced in errata 010 - so i am not sure this is it. I will try to investigate that oddness bit more... _ Zbyszek Żółkiewski > Wiadomość napisana przez Philip Guenther w dniu > 01.08.2018, o godz. 23:41: > > I made a later commit in that area (sys/arch/amd64/amd64/cpu.c rev 1.124) > so it would be interesting to know if -current shows the same issue or if > the symptoms have improved (or changed at all) there.
Re: bsd.port.mk: make clean=build && make : failed
On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote:
> Hi,
>
> After issuing a "make clean=build" on a port, I am unable to build
> again.
>
> "make" failed in 'configure' stage:
>
> $ make
> ...
> /bin/sh: cannot create
> /home/semarie/repos/openbsd/ports/pobj/rust-1.28.0/bin/aclocal: Permission
> denied
> *** Error 1 in .
> (/home/semarie/repos/openbsd/ports/infrastructure/mk/bsd.port.mk:2689
> '_post-configure-finalize': @printf '#!/bin/sh\nexit ...)
> *** Error 1 in .
> (/home/semarie/repos/openbsd/ports/infrastructure/mk/bsd.port.mk:2708
> '/home/semarie/repos/openbsd/ports/pobj/rust-1.28.0/build-amd64/.configure_done')
> *** Error 1 in /home/semarie/ports/mystuff/lang/rust
> (/home/semarie/repos/openbsd/ports/infrastructure/mk/bsd.port.mk:2396 'all')
>
> It is due to _post-configure-finalize target that chmod 555 on the file,
> and after that, ksh is unable to override it.
>
> One possibility is to have just 755 on mode.
>
> Another would be to rm -f ${WRKDIR}/bin/${_wrap} before the printf.
>
> Thanks.
> --
> Sebastien Marie
Oh, actually, the aclocal part was not intended at all. Lol
Re: bsd.port.mk: make clean=build && make : failed
On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote:
> Hi,
>
> After issuing a "make clean=build" on a port, I am unable to build
> again.
>
> "make" failed in 'configure' stage:
>
> $ make
> ...
> /bin/sh: cannot create
> /home/semarie/repos/openbsd/ports/pobj/rust-1.28.0/bin/aclocal: Permission
> denied
> *** Error 1 in .
> (/home/semarie/repos/openbsd/ports/infrastructure/mk/bsd.port.mk:2689
> '_post-configure-finalize': @printf '#!/bin/sh\nexit ...)
> *** Error 1 in .
> (/home/semarie/repos/openbsd/ports/infrastructure/mk/bsd.port.mk:2708
> '/home/semarie/repos/openbsd/ports/pobj/rust-1.28.0/build-amd64/.configure_done')
> *** Error 1 in /home/semarie/ports/mystuff/lang/rust
> (/home/semarie/repos/openbsd/ports/infrastructure/mk/bsd.port.mk:2396 'all')
>
> It is due to _post-configure-finalize target that chmod 555 on the file,
> and after that, ksh is unable to override it.
>
> One possibility is to have just 755 on mode.
>
> Another would be to rm -f ${WRKDIR}/bin/${_wrap} before the printf.
>
> Thanks.
> --
I'll do that.
Because it's the thing that makes sense. You do expect all configure parts
to go away when make clean=build
