mbg(4): tsleep(9) -> tsleep_nsec(9)
Hi,
mbg(4) is among the few remaining drivers using tsleep(9).
In a few spots, when the kernel is not cold, the driver will spin for
up to 1/10 seconds waiting for the MBG_BUSY flag to go low.
We can approximate this behavior by spinning 10 times and sleeping 10
milliseconds each iteration. 10 x 10ms = 100ms = 1/10 seconds.
I can't test this but I was able to compile it on amd64. It isn't
normally built for amd64, though. Just i386.
I have my doubts that anyone has this card and is able to actually
test this diff.
Anybody ok?
Index: mbg.c
===
RCS file: /cvs/src/sys/dev/pci/mbg.c,v
retrieving revision 1.31
diff -u -p -r1.31 mbg.c
--- mbg.c 29 Nov 2020 03:17:27 - 1.31
+++ mbg.c 4 Dec 2020 04:39:59 -
@@ -417,12 +417,12 @@ mbg_read_amcc_s5920(struct mbg_softc *sc
/* wait for the BUSY flag to go low (approx 70 us on i386) */
timer = 0;
- tmax = cold ? 50 : hz / 10;
+ tmax = cold ? 50 : 10;
do {
if (cold)
delay(20);
else
- tsleep(tstamp, 0, "mbg", 1);
+ tsleep_nsec(tstamp, 0, "mbg", MSEC_TO_NSEC(10));
status = bus_space_read_1(sc->sc_iot, sc->sc_ioh,
AMCC_IMB4 + 3);
} while ((status & MBG_BUSY) && timer++ < tmax);
@@ -473,12 +473,12 @@ mbg_read_amcc_s5933(struct mbg_softc *sc
/* wait for the BUSY flag to go low (approx 70 us on i386) */
timer = 0;
- tmax = cold ? 50 : hz / 10;
+ tmax = cold ? 50 : 10;
do {
if (cold)
delay(20);
else
- tsleep(tstamp, 0, "mbg", 1);
+ tsleep_nsec(tstamp, 0, "mbg", MSEC_TO_NSEC(10));
status = bus_space_read_1(sc->sc_iot, sc->sc_ioh,
AMCC_IMB4 + 3);
} while ((status & MBG_BUSY) && timer++ < tmax);
@@ -525,12 +525,12 @@ mbg_read_asic(struct mbg_softc *sc, int
/* wait for the BUSY flag to go low */
timer = 0;
- tmax = cold ? 50 : hz / 10;
+ tmax = cold ? 50 : 10;
do {
if (cold)
delay(20);
else
- tsleep(tstamp, 0, "mbg", 1);
+ tsleep_nsec(tstamp, 0, "mbg", MSEC_TO_NSEC(10));
status = bus_space_read_1(sc->sc_iot, sc->sc_ioh, ASIC_STATUS);
} while ((status & MBG_BUSY) && timer++ < tmax);
srp_finalize(9): tsleep(9) -> tsleep_nsec(9)
Hi,
srp_finalize(9) uses tsleep(9) to spin while it waits for the object's
refcount to reach zero. It blocks for up to 1 tick and then checks
the refecount again and again.
We can just as easily do this with tsleep_nsec(9) and block for 1
millisecond per interval.
ok?
Index: kern_srp.c
===
RCS file: /cvs/src/sys/kern/kern_srp.c,v
retrieving revision 1.12
diff -u -p -r1.12 kern_srp.c
--- kern_srp.c 8 Sep 2017 05:36:53 - 1.12
+++ kern_srp.c 4 Dec 2020 04:04:39 -
@@ -274,7 +274,7 @@ void
srp_finalize(void *v, const char *wmesg)
{
while (srp_referenced(v))
- tsleep(v, PWAIT, wmesg, 1);
+ tsleep_nsec(v, PWAIT, wmesg, MSEC_TO_NSEC(1));
}
#else /* MULTIPROCESSOR */
tht(4): more tsleep(9) -> tsleep_nsec(9) conversions
Hi,
tht(4) is another driver still using tsleep(9).
It uses it to spin while it waits for the card to load the firmware.
Then it uses it to spin for up to 2 seconds while waiting for
THT_REG_INIT_STATUS.
In the firmware case we can sleep for 10 milliseconds each iteration.
In the THT_REG_INIT_STATUS loop we can sleep for 10 milliseconds each
iteration again, but instead of using a timeout to set a flag after 2
seconds we can just count how many milliseconds we've slept. This is
less precise than using the timeout but it is much simpler. Obviously
we then need to remove all the timeout-related stuff from the function
and the file.
Thoughts? ok?
Index: if_tht.c
===
RCS file: /cvs/src/sys/dev/pci/if_tht.c,v
retrieving revision 1.142
diff -u -p -r1.142 if_tht.c
--- if_tht.c10 Jul 2020 13:26:38 - 1.142
+++ if_tht.c4 Dec 2020 03:57:21 -
@@ -582,7 +582,6 @@ voidtht_lladdr_read(struct
tht_softc
void tht_lladdr_write(struct tht_softc *);
inttht_sw_reset(struct tht_softc *);
inttht_fw_load(struct tht_softc *);
-void tht_fw_tick(void *arg);
void tht_link_state(struct tht_softc *);
/* interface operations */
@@ -1667,11 +1666,9 @@ tht_sw_reset(struct tht_softc *sc)
int
tht_fw_load(struct tht_softc *sc)
{
- struct timeout ticker;
- volatile intok = 1;
u_int8_t*fw, *buf;
size_t fwlen, wrlen;
- int error = 1;
+ int error = 1, msecs, ret;
if (loadfirmware("tht", , ) != 0)
return (1);
@@ -1682,7 +1679,9 @@ tht_fw_load(struct tht_softc *sc)
buf = fw;
while (fwlen > 0) {
while (tht_fifo_writable(sc, >sc_txt) <= THT_FIFO_GAP) {
- if (tsleep(sc, PCATCH, "thtfw", 1) == EINTR)
+ ret = tsleep_nsec(sc, PCATCH, "thtfw",
+ MSEC_TO_NSEC(10));
+ if (ret == EINTR)
goto err;
}
@@ -1695,32 +1694,21 @@ tht_fw_load(struct tht_softc *sc)
buf += wrlen;
}
- timeout_set(, tht_fw_tick, (void *));
- timeout_add_sec(, 2);
- while (ok) {
+ for (msecs = 0; msecs < 2000; msecs += 10) {
if (tht_read(sc, THT_REG_INIT_STATUS) != 0) {
error = 0;
break;
}
-
- if (tsleep(sc, PCATCH, "thtinit", 1) == EINTR)
+ ret = tsleep_nsec(sc, PCATCH, "thtinit", MSEC_TO_NSEC(10));
+ if (ret == EINTR)
goto err;
}
- timeout_del();
tht_write(sc, THT_REG_INIT_SEMAPHORE, 0x1);
err:
free(fw, M_DEVBUF, fwlen);
return (error);
-}
-
-void
-tht_fw_tick(void *arg)
-{
- volatile int*ok = arg;
-
- *ok = 0;
}
void
hvn(4): msleep(9) -> msleep_nsec(9)
Hi, In hvn_alloc_cmd() we spin within a mutex while the freelist is empty. Because we're using a mutex there is no way to miss the wakeup(9) from hvn_free_cmd(), so we don't even need a timeout here. Instead of doing msleep(9) for 1 tick repeatedly we can msleep_nsec(9) without a timeout (INFSLP) repeatedly and poll less in this spot. Once again I can't test this. But the principle of protecting the sleep with a mutex is sound. ok? Index: if_hvn.c === RCS file: /cvs/src/sys/dev/pv/if_hvn.c,v retrieving revision 1.43 diff -u -p -r1.43 if_hvn.c --- if_hvn.c4 Dec 2020 03:22:46 - 1.43 +++ if_hvn.c4 Dec 2020 03:35:25 - @@ -1127,8 +1127,8 @@ hvn_alloc_cmd(struct hvn_softc *sc) mtx_enter(>sc_cntl_fqlck); while ((rc = TAILQ_FIRST(>sc_cntl_fq)) == NULL) - msleep(>sc_cntl_fq, >sc_cntl_fqlck, - PRIBIO, "nvsalloc", 1); + msleep_nsec(>sc_cntl_fq, >sc_cntl_fqlck, + PRIBIO, "nvsalloc", INFSLP); TAILQ_REMOVE(>sc_cntl_fq, rc, rc_entry); mtx_leave(>sc_cntl_fqlck); return (rc);
softraid(4): more tsleep(9) -> tsleep_nsec(9) conversions
Hi,
softraid(4) is another driver still using tsleep(9).
softraid(4) uses tsleep(9) in one spot to poll for completion. It
uses it in two other spots to momentarily yield the CPU to permit a
different thread to make progress.
In all cases the length of the timeout is totally arbitrary. We're
just spinning or yielding. The duration doesn't matter much.
Currently we tsleep(9) for up to 1 tick. Instead let's tsleep_nsec(9)
for 1 millisecond.
ok?
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.416
diff -u -p -r1.416 softraid.c
--- softraid.c 15 Oct 2020 00:13:47 - 1.416
+++ softraid.c 4 Dec 2020 03:29:20 -
@@ -3885,7 +3885,7 @@ sr_discipline_shutdown(struct sr_discipl
if (sd->sd_reb_active) {
sd->sd_reb_abort = 1;
while (sd->sd_reb_active)
- tsleep(sd, PWAIT, "sr_shutdown", 1);
+ tsleep_nsec(sd, PWAIT, "sr_shutdown", MSEC_TO_NSEC(1));
}
if (meta_save)
@@ -4765,7 +4765,7 @@ sr_rebuild(struct sr_discipline *sd)
}
/* yield if we didn't sleep */
if (slept == 0)
- tsleep(sc, PWAIT, "sr_yield", 1);
+ tsleep_nsec(sc, PWAIT, "sr_yield", MSEC_TO_NSEC(1));
sr_scsi_wu_put(sd, wu_r);
sr_scsi_wu_put(sd, wu_w);
Index: softraid_raid5.c
===
RCS file: /cvs/src/sys/dev/softraid_raid5.c,v
retrieving revision 1.30
diff -u -p -r1.30 softraid_raid5.c
--- softraid_raid5.c26 Mar 2020 11:28:23 - 1.30
+++ softraid_raid5.c4 Dec 2020 03:29:20 -
@@ -857,8 +857,10 @@ sr_raid5_rebuild(struct sr_discipline *s
tsleep_nsec(wu_w, PRIBIO, "sr_rebuild", INFSLP);
slept = 1;
}
- if (!slept)
- tsleep(sd->sd_sc, PWAIT, "sr_yield", 1);
+ if (!slept) {
+ tsleep_nsec(sd->sd_sc, PWAIT, "sr_yield",
+ MSEC_TO_NSEC(1));
+ }
sr_scsi_wu_put(sd, wu_r);
sr_scsi_wu_put(sd, wu_w);
Re: Use SMR_TAILQ for `ps_threads'
On Wed, Dec 02, 2020 at 07:44:02PM +0100, Anton Lindqvist wrote:
> On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> > > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > > > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > > > [...]
> > > > > Did you run a make build with that smr_barrier() in it and checked
> > > > > that it
> > > > > does not cause a slow down? I am sceptical, smr_barrier() is a very
> > > > > slow
> > > > > construct which introduces large delays and should be avoided whenever
> > > > > possible.
> > > >
> > > > I did build GENERIC.MP multiple times on a 4CPU sparc64 with the diff
> > > > below, without noticeable difference.
> > > >
> > > > I'm happy to hear from sceptical performance checkers :o)
> > >
> > > On a reasonably fast amd64 box, this increases GENERIC.MP make -j6 build
> > > time from
> > > ~3m06s to ~3m44s, which seems a bit much to me.
> >
> > Do you know if this is due to an increase of %spin time?
> >
> > > Replacing smr_barrier() with smr_flush() reduces the overhead to a couple
> > > of
> > > seconds, and it seems warranted here.
> >
> > Could you try the diff below that only call smr_barrier() for multi-
> > threaded processes with threads still in the list. I guess this also
> > answers guenther@'s question. The same could be done with smr_flush().
>
> I'm wondering if smr_grace_wait() could be improved on amd64, assuming
> SMT is disabled, by skipping offline CPUs.
This doesn't make much of a difference when using smr_barrier(), but with
smr_flush() it removes much of the overhead on this system with 8 of 16 cpus
online. Of course as Visa and Mark point out this is risky without more
guarantees about what offline cpus are actually doing. If we start using SMR
in ways that make the delay visible to user processes, it'll probably be worth
looking at.
>
> Index: kern/kern_smr.c
> ===
> RCS file: /cvs/src/sys/kern/kern_smr.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 kern_smr.c
> --- kern/kern_smr.c 3 Apr 2020 03:36:56 - 1.8
> +++ kern/kern_smr.c 2 Dec 2020 18:41:29 -
> @@ -142,7 +142,7 @@ smr_grace_wait(void)
>
> ci_start = curcpu();
> CPU_INFO_FOREACH(cii, ci) {
> - if (ci == ci_start)
> + if (ci == ci_start || !cpu_is_online(ci))
> continue;
> sched_peg_curproc(ci);
> }
>
Re: Use SMR_TAILQ for `ps_threads'
On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote: > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote: > > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote: > > > On 01/12/20(Tue) 15:30, Claudio Jeker wrote: > > > > [...] > > > > Did you run a make build with that smr_barrier() in it and checked that > > > > it > > > > does not cause a slow down? I am sceptical, smr_barrier() is a very slow > > > > construct which introduces large delays and should be avoided whenever > > > > possible. > > > > > > I did build GENERIC.MP multiple times on a 4CPU sparc64 with the diff > > > below, without noticeable difference. > > > > > > I'm happy to hear from sceptical performance checkers :o) > > > > On a reasonably fast amd64 box, this increases GENERIC.MP make -j6 build > > time from > > ~3m06s to ~3m44s, which seems a bit much to me. > > Do you know if this is due to an increase of %spin time? It actually decreased %spin, and the total system cpu time used during the build was decreased from around 6m30s to around 5m15, so I think it's mostly the effect of the delayed wakeup of the SMR thread in smr_dispatch(). There's also this: $ time sleep 1 0m01.11s real 0m00.00s user 0m00.00s system > > > Replacing smr_barrier() with smr_flush() reduces the overhead to a couple of > > seconds, and it seems warranted here. > > Could you try the diff below that only call smr_barrier() for multi- > threaded processes with threads still in the list. I guess this also > answers guenther@'s question. The same could be done with smr_flush(). This removes the overhead, more or less. Are we only looking at unlocking access to ps_threads from within a process (not the sysctl or ptrace stuff)? Otherwise this doesn't seem safe.
Re: [PATCH] Convert ddb_sysctl to sysctl_bounded_arr
On Mon, 30 Nov 2020 20:04:10 -0800
Greg Steuck wrote:
> Tested with a bunch of manual sysctl -w's.
>
> OK?
I'm not sure about this diff. I'm more likely to do
ddb{0}> set $radix = 0t2
and less likely to do
# sysctl ddb.radix=2
but you enforce the range check (radix in 8..16) only in sysctl,
not in ddb set.
If I do ddb set a bad value, then sysctl refuses to show the value:
# sysctl ddb.console=1
ddb.console: 0 -> 1
# sysctl ddb.trigger=1
Stopped at ddb_sysctl+0x114: ori r0,r0,0x0
ddb{0}> set $radix = 0t2
ddb{0}> c
ddb.trigger: 0 -> 1
# sysctl ddb.radix
sysctl: ddb.radix: Invalid argument
This diff might be better than doing nothing? I'm not sure. --George
> From 24ae202fd5d39c3c40c029fb878aa15eee33b709 Mon Sep 17 00:00:00 2001
> From: Greg Steuck
> Date: Mon, 30 Nov 2020 19:42:19 -0800
> Subject: [PATCH] Convert ddb_sysctl to sysctl_bounded_arr
>
> ---
> sys/ddb/db_usrreq.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git sys/ddb/db_usrreq.c sys/ddb/db_usrreq.c
> index 546822459ca..259e7b56a8f 100644
> --- sys/ddb/db_usrreq.c
> +++ sys/ddb/db_usrreq.c
> @@ -36,6 +36,14 @@
> int db_log = 1;
> int db_profile; /* Allow dynamic profiling */
>
> +const struct sysctl_bounded_args ddb_vars[] = {
> + { DBCTL_RADIX, _radix, 8, 16 },
> + { DBCTL_MAXWIDTH, _max_width, 0, INT_MAX },
> + { DBCTL_TABSTOP, _tab_stop_width, 1, 16 },
> + { DBCTL_MAXLINE, _max_line, 0, INT_MAX },
> + { DBCTL_LOG, _log, 0, 1 },
> +};
> +
> int
> ddb_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp,
> size_t newlen, struct proc *p)
> @@ -47,15 +55,6 @@ ddb_sysctl(int *name, u_int namelen, void *oldp, size_t
> *oldlenp, void *newp,
> return (ENOTDIR);
>
> switch (name[0]) {
> -
> - case DBCTL_RADIX:
> - return sysctl_int(oldp, oldlenp, newp, newlen, _radix);
> - case DBCTL_MAXWIDTH:
> - return sysctl_int(oldp, oldlenp, newp, newlen, _max_width);
> - case DBCTL_TABSTOP:
> - return sysctl_int(oldp, oldlenp, newp, newlen,
> _tab_stop_width);
> - case DBCTL_MAXLINE:
> - return sysctl_int(oldp, oldlenp, newp, newlen, _max_line);
> case DBCTL_PANIC:
> if (securelevel > 0)
> return (sysctl_int_lower(oldp, oldlenp, newp, newlen,
> @@ -86,8 +85,6 @@ ddb_sysctl(int *name, u_int namelen, void *oldp, size_t
> *oldlenp, void *newp,
> return (0);
> }
> break;
> - case DBCTL_LOG:
> - return (sysctl_int(oldp, oldlenp, newp, newlen, _log));
> case DBCTL_TRIGGER:
> if (newp && db_console) {
> struct process *pr = curproc->p_p;
> @@ -119,7 +116,8 @@ ddb_sysctl(int *name, u_int namelen, void *oldp, size_t
> *oldlenp, void *newp,
> break;
> #endif /* DDBPROF */
> default:
> - return (EOPNOTSUPP);
> + return (sysctl_bounded_arr(ddb_vars, nitems(ddb_vars), name,
> + namelen, oldp, oldlenp, newp, newlen));
> }
> /* NOTREACHED */
> }
> --
> 2.29.2
>
--
George Koehler
Re: PF synproxy should act on inbound packets only
Hello,
>
> Just a style nit. Other errors do not put stdin:1 in brackes. One
> line per error. In pf.conf the rule direction matters. What about
>
> stdin:1 warning: synproxy used for inbound rules only, ignored for outbound
>
thanks, I like your suggestion.
below is updated diff. The new diff also updates pf.conf(5) manpage.
thanks and
regards
sashan
8<---8<---8<--8<
diff --git a/sbin/pfctl/parse.y b/sbin/pfctl/parse.y
index f06171158cb..6c4dde1261f 100644
--- a/sbin/pfctl/parse.y
+++ b/sbin/pfctl/parse.y
@@ -4042,6 +4042,12 @@ rule_consistent(struct pf_rule *r)
"synproxy state or modulate state");
problems++;
}
+
+ if ((r->keep_state == PF_STATE_SYNPROXY) && (r->direction != PF_IN))
+ fprintf(stderr, "%s:%d: warning: "
+ "synproxy used for inbound rules only, "
+ "ignored for outbound\n", file->name, yylval.lineno);
+
if ((r->nat.addr.type != PF_ADDR_NONE ||
r->rdr.addr.type != PF_ADDR_NONE) &&
r->action != PF_MATCH && !r->keep_state) {
diff --git a/share/man/man5/pf.conf.5 b/share/man/man5/pf.conf.5
index e81198370c9..b77ba5d326c 100644
--- a/share/man/man5/pf.conf.5
+++ b/share/man/man5/pf.conf.5
@@ -2126,6 +2126,9 @@ will not work if
.Xr pf 4
operates on a
.Xr bridge 4 .
+Also
+.Cm synproxy state
+option acts on inbound packets only.
.Pp
Example:
.Bd -literal -offset indent
diff --git a/sys/net/pf.c b/sys/net/pf.c
index 823fdc22133..986ee57bff9 100644
--- a/sys/net/pf.c
+++ b/sys/net/pf.c
@@ -4161,7 +4161,7 @@ pf_create_state(struct pf_pdesc *pd, struct pf_rule *r,
struct pf_rule *a,
s->tag = tag;
}
if (pd->proto == IPPROTO_TCP && (th->th_flags & (TH_SYN|TH_ACK)) ==
- TH_SYN && r->keep_state == PF_STATE_SYNPROXY) {
+ TH_SYN && r->keep_state == PF_STATE_SYNPROXY && pd->dir == PF_IN) {
int rtid = pd->rdomain;
if (act->rtableid >= 0)
rtid = act->rtableid;
Re: tcpdump: Don't link to libl and remove reference to yydebug
On Thu, Dec 03, 2020 at 10:56:17PM +0300, Vitaliy Makkoveev wrote:
> > On 3 Dec 2020, at 13:20, Martin Vahlensieck
> > wrote:
> >
> > Hi
>
> Hi.
>
Hi
> >
> > This is unused. It has been in there since the import from NetBSD.
> > Their logs show that tcpgram.y and tcplex.l have been removed in 1995.
> > I am not sure what the policy is for the getopt(3) call: Should Y be
> > removed in the optstring as well (not done in this diff)?
> >
>
> There are two getopt(3) strings: one in privsep.c and one in tcpdump.c.
> “Y” should be removed from both. With this fix your diff is ok by me
> and I’ll commit it.
Done, updated diff below. Good catch with privsep.c.
Thanks.
Best,
Martin
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/tcpdump/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile21 Jun 2020 05:00:17 - 1.66
+++ Makefile4 Dec 2020 00:02:25 -
@@ -30,8 +30,8 @@ CFLAGS+=-I${.CURDIR}/../../lib/libpcap
CFLAGS+=-DCSLIP -DPPP -DHAVE_FDDI -DETHER_SERVICE -DHAVE_ETHER_NTOHOST -DINET6
-LDADD+=-lpcap -ll -lcrypto
-DPADD+=${LIBL} ${LIBPCAP} ${LIBCRYPTO}
+LDADD+=-lpcap -lcrypto
+DPADD+=${LIBPCAP} ${LIBCRYPTO}
SRCS= tcpdump.c addrtoname.c privsep.c privsep_fdpass.c privsep_pcap.c \
print-ether.c print-ip.c print-arp.c print-tcp.c print-udp.c \
Index: privsep.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/privsep.c,v
retrieving revision 1.54
diff -u -p -r1.54 privsep.c
--- privsep.c 28 Jun 2019 13:32:51 - 1.54
+++ privsep.c 4 Dec 2020 00:02:25 -
@@ -224,7 +224,7 @@ priv_exec(int argc, char *argv[])
/* parse the arguments for required options */
opterr = 0;
while ((i = getopt(argc, argv,
- "aB:c:D:deE:fF:i:lLnNOopPqr:s:StT:vw:xXy:Y")) != -1) {
+ "aB:c:D:deE:fF:i:lLnNOopPqr:s:StT:vw:xXy:")) != -1) {
switch (i) {
case 'n':
nflag++;
Index: tcpdump.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.c,v
retrieving revision 1.94
diff -u -p -r1.94 tcpdump.c
--- tcpdump.c 17 Aug 2020 06:29:29 - 1.94
+++ tcpdump.c 4 Dec 2020 00:02:26 -
@@ -232,7 +232,7 @@ main(int argc, char **argv)
opterr = 0;
while ((op = getopt(argc, argv,
- "AaB:c:D:deE:fF:i:IlLnNOopqr:s:StT:vw:xXy:Y")) != -1)
+ "AaB:c:D:deE:fF:i:IlLnNOopqr:s:StT:vw:xXy:")) != -1)
switch (op) {
case 'A':
@@ -392,15 +392,7 @@ main(int argc, char **argv)
case 'w':
WFileName = optarg;
break;
-#ifdef YYDEBUG
- case 'Y':
- {
- /* Undocumented flag */
- extern int yydebug;
- yydebug = 1;
- }
- break;
-#endif
+
case 'y':
i = pcap_datalink_name_to_val(optarg);
if (i < 0)
>
> > Best,
> >
> > Martin
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdump/Makefile,v
> > retrieving revision 1.66
> > diff -u -p -r1.66 Makefile
> > --- Makefile21 Jun 2020 05:00:17 - 1.66
> > +++ Makefile3 Dec 2020 10:15:35 -
> > @@ -30,8 +30,8 @@ CFLAGS+=-I${.CURDIR}/../../lib/libpcap
> >
> > CFLAGS+=-DCSLIP -DPPP -DHAVE_FDDI -DETHER_SERVICE -DHAVE_ETHER_NTOHOST
> > -DINET6
> >
> > -LDADD+=-lpcap -ll -lcrypto
> > -DPADD+=${LIBL} ${LIBPCAP} ${LIBCRYPTO}
> > +LDADD+=-lpcap -lcrypto
> > +DPADD+=${LIBPCAP} ${LIBCRYPTO}
> >
> > SRCS= tcpdump.c addrtoname.c privsep.c privsep_fdpass.c
> > privsep_pcap.c \
> > print-ether.c print-ip.c print-arp.c print-tcp.c print-udp.c \
> > Index: tcpdump.c
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.c,v
> > retrieving revision 1.94
> > diff -u -p -r1.94 tcpdump.c
> > --- tcpdump.c 17 Aug 2020 06:29:29 - 1.94
> > +++ tcpdump.c 3 Dec 2020 10:15:35 -
> > @@ -392,15 +392,7 @@ main(int argc, char **argv)
> > case 'w':
> > WFileName = optarg;
> > break;
> > -#ifdef YYDEBUG
> > - case 'Y':
> > - {
> > - /* Undocumented flag */
> > - extern int yydebug;
> > - yydebug = 1;
> > - }
> > - break;
> > -#endif
> > +
> > case 'y':
> > i = pcap_datalink_name_to_val(optarg);
> > if (i < 0)
> >
>
Re: Diff: Article Fixes
On Thu, Dec 03, 2020 at 02:20:23AM -0500, VARIK VALEFOR wrote: > Sir or Madam: > > This message contains some diffs which fix incorrect article usage, i.e., > the use of "a" where "an" should have been used, and vice-versa. > > "If you love something, and you set it free, and it doesn't come back, > you're a dumb-ass." > Varik "NOT A COMPUTER PROGRAMMER!!!" Valefor > hi. i committed your diff minus the libform/libmenu ones: those are 3rd party. check out the latest curses sources and submit a diff upstream if the fixes are still relevant. thanks! jmc > > > = BEGIN DIFFS = > diff --git a/lib/libagentx/agentx.3 b/lib/libagentx/agentx.3 > index f674c86f7cc..cdfd8490853 100644 > --- a/lib/libagentx/agentx.3 > +++ b/lib/libagentx/agentx.3 > @@ -586,7 +586,7 @@ The function type must also match the data type of > ??Other functions that can retrieve information from the agentx context are: > ??.Bl -tag -width Ds > ??.It Fn agentx_context_object_find > -Find a agentx_object created inside agentx_context > +Find an agentx_object created inside agentx_context > ??.Fa sac > ??based on > ??.Fa oid > > > > diff --git a/lib/libc/yp/yp_bind.3 b/lib/libc/yp/yp_bind.3 > index 5371b854e58..2ea4af6395f 100644 > --- a/lib/libc/yp/yp_bind.3 > +++ b/lib/libc/yp/yp_bind.3 > @@ -304,7 +304,7 @@ Returns a pointer to a NUL-terminated error string > that does not contain a > ??or > ??.Ql \en . > ??.It Fn ypprot_err > -Converts a YP protocol error code to a error code suitable for > +Converts a YP protocol error code to an error code suitable for > ??.Fn yperr_string . > ??.El > ??.Sh RETURN VALUES > > > > diff --git a/lib/libcrypto/man/BIO_ctrl.3 b/lib/libcrypto/man/BIO_ctrl.3 > index 98c78be1344..4f3b1337d64 100644 > --- a/lib/libcrypto/man/BIO_ctrl.3 > +++ b/lib/libcrypto/man/BIO_ctrl.3 > @@ -304,7 +304,7 @@ For example no current filter BIOs implement > ??but this may still succeed if the chain ends > ??in a FILE or file descriptor BIO. > ??.Pp > -Source/sink BIOs return an 0 if they do not recognize the > +Source/sink BIOs return a 0 if they do not recognize the > ??.Fn BIO_ctrl > ??operation. > ??.Sh SEE ALSO > > > > diff --git a/lib/libcrypto/man/EVP_EncryptInit.3 > b/lib/libcrypto/man/EVP_EncryptInit.3 > index 7f9428d174b..ac20f27831b 100644 > --- a/lib/libcrypto/man/EVP_EncryptInit.3 > +++ b/lib/libcrypto/man/EVP_EncryptInit.3 > @@ -1197,7 +1197,7 @@ openssl bf -in cipher.bin -K > 000102030405060708090A0B0C0D0E0F \e > ??.Ed > ??.Pp > ??General encryption, decryption function example using FILE I/O and AES128 > -with an 128-bit key: > +with a 128-bit key: > ??.Bd -literal > ??int > ??do_crypt(FILE *in, FILE *out, int do_encrypt) > > > > diff --git a/lib/libelf/elf.3 b/lib/libelf/elf.3 > index 3c238f2ea4f..6136c895f6f 100644 > --- a/lib/libelf/elf.3 > +++ b/lib/libelf/elf.3 > @@ -576,7 +576,7 @@ set by function > ??.Ss Error Handling > ??In case an error is encountered, these library functions set an > ??internal error number and signal the presence of the error by > -returning an special return value. > +returning a special return value. > ??The application can check the > ??current error number by calling > ??.Xr elf_errno 3 . > > > > diff --git a/lib/libform/form_driver.3 b/lib/libform/form_driver.3 > index 48d371abe8d..510f6c359fb 100644 > --- a/lib/libform/form_driver.3 > +++ b/lib/libform/form_driver.3 > @@ -263,7 +263,7 @@ a REQ_NEXT_PAGE is generated for a double-click and > ??a REQ_LAST_FIELD is generated for a triple-click. > ??.RE > ??.PP > -If you click at an field inside the display area of the form: > +If you click at a field inside the display area of the form: > ??.RS > ??.TP 3 > ??- > @@ -274,7 +274,7 @@ If you double-click a field, > ??the form cursor is positioned to that field > ??and \fBE_UNKNOWN_COMMAND\fR is returned. > ??This return value makes sense, > -because a double click usually means that an field-specific action should > +because a double click usually means that a field-specific action should > ??be returned. > ??It is exactly the purpose of this return value to signal that an > ??application specific command should be executed. > > > > diff --git a/lib/libform/form_fieldtype.3 b/lib/libform/form_fieldtype.3 > index b2956a41ed3..a6c4d6b4877 100644 > --- a/lib/libform/form_fieldtype.3 > +++ b/lib/libform/form_fieldtype.3 > @@ -89,7 +89,7 @@ argument into a single scalar value. > ??.PP > ??The function \fBlink_fieldtype\fR creates > ??a new field type from the two given types. > -They are connected by an logical 'OR'. > +They are connected by a logical 'OR'. > ??.PP > ??The form driver requests \fBREQ_NEXT_CHOICE\fR and > \fBREQ_PREV_CHOICE\fR assume > ??that the possible values of a field form an ordered set, and provide > the forms > > > > diff --git a/lib/libform/form_post.3 b/lib/libform/form_post.3 > index ca29a6a4698..56639c1d902 100644 > --- a/lib/libform/form_post.3 > +++ b/lib/libform/form_post.3
Re: amdgpu(4): use DRM_INFO instead of printf for printing compute unit info
Sure thing! Tracing it out, it seems to happen after the function psp_v11_0_ring_set_wptr is called, but I'm having trouble figuring out *why* the timing is messing it up. It also runs fine if any print statements are called before amdgpu_device_ip_init, however DRMDEBUG has to be disabled. It doesn't have issues with drm_msleep being called in place of kernel print statements either. The timeout error about the IB test only shows up about half the time. I've also tried increasing the timeout limit to see if that aided anything, but it still had the same error. This is the output using a vanilla, precompiled kernel: Dec 3 12:24:08 tabr /bsd: amdgpu0: VEGA20 60 CU rev 0x01 Dec 3 12:24:08 tabr /bsd: amdgpu0: 2560x1440, 32bpp Dec 3 12:24:08 tabr /bsd: wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0 Dec 3 12:24:08 tabr /bsd: wskbd1: connecting to wsdisplay0 Dec 3 12:24:08 tabr /bsd: wskbd2: connecting to wsdisplay0 Dec 3 12:24:08 tabr /bsd: wskbd3: connecting to wsdisplay0 Dec 3 12:24:08 tabr /bsd: wskbd4: connecting to wsdisplay0 Dec 3 12:24:08 tabr /bsd: wsdisplay0: screen 1-5 added (std, vt100 emulation) Dec 3 12:24:08 tabr /bsd: iwm0: hw rev 0x310, fw ver 34.3125811985.0, address 38:00:25:26:6d:f3 Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* [gfxhub0] no-retry page fault (src_id:0 ring:222 vmid:0 pasid:0, for process pid 0 thread pid 0) Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* in page starting at address 0x0066d000 from client 27 Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* VM_L2_PROTECTION_FAULT_STATUS:0x09BC Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* MORE_FAULTS: 0x0 Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* WALKER_ERROR: 0x6 Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* PERMISSION_FAULTS: 0xb Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* MAPPING_ERROR: 0x1 Dec 3 12:24:08 tabr /bsd: drm:pid38002:gmc_v9_0_process_interrupt *ERROR* RW: 0x0 Dec 3 12:24:08 tabr /bsd: [drm] *ERROR* IB test failed on gfx (-60). Dec 3 12:24:08 tabr /bsd: [drm] *ERROR* ib ring test failed (-60). If DRMDEBUG is set, this mess pops out: Dec 1 11:39:01 tabr /bsd: [drm] initializing kernel modesetting (VEGA20 0x1002:0x66AF 0x1002:0x081E 0xC1). Dec 1 11:39:01 tabr /bsd: [drm] register mmio base: 0x9A20 Dec 1 11:39:01 tabr /bsd: [drm] register mmio size: 524288 Dec 1 11:39:01 tabr /bsd: [drm] probing pcie caps for device 2:0:0 0x1002:0x14a1 = 3/e Dec 1 11:39:01 tabr /bsd: [drm] probing pcie width for device 2:0:0 0x1002:0x14a1 = 700d03 Dec 1 11:39:01 tabr /bsd: [drm] probing pcie caps for device 3:0:0 0x1002:0x66af = 3/e Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 0 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 1 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 2 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 3 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 4 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 5 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 6 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 7 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 8 Dec 1 11:39:01 tabr /bsd: [drm] add ip block number 9 Dec 1 11:39:01 tabr /bsd: [drm] ATOMBIOS detected Dec 1 11:39:01 tabr /bsd: ATOM BIOS: 113-D3600200-106 Dec 1 11:39:01 tabr /bsd: [drm] atom firmware requested 0kb fw 0kb drv Dec 1 11:39:01 tabr /bsd: [drm] Dec 1 11:39:01 tabr /bsd: [drm] psp_load == 'true' Dec 1 11:39:01 tabr /bsd: [drm] UVD(0) is enabled in VM mode Dec 1 11:39:01 tabr /bsd: [drm] UVD(1) is enabled in VM mode Dec 1 11:39:01 tabr /bsd: [drm] UVD(0) ENC is enabled in VM mode Dec 1 11:39:01 tabr /bsd: [drm] UVD(1) ENC is enabled in VM mode Dec 1 11:39:01 tabr /bsd: [drm] VCE enabled in VM mode Dec 1 11:39:01 tabr /bsd: [drm] HBM ECC is not presented. Dec 1 11:39:01 tabr /bsd: [drm] SRAM ECC is not presented. Dec 1 11:39:01 tabr /bsd: [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit Dec 1 11:39:01 tabr /bsd: drm: VRAM: 16368M 0x0080 - 0x0083FEFF (16368M used) Dec 1 11:39:01 tabr /bsd: drm: GART: 512M 0x - 0x1FFF Dec 1 11:39:01 tabr /bsd: drm: AGP: 267894784M 0x0084 - 0x Dec 1 11:39:01 tabr /bsd: [drm] Detected VRAM RAM=16368M, BAR=256M Dec 1 11:39:01 tabr /bsd: [drm] RAM width 4096bits HBM Dec 1 11:39:01 tabr /bsd: [TTM] Zone kernel: Available graphics memory: 33512110 KiB Dec 1 11:39:01 tabr /bsd: [TTM] Zone dma32: Available graphics memory: 2097152 KiB Dec 1 11:39:01 tabr /bsd: [TTM] Initializing pool allocator Dec 1 11:39:01 tabr /bsd: [drm] memory training does not support! Dec 1 11:39:01 tabr /bsd: [drm] amdgpu: 16368M of VRAM memory ready Dec 1 11:39:01 tabr /bsd: [drm]
bgpd show status of set tables
The use of roa-set, prefix-set and as-set is fairly common in bgpd.
Still sometimes it is not exactly clear how old the data in those tables
is. This diff is a first step at inproving inspection by adding
bgpctl show sets
Sample output is:
Type Name #IPv4 #Ipv6 #ASnum Last Change
ROARPKI ROA158810 26257 -00:00:07
ASNUM asns_AS15600 - - 2601:19:10
PREFIX p4_AS21040 8 0 -01:19:10
I just did a bgpctl reload with a new roa table (generated by rpki-client)
but the as-set and prefix-set did not change during this reload.
The output also includes the number of entries in the tables but in the
case of roa-set the number of unique prefixes is counted. So the number is
a bit under the count from rpki-client because e.g.
1.32.219.0/24 source-as 4842
1.32.219.0/24 source-as 138570
are counted as 1 right now (instead of 2 prefixes).
More statistics can be added if their calculation is easy.
--
:wq Claudio
PS: apply diff in /usr/src/usr.sbin
Index: bgpd/bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.405
diff -u -p -r1.405 bgpd.h
--- bgpd/bgpd.h 5 Nov 2020 11:52:59 - 1.405
+++ bgpd/bgpd.h 3 Dec 2020 20:15:30 -
@@ -254,12 +254,15 @@ struct trie_head {
struct tentry_v6*root_v6;
int match_default_v4;
int match_default_v6;
+ size_t v4_cnt;
+ size_t v6_cnt;
};
struct rde_prefixset {
charname[SET_NAME_LEN];
struct trie_headth;
SIMPLEQ_ENTRY(rde_prefixset)entry;
+ time_t lastchange;
int dirty;
};
SIMPLEQ_HEAD(rde_prefixset_head, rde_prefixset);
@@ -465,6 +468,7 @@ enum imsg_type {
IMSG_CTL_SHOW_TIMER,
IMSG_CTL_LOG_VERBOSE,
IMSG_CTL_SHOW_FIB_TABLES,
+ IMSG_CTL_SHOW_SET,
IMSG_CTL_TERMINATE,
IMSG_NETWORK_ADD,
IMSG_NETWORK_ASPATH,
@@ -696,6 +700,20 @@ struct ctl_show_nexthop {
u_int8_tkrvalid;
};
+struct ctl_show_set {
+ charname[SET_NAME_LEN];
+ time_t lastchange;
+ size_t v4_cnt;
+ size_t v6_cnt;
+ size_t as_cnt;
+ enum {
+ ASNUM_SET,
+ PREFIX_SET,
+ ORIGIN_SET,
+ ROA_SET,
+ } type;
+};
+
struct ctl_neighbor {
struct bgpd_addraddr;
chardescr[PEER_DESCR_LEN];
@@ -1049,6 +1067,7 @@ struct as_set {
char name[SET_NAME_LEN];
SIMPLEQ_ENTRY(as_set)entry;
struct set_table*set;
+ time_t lastchange;
int dirty;
};
@@ -1283,6 +1302,7 @@ void set_prep(struct set_table *);
void *set_match(const struct set_table *, u_int32_t);
int set_equal(const struct set_table *,
const struct set_table *);
+size_t set_nmemb(const struct set_table *);
/* rde_trie.c */
inttrie_add(struct trie_head *, struct bgpd_addr *, u_int8_t, u_int8_t,
Index: bgpd/control.c
===
RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
retrieving revision 1.101
diff -u -p -r1.101 control.c
--- bgpd/control.c 5 Nov 2020 11:28:11 - 1.101
+++ bgpd/control.c 3 Dec 2020 17:07:58 -
@@ -280,6 +280,7 @@ control_dispatch_msg(struct pollfd *pfd,
case IMSG_CTL_SHOW_NETWORK:
case IMSG_CTL_SHOW_RIB:
case IMSG_CTL_SHOW_RIB_PREFIX:
+ case IMSG_CTL_SHOW_SET:
break;
default:
/* clear imsg type to prevent processing */
@@ -496,6 +497,7 @@ control_dispatch_msg(struct pollfd *pfd,
c->terminate = 1;
/* FALLTHROUGH */
case IMSG_CTL_SHOW_RIB_MEM:
+ case IMSG_CTL_SHOW_SET:
c->ibuf.pid = imsg.hdr.pid;
imsg_ctl_rde(imsg.hdr.type, imsg.hdr.pid,
imsg.data, imsg.hdr.len - IMSG_HEADER_SIZE);
Index: bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.506
diff -u -p -r1.506 rde.c
--- bgpd/rde.c 5 Nov 2020 14:44:59 - 1.506
+++ bgpd/rde.c 3 Dec
Diff: Article Fixes
Sir or Madam: This message contains some diffs which fix incorrect article usage, i.e., the use of "a" where "an" should have been used, and vice-versa. "If you love something, and you set it free, and it doesn't come back, you're a dumb-ass." Varik "NOT A COMPUTER PROGRAMMER!!!" Valefor = BEGIN DIFFS = diff --git a/lib/libagentx/agentx.3 b/lib/libagentx/agentx.3 index f674c86f7cc..cdfd8490853 100644 --- a/lib/libagentx/agentx.3 +++ b/lib/libagentx/agentx.3 @@ -586,7 +586,7 @@ The function type must also match the data type of Other functions that can retrieve information from the agentx context are: .Bl -tag -width Ds .It Fn agentx_context_object_find -Find a agentx_object created inside agentx_context +Find an agentx_object created inside agentx_context .Fa sac based on .Fa oid diff --git a/lib/libc/yp/yp_bind.3 b/lib/libc/yp/yp_bind.3 index 5371b854e58..2ea4af6395f 100644 --- a/lib/libc/yp/yp_bind.3 +++ b/lib/libc/yp/yp_bind.3 @@ -304,7 +304,7 @@ Returns a pointer to a NUL-terminated error string that does not contain a or .Ql \en . .It Fn ypprot_err -Converts a YP protocol error code to a error code suitable for +Converts a YP protocol error code to an error code suitable for .Fn yperr_string . .El .Sh RETURN VALUES diff --git a/lib/libcrypto/man/BIO_ctrl.3 b/lib/libcrypto/man/BIO_ctrl.3 index 98c78be1344..4f3b1337d64 100644 --- a/lib/libcrypto/man/BIO_ctrl.3 +++ b/lib/libcrypto/man/BIO_ctrl.3 @@ -304,7 +304,7 @@ For example no current filter BIOs implement but this may still succeed if the chain ends in a FILE or file descriptor BIO. .Pp -Source/sink BIOs return an 0 if they do not recognize the +Source/sink BIOs return a 0 if they do not recognize the .Fn BIO_ctrl operation. .Sh SEE ALSO diff --git a/lib/libcrypto/man/EVP_EncryptInit.3 b/lib/libcrypto/man/EVP_EncryptInit.3 index 7f9428d174b..ac20f27831b 100644 --- a/lib/libcrypto/man/EVP_EncryptInit.3 +++ b/lib/libcrypto/man/EVP_EncryptInit.3 @@ -1197,7 +1197,7 @@ openssl bf -in cipher.bin -K 000102030405060708090A0B0C0D0E0F \e .Ed .Pp General encryption, decryption function example using FILE I/O and AES128 -with an 128-bit key: +with a 128-bit key: .Bd -literal int do_crypt(FILE *in, FILE *out, int do_encrypt) diff --git a/lib/libelf/elf.3 b/lib/libelf/elf.3 index 3c238f2ea4f..6136c895f6f 100644 --- a/lib/libelf/elf.3 +++ b/lib/libelf/elf.3 @@ -576,7 +576,7 @@ set by function .Ss Error Handling In case an error is encountered, these library functions set an internal error number and signal the presence of the error by -returning an special return value. +returning a special return value. The application can check the current error number by calling .Xr elf_errno 3 . diff --git a/lib/libform/form_driver.3 b/lib/libform/form_driver.3 index 48d371abe8d..510f6c359fb 100644 --- a/lib/libform/form_driver.3 +++ b/lib/libform/form_driver.3 @@ -263,7 +263,7 @@ a REQ_NEXT_PAGE is generated for a double-click and a REQ_LAST_FIELD is generated for a triple-click. .RE .PP -If you click at an field inside the display area of the form: +If you click at a field inside the display area of the form: .RS .TP 3 - @@ -274,7 +274,7 @@ If you double-click a field, the form cursor is positioned to that field and \fBE_UNKNOWN_COMMAND\fR is returned. This return value makes sense, -because a double click usually means that an field-specific action should +because a double click usually means that a field-specific action should be returned. It is exactly the purpose of this return value to signal that an application specific command should be executed. diff --git a/lib/libform/form_fieldtype.3 b/lib/libform/form_fieldtype.3 index b2956a41ed3..a6c4d6b4877 100644 --- a/lib/libform/form_fieldtype.3 +++ b/lib/libform/form_fieldtype.3 @@ -89,7 +89,7 @@ argument into a single scalar value. .PP The function \fBlink_fieldtype\fR creates a new field type from the two given types. -They are connected by an logical 'OR'. +They are connected by a logical 'OR'. .PP The form driver requests \fBREQ_NEXT_CHOICE\fR and \fBREQ_PREV_CHOICE\fR assume that the possible values of a field form an ordered set, and provide the forms diff --git a/lib/libform/form_post.3 b/lib/libform/form_post.3 index ca29a6a4698..56639c1d902 100644 --- a/lib/libform/form_post.3 +++ b/lib/libform/form_post.3 @@ -44,7 +44,7 @@ int unpost_form(FORM *form); .SH DESCRIPTION The function \fBpost_form\fR displays a form to its associated subwindow. To trigger physical display of the subwindow, use \fBrefresh\fR or some equivalent -\fBcurses\fR routine (the implicit \fBdoupdate\fR triggered by an \fBcurses\fR +\fBcurses\fR routine (the implicit \fBdoupdate\fR triggered by a \fBcurses\fR input request will do). .PP The function \fBunpost_form\fR erases form from its associated subwindow. diff --git a/lib/libmenu/menu_driver.3 b/lib/libmenu/menu_driver.3 index 5b9bb140fb1..16b404ada0c 100644 ---
Re: tcpdump: Don't link to libl and remove reference to yydebug
> On 3 Dec 2020, at 13:20, Martin Vahlensieck
> wrote:
>
> Hi
Hi.
>
> This is unused. It has been in there since the import from NetBSD.
> Their logs show that tcpgram.y and tcplex.l have been removed in 1995.
> I am not sure what the policy is for the getopt(3) call: Should Y be
> removed in the optstring as well (not done in this diff)?
>
There are two getopt(3) strings: one in privsep.c and one in tcpdump.c.
“Y” should be removed from both. With this fix your diff is ok by me
and I’ll commit it.
> Best,
>
> Martin
>
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile 21 Jun 2020 05:00:17 - 1.66
> +++ Makefile 3 Dec 2020 10:15:35 -
> @@ -30,8 +30,8 @@ CFLAGS+=-I${.CURDIR}/../../lib/libpcap
>
> CFLAGS+=-DCSLIP -DPPP -DHAVE_FDDI -DETHER_SERVICE -DHAVE_ETHER_NTOHOST -DINET6
>
> -LDADD+= -lpcap -ll -lcrypto
> -DPADD+= ${LIBL} ${LIBPCAP} ${LIBCRYPTO}
> +LDADD+= -lpcap -lcrypto
> +DPADD+= ${LIBPCAP} ${LIBCRYPTO}
>
> SRCS= tcpdump.c addrtoname.c privsep.c privsep_fdpass.c privsep_pcap.c \
> print-ether.c print-ip.c print-arp.c print-tcp.c print-udp.c \
> Index: tcpdump.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 tcpdump.c
> --- tcpdump.c 17 Aug 2020 06:29:29 - 1.94
> +++ tcpdump.c 3 Dec 2020 10:15:35 -
> @@ -392,15 +392,7 @@ main(int argc, char **argv)
> case 'w':
> WFileName = optarg;
> break;
> -#ifdef YYDEBUG
> - case 'Y':
> - {
> - /* Undocumented flag */
> - extern int yydebug;
> - yydebug = 1;
> - }
> - break;
> -#endif
> +
> case 'y':
> i = pcap_datalink_name_to_val(optarg);
> if (i < 0)
>
Re: PF synproxy should act on inbound packets only
On Wed, Dec 02, 2020 at 12:43:28AM +0100, Alexandr Nedvedicky wrote:
> the fix is to apply synproxy action on inbound packets only. Diff below
> does that exactly. Furthermore it also makes pfctl(8) to emit warning,
> when synproxy is being used in outbound/unbound rule:
Sounds reasonable.
> lumpy$ echo 'pass proto tcp from any to any port = 80 synproxy state'
> |./pfctl -nf -
> warning (stdin:1): synproxy acts on inbound packets only
> synproxy action is ignored for outbound packets
Just a style nit. Other errors do not put stdin:1 in brackes. One
line per error. In pf.conf the rule direction matters. What about
stdin:1 warning: synproxy used for inbound rules only, ignored for outbound
> OK?
OK bluhm@
> 8<---8<---8<--8<
> diff --git a/sbin/pfctl/parse.y b/sbin/pfctl/parse.y
> index f06171158cb..d052b5b9a0e 100644
> --- a/sbin/pfctl/parse.y
> +++ b/sbin/pfctl/parse.y
> @@ -4042,6 +4042,13 @@ rule_consistent(struct pf_rule *r)
> "synproxy state or modulate state");
> problems++;
> }
> +
> + if ((r->keep_state == PF_STATE_SYNPROXY) && (r->direction != PF_IN))
> + fprintf(stderr, "warning (%s:%d): "
> + "synproxy acts on inbound packets only\n"
> + "synproxy action is ignored for outbound packets\n",
> + file->name, yylval.lineno);
> +
> if ((r->nat.addr.type != PF_ADDR_NONE ||
> r->rdr.addr.type != PF_ADDR_NONE) &&
> r->action != PF_MATCH && !r->keep_state) {
> diff --git a/sys/net/pf.c b/sys/net/pf.c
> index 823fdc22133..986ee57bff9 100644
> --- a/sys/net/pf.c
> +++ b/sys/net/pf.c
> @@ -4161,7 +4161,7 @@ pf_create_state(struct pf_pdesc *pd, struct pf_rule *r,
> struct pf_rule *a,
> s->tag = tag;
> }
> if (pd->proto == IPPROTO_TCP && (th->th_flags & (TH_SYN|TH_ACK)) ==
> - TH_SYN && r->keep_state == PF_STATE_SYNPROXY) {
> + TH_SYN && r->keep_state == PF_STATE_SYNPROXY && pd->dir == PF_IN) {
> int rtid = pd->rdomain;
> if (act->rtableid >= 0)
> rtid = act->rtableid;
Re: Use SMR_TAILQ for `ps_threads'
> Date: Wed, 2 Dec 2020 19:44:02 +0100
> From: Anton Lindqvist
>
> On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> > On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> > > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > > > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > > > [...]
> > > > > Did you run a make build with that smr_barrier() in it and checked
> > > > > that it
> > > > > does not cause a slow down? I am sceptical, smr_barrier() is a very
> > > > > slow
> > > > > construct which introduces large delays and should be avoided whenever
> > > > > possible.
> > > >
> > > > I did build GENERIC.MP multiple times on a 4CPU sparc64 with the diff
> > > > below, without noticeable difference.
> > > >
> > > > I'm happy to hear from sceptical performance checkers :o)
> > >
> > > On a reasonably fast amd64 box, this increases GENERIC.MP make -j6 build
> > > time from
> > > ~3m06s to ~3m44s, which seems a bit much to me.
> >
> > Do you know if this is due to an increase of %spin time?
> >
> > > Replacing smr_barrier() with smr_flush() reduces the overhead to a couple
> > > of
> > > seconds, and it seems warranted here.
> >
> > Could you try the diff below that only call smr_barrier() for multi-
> > threaded processes with threads still in the list. I guess this also
> > answers guenther@'s question. The same could be done with smr_flush().
>
> I'm wondering if smr_grace_wait() could be improved on amd64, assuming
> SMT is disabled, by skipping offline CPUs.
I think this would come back to bite us at some point.
> Index: kern/kern_smr.c
> ===
> RCS file: /cvs/src/sys/kern/kern_smr.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 kern_smr.c
> --- kern/kern_smr.c 3 Apr 2020 03:36:56 - 1.8
> +++ kern/kern_smr.c 2 Dec 2020 18:41:29 -
> @@ -142,7 +142,7 @@ smr_grace_wait(void)
>
> ci_start = curcpu();
> CPU_INFO_FOREACH(cii, ci) {
> - if (ci == ci_start)
> + if (ci == ci_start || !cpu_is_online(ci))
> continue;
> sched_peg_curproc(ci);
> }
>
>
Re: unwind(8): handle large answers differently
Anyone?
While I could volunteer all y'all for testing that seems a bit silly.
I'd rather have someone to read the diff because
- The tricky cases will be very rare to hit in normal operations,
DNS answers are just not that big.
- I'd like to hear that this is actually a good pattern to do this and
I'm not completely off the trail
Eventually I will put it in though, to make progress.
Thanks.
On Thu, Nov 19, 2020 at 03:59:03PM +0100, Florian Obser wrote:
> On Fri, Nov 13, 2020 at 05:53:53PM +0100, Florian Obser wrote:
> > The recent fix for handling large (about 16k) answers in unwind has
> > the downside that we are now always copying at least 16k per answer
> > between the resolver and frontend process.
> > That seems wasteful.
> >
> > This re-arranges things to only copy what its needed.
> >
> > Tests, OKs?
> >
>
> Anyone? So far I had one (1) test report.
>
> diff --git frontend.c frontend.c
> index 8adbb07219b..74715087c5f 100644
> --- frontend.c
> +++ frontend.c
> @@ -86,7 +86,8 @@ struct pending_query {
> int fd;
> int bogus;
> int rcode_override;
> - ssize_t answer_len;
> + int answer_len;
> + int received;
> uint8_t *answer;
> };
>
> @@ -424,10 +425,7 @@ frontend_dispatch_resolver(int fd, short event, void
> *bula)
> struct imsgev *iev = bula;
> struct imsgbuf *ibuf = >ibuf;
> struct imsg imsg;
> - struct query_imsg *query_imsg;
> - struct answer_imsg *answer_imsg;
> int n, shut = 0, chg;
> - uint8_t *p;
>
> if (event & EV_READ) {
> if ((n = imsg_read(ibuf)) == -1 && errno != EAGAIN)
> @@ -449,45 +447,30 @@ frontend_dispatch_resolver(int fd, short event, void
> *bula)
> break;
>
> switch (imsg.hdr.type) {
> - case IMSG_ANSWER_HEADER:
> - if (IMSG_DATA_SIZE(imsg) != sizeof(*query_imsg))
> - fatalx("%s: IMSG_ANSWER_HEADER wrong length: "
> - "%lu", __func__, IMSG_DATA_SIZE(imsg));
> - query_imsg = (struct query_imsg *)imsg.data;
> - if ((pq = find_pending_query(query_imsg->id)) ==
> - NULL) {
> - log_warnx("cannot find pending query %llu",
> - query_imsg->id);
> - break;
> - }
> - if (query_imsg->err) {
> - send_answer(pq);
> - pq = NULL;
> - break;
> - }
> - pq->bogus = query_imsg->bogus;
> - break;
> - case IMSG_ANSWER:
> - if (IMSG_DATA_SIZE(imsg) != sizeof(*answer_imsg))
> + case IMSG_ANSWER: {
> + struct answer_header*answer_header;
> + int data_len;
> + uint8_t *data;
> +
> + if (IMSG_DATA_SIZE(imsg) < sizeof(*answer_header))
> fatalx("%s: IMSG_ANSWER wrong length: "
> "%lu", __func__, IMSG_DATA_SIZE(imsg));
> - answer_imsg = (struct answer_imsg *)imsg.data;
> - if ((pq = find_pending_query(answer_imsg->id)) ==
> + answer_header = (struct answer_header *)imsg.data;
> + data = (uint8_t *)imsg.data + sizeof(*answer_header);
> + if (answer_header->answer_len > 65535)
> + fatalx("%s: IMSG_ANSWER answer too big: %d",
> + __func__, answer_header->answer_len);
> + data_len = IMSG_DATA_SIZE(imsg) -
> + sizeof(*answer_header);
> +
> + if ((pq = find_pending_query(answer_header->id)) ==
> NULL) {
> - log_warnx("cannot find pending query %llu",
> - answer_imsg->id);
> + log_warnx("%s: cannot find pending query %llu",
> + __func__, answer_header->id);
> break;
> }
>
> - p = realloc(pq->answer, pq->answer_len +
> - answer_imsg->len);
> -
> - if (p != NULL) {
> - pq->answer = p;
> - memcpy(pq->answer + pq->answer_len,
> -
Small optimization to smr_grace_wait()
Here is a small optimization to SMR's naive grace period mechanism.
It makes use of the fact that some CPUs may cross a quiescent state
independently while the SMR thread is running smr_grace_wait().
Such CPUs can be skipped.
Index: kern/kern_smr.c
===
RCS file: src/sys/kern/kern_smr.c,v
retrieving revision 1.8
diff -u -p -r1.8 kern_smr.c
--- kern/kern_smr.c 3 Apr 2020 03:36:56 - 1.8
+++ kern/kern_smr.c 3 Dec 2020 17:05:22 -
@@ -41,6 +41,7 @@ struct smr_entry_list smr_deferred;
struct timeout smr_wakeup_tmo;
unsigned int smr_expedite;
unsigned int smr_ndeferred;
+unsigned char smr_grace_period;
#ifdef WITNESS
static const char smr_lock_name[] = "smr";
@@ -131,20 +132,27 @@ smr_thread(void *arg)
}
/*
- * Block until all CPUs have crossed quiescent state.
+ * Announce next grace period and wait until all CPUs have entered it
+ * by crossing quiescent state.
*/
void
smr_grace_wait(void)
{
#ifdef MULTIPROCESSOR
CPU_INFO_ITERATOR cii;
- struct cpu_info *ci, *ci_start;
+ struct cpu_info *ci;
+ unsigned char smrgp;
+
+ smrgp = READ_ONCE(smr_grace_period) + 1;
+ WRITE_ONCE(smr_grace_period, smrgp);
+
+ curcpu()->ci_schedstate.spc_smrgp = smrgp;
- ci_start = curcpu();
CPU_INFO_FOREACH(cii, ci) {
- if (ci == ci_start)
+ if (READ_ONCE(ci->ci_schedstate.spc_smrgp) == smrgp)
continue;
sched_peg_curproc(ci);
+ KASSERT(ci->ci_schedstate.spc_smrgp == smrgp);
}
atomic_clearbits_int(>p_flag, P_CPUPEG);
#endif /* MULTIPROCESSOR */
@@ -209,11 +217,23 @@ void
smr_idle(void)
{
struct schedstate_percpu *spc = ()->ci_schedstate;
+ unsigned char smrgp;
SMR_ASSERT_NONCRITICAL();
if (spc->spc_ndeferred > 0)
smr_dispatch(spc);
+
+ /*
+* Update this CPU's view of the system's grace period.
+* The update must become visible after any preceding reads
+* of SMR-protected data.
+*/
+ smrgp = READ_ONCE(smr_grace_period);
+ if (__predict_false(spc->spc_smrgp != smrgp)) {
+ membar_exit();
+ WRITE_ONCE(spc->spc_smrgp, smrgp);
+ }
}
void
Index: sys/sched.h
===
RCS file: src/sys/sys/sched.h,v
retrieving revision 1.56
diff -u -p -r1.56 sched.h
--- sys/sched.h 21 Oct 2019 10:24:01 - 1.56
+++ sys/sched.h 3 Dec 2020 17:05:22 -
@@ -119,6 +119,7 @@ struct schedstate_percpu {
u_int spc_smrdepth; /* level of smr nesting */
u_char spc_smrexpedite; /* if set, dispatch smr entries
* without delay */
+ u_char spc_smrgp; /* this CPU's view of grace period */
};
struct cpustats {
Re: rpki-client: use strndup instead of malloc + memcpy
On Thu, Dec 03, 2020 at 03:48:00PM +0100, Christian Weisgerber wrote: > Claudio Jeker: > > > In tal_parse() use strndup() to create the tal descr instead of the more > > complex malloc, memcpy version. Result is the same but the strndup version > > is a lot nicer. > > Yes, but... > > > --- tal.c 11 Oct 2020 12:39:25 - 1.22 > > +++ tal.c 3 Dec 2020 12:00:25 - > > @@ -198,10 +198,8 @@ tal_parse(const char *fn, char *buf) > > dlen = strlen(d); > > if (strcasecmp(d + dlen - 4, ".tal") == 0) > > dlen -= 4; > > That looks like a potential out-of-bounds access. Are we guaranteed > that dlen >= 4 here? Indeed, that strcasecmp should only be done if dlen > 4. I'll change that. > > - if ((p->descr = malloc(dlen + 1)) == NULL) > > + if ((p->descr = strndup(d, dlen)) == NULL) > > err(1, NULL); > > - memcpy(p->descr, d, dlen); > > - p->descr[dlen] = '\0'; > > > > return p; > > } > > ok -- :wq Claudio
postgresql 12 - could not open shared memory segment
Hello - I am using postgresql 12 on OpenBSD 6.8. After a while of running, postgresql starts throwing out errors: 2020-12-03 08:18:35.052 CST [60288] ERROR: could not open shared memory segment "/PostgreSQL.1780529043": No such file or directory 2020-12-03 08:18:35.052 CST [40083] ERROR: could not open shared memory segment "/PostgreSQL.1780529043": No such file or directory 2020-12-03 08:18:35.052 CST [53517] ERROR: could not open shared memory segment "/PostgreSQL.1780529043": No such file or directory 2020-12-03 08:18:35.052 CST [53517] CONTEXT: parallel worker 2020-12-03 08:18:35.054 CST [47581] LOG: background worker "parallel worker" (PID 40083) exited with exit code 1 2020-12-03 08:18:35.055 CST [47581] LOG: background worker "parallel worker" (PID 60288) exited with exit code 1 2020-12-03 08:24:19.583 CST [53517] WARNING: could not remove shared memory segment "/PostgreSQL.1222503421": No such file or directory 2020-12-03 08:24:19.584 CST [31517] WARNING: could not remove shared memory segment "/PostgreSQL.19516083": No such file or directory 2020-12-03 08:24:19.584 CST [53517] WARNING: could not remove shared memory segment "/PostgreSQL.1780529043": No such file or directory in postgresql.conf, dynamic_shared_memory_type is set to posix. /etc/sysctl.conf kern.seminfo.semmni=256 kern.seminfo.semmns=2048 I am wondering there is something I need to adjust... or if anyone has run into this before? Does anyone have any pointers on what to look for? Thanks - David
Re: rpki-client: use strndup instead of malloc + memcpy
Claudio Jeker: > In tal_parse() use strndup() to create the tal descr instead of the more > complex malloc, memcpy version. Result is the same but the strndup version > is a lot nicer. Yes, but... > --- tal.c 11 Oct 2020 12:39:25 - 1.22 > +++ tal.c 3 Dec 2020 12:00:25 - > @@ -198,10 +198,8 @@ tal_parse(const char *fn, char *buf) > dlen = strlen(d); > if (strcasecmp(d + dlen - 4, ".tal") == 0) > dlen -= 4; That looks like a potential out-of-bounds access. Are we guaranteed that dlen >= 4 here? > - if ((p->descr = malloc(dlen + 1)) == NULL) > + if ((p->descr = strndup(d, dlen)) == NULL) > err(1, NULL); > - memcpy(p->descr, d, dlen); > - p->descr[dlen] = '\0'; > > return p; > } ok -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Use SMR_TAILQ for `ps_threads'
On Wed, Dec 02, 2020 at 07:44:02PM +0100, Anton Lindqvist wrote:
> I'm wondering if smr_grace_wait() could be improved on amd64, assuming
> SMT is disabled, by skipping offline CPUs.
>
> Index: kern/kern_smr.c
> ===
> RCS file: /cvs/src/sys/kern/kern_smr.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 kern_smr.c
> --- kern/kern_smr.c 3 Apr 2020 03:36:56 - 1.8
> +++ kern/kern_smr.c 2 Dec 2020 18:41:29 -
> @@ -142,7 +142,7 @@ smr_grace_wait(void)
>
> ci_start = curcpu();
> CPU_INFO_FOREACH(cii, ci) {
> - if (ci == ci_start)
> + if (ci == ci_start || !cpu_is_online(ci))
> continue;
> sched_peg_curproc(ci);
> }
That is not safe. The code should coordinate with switching of hw.smt.
Also, the CPUs that are offline because of hw.smt are not totally
inactive. They might still access SMR-protected data as a result of
interrupts for example.
Re: Better overflow check in bgpd
On Wed, Dec 02, 2020 at 12:19:11PM +0100, Claudio Jeker wrote:
> The overflow check for the relative metric adjustments of filtersets
> assumes a certain overflow behaviour of signed integers. I think it is
> better to write this in a way that does not involve an overflow.
>
Here a small follow up. The underflow check can be adjusted to be similar
to the overflow check which makes my OCD happy.
OK?
--
:wq Claudio
Index: rde_filter.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v
retrieving revision 1.125
diff -u -p -r1.125 rde_filter.c
--- rde_filter.c3 Dec 2020 11:53:34 - 1.125
+++ rde_filter.c3 Dec 2020 11:58:58 -
@@ -55,8 +55,8 @@ rde_apply_set(struct filter_set_head *sh
state->aspath.lpref +=
set->action.relative;
} else {
- if ((u_int32_t)-set->action.relative >
- state->aspath.lpref)
+ if (state->aspath.lpref <
+ 0U - set->action.relative)
state->aspath.lpref = 0;
else
state->aspath.lpref +=
@@ -77,8 +77,8 @@ rde_apply_set(struct filter_set_head *sh
state->aspath.med +=
set->action.relative;
} else {
- if ((u_int32_t)-set->action.relative >
- state->aspath.med)
+ if (state->aspath.med <
+ 0U - set->action.relative)
state->aspath.med = 0;
else
state->aspath.med +=
@@ -97,8 +97,8 @@ rde_apply_set(struct filter_set_head *sh
state->aspath.weight +=
set->action.relative;
} else {
- if ((u_int32_t)-set->action.relative >
- state->aspath.weight)
+ if (state->aspath.weight <
+ 0U - set->action.relative)
state->aspath.weight = 0;
else
state->aspath.weight +=
rpki-client refactor some path building
Use asprintf with %.*s to construct the path based on the mft file
location and the filename of the referenced file.
Since the * field in printf(3) is expecting an int type, typecast the
ptrdiff_t to an int. Add an assert check to make sure there is no
overflow. Also do the same overflow check in mft.c where the same idiom is
used.
Maybe some PATH_MAX checks should be placed in the mft parser.
--
:wq Claudio
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.85
diff -u -p -r1.85 main.c
--- main.c 2 Dec 2020 15:31:15 - 1.85
+++ main.c 3 Dec 2020 12:25:24 -
@@ -451,23 +451,16 @@ static void
queue_add_from_mft(int fd, struct entityq *q, const char *mft,
const struct mftfile *file, enum rtype type, size_t *eid)
{
- size_t sz;
char*cp, *nfile;
/* Construct local path from filename. */
-
- sz = strlen(file->file) + strlen(mft);
- if ((nfile = calloc(sz + 1, 1)) == NULL)
- err(1, "calloc");
-
/* We know this is host/module/... */
- strlcpy(nfile, mft, sz + 1);
- cp = strrchr(nfile, '/');
+ cp = strrchr(mft, '/');
assert(cp != NULL);
- cp++;
- *cp = '\0';
- strlcat(nfile, file->file, sz + 1);
+ assert(cp - mft < INT_MAX);
+ if (asprintf(, "%.*s/%s", (int)(cp - mft), mft, file->file) == -1)
+ err(1, "asprintf");
/*
* Since we're from the same directory as the MFT file, we know
Index: mft.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/mft.c,v
retrieving revision 1.19
diff -u -p -r1.19 mft.c
--- mft.c 6 Nov 2020 04:22:18 - 1.19
+++ mft.c 3 Dec 2020 12:37:15 -
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -457,6 +458,7 @@ mft_validfilehash(const char *fn, const
/* Check hash of file now, but first build path for it */
cp = strrchr(fn, '/');
assert(cp != NULL);
+ assert(cp - fn < INT_MAX);
if (asprintf(, "%.*s/%s", (int)(cp - fn), fn, m->file) == -1)
err(1, "asprintf");
Re: hvn(4), hyperv(4): tsleep(9) -> tsleep_nsec(9)
Hello Scott, I tested this with Hyper-V on Windows 10 and it works fine so far. Regards, Andre OpenBSD 6.8-current (GENERIC.MP) #6: Thu Dec 3 12:54:46 CET 2020 an...@dev.stoe.be:/sys/arch/amd64/compile/GENERIC.MP real mem = 4278124544 (4079MB) avail mem = 4133171200 (3941MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf93d0 (338 entries) bios0: vendor American Megatrends Inc. version "090008" date 12/07/2018 bios0: Microsoft Corporation Virtual Machine acpi0 at bios0: ACPI 2.0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihve0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz, 2825.55 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 168MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz, 2957.93 MHz, 06-5e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz, 2957.97 MHz, 06-5e-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz, 2957.94 MHz, 06-5e-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 acpiprt0 at acpi0: bus 0 (PCI0) acpipci0 at acpi0 PCI0 acpicmos0 at acpi0 "VMBus" at acpi0 not configured "Hyper_V_Gen_Counter_V1" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!) cpu0: using VERW MDS workaround (except on vmm entry) pvbus0 at mainbus0: Hyper-V 10.0 hyperv0 at pvbus0: protocol 4.0, features 0x2e7f hyperv0: heartbeat, kvp, shutdown, timesync hvs0 at hyperv0 channel 2: ide, protocol 6.2 scsibus1 at hvs0: 2 targets sd0 at scsibus1 targ 0 lun 0: naa.600224802050cb43ae008c0f97857048 sd0: 65536MB, 512 bytes/sector, 134217728 sectors, thin hvs1 at hyperv0 channel 15: scsi, protocol 6.2 scsibus2 at hvs1: 2 targets hvn0 at hyperv0 channel 16: NVS 5.0 NDIS 6.30, address 00:15:5d:9a:72:2f pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 0x03 pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus3 at atapiscsi0: 2 targets cd0 at scsibus3 targ 0 lun 0: removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMBus disabled vga1 at pci0 dev 8 function 0 "Microsoft VGA" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16
rpki-client: use strndup instead of malloc + memcpy
In tal_parse() use strndup() to create the tal descr instead of the more complex malloc, memcpy version. Result is the same but the strndup version is a lot nicer. OK? -- :wq Claudio Index: tal.c === RCS file: /cvs/src/usr.sbin/rpki-client/tal.c,v retrieving revision 1.22 diff -u -p -r1.22 tal.c --- tal.c 11 Oct 2020 12:39:25 - 1.22 +++ tal.c 3 Dec 2020 12:00:25 - @@ -198,10 +198,8 @@ tal_parse(const char *fn, char *buf) dlen = strlen(d); if (strcasecmp(d + dlen - 4, ".tal") == 0) dlen -= 4; - if ((p->descr = malloc(dlen + 1)) == NULL) + if ((p->descr = strndup(d, dlen)) == NULL) err(1, NULL); - memcpy(p->descr, d, dlen); - p->descr[dlen] = '\0'; return p; }
tcpdump: Don't link to libl and remove reference to yydebug
Hi
This is unused. It has been in there since the import from NetBSD.
Their logs show that tcpgram.y and tcplex.l have been removed in 1995.
I am not sure what the policy is for the getopt(3) call: Should Y be
removed in the optstring as well (not done in this diff)?
Best,
Martin
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/tcpdump/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile21 Jun 2020 05:00:17 - 1.66
+++ Makefile3 Dec 2020 10:15:35 -
@@ -30,8 +30,8 @@ CFLAGS+=-I${.CURDIR}/../../lib/libpcap
CFLAGS+=-DCSLIP -DPPP -DHAVE_FDDI -DETHER_SERVICE -DHAVE_ETHER_NTOHOST -DINET6
-LDADD+=-lpcap -ll -lcrypto
-DPADD+=${LIBL} ${LIBPCAP} ${LIBCRYPTO}
+LDADD+=-lpcap -lcrypto
+DPADD+=${LIBPCAP} ${LIBCRYPTO}
SRCS= tcpdump.c addrtoname.c privsep.c privsep_fdpass.c privsep_pcap.c \
print-ether.c print-ip.c print-arp.c print-tcp.c print-udp.c \
Index: tcpdump.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.c,v
retrieving revision 1.94
diff -u -p -r1.94 tcpdump.c
--- tcpdump.c 17 Aug 2020 06:29:29 - 1.94
+++ tcpdump.c 3 Dec 2020 10:15:35 -
@@ -392,15 +392,7 @@ main(int argc, char **argv)
case 'w':
WFileName = optarg;
break;
-#ifdef YYDEBUG
- case 'Y':
- {
- /* Undocumented flag */
- extern int yydebug;
- yydebug = 1;
- }
- break;
-#endif
+
case 'y':
i = pcap_datalink_name_to_val(optarg);
if (i < 0)
