Re: [patch] rename tbl man pages

2022-07-07 Thread Jason McIntyre
On Thu, Jul 07, 2022 at 03:42:27PM +0200, Ingo Schwarze wrote:
> Hi Daniel,
> 
> Daniel Dickman wrote on Thu, Jul 07, 2022 at 12:03:18AM -0400:
> 
> > Over a decade ago there was some work in bsd.man.mk to build tbl pages 
> > with mandoc. For example this commit from 2010:
> > 
> > 
> > revision 1.32
> > date: 2010/10/17 22:47:08;  author: schwarze;  state: Exp;  lines: +8 -18;
> > Build tbl(1) pages with mandoc(1), not groff.
> > Xenocara build checked myself, base build also by jmc@, thanks!
> > "don't wait for me" deraadt@
> > 
> > Pages in base using tbl mostly look good already except for the
> > rare .T{ macros; there may still be a few formatting issues
> > in xenocara, please speak up when you run into them.
> > Eventually, mandoc will catch up.
> 
> Today, the tbl(7) formatting of all the pages you are touching
> is byte-by-byte identical between groff(1) and mandoc(1) -
> with one minor exception in infocmp(1) where groff(1) renders
> a few horizontal lines incorrectly due to a bug in groff(1).
> 
> > 
> > 
> > Back then there was some special infrastructure to build these man pages 
> > if they were named something like *.6tbl.
> > 
> > That convention is a local OpenBSD convention, it does not exist outside 
> > of our tree.
> > 
> > At this point the special naming for these man pages is no longer needed:
> 
> That is completely correct.
> 
> > * games/phantasia/phantasia.6tbl
> > * gnu/usr.sbin/mkhybrid/src/mkhybrid.8tbl
> > * share/man/man4/man4.hppa/cpu.4tbl
> > * share/man/man4/wi.4tbl
> > * share/man/man4/man4.hppa/cpu.4tbl
> > * usr.bin/infocmp/infocmp.1tbl
> > * usr.bin/tic/captoinfo.1tbl
> > 
> > The benefits are:
> > - The affected Makefiles are shortened by 3+ lines
> > - diffing external software like mkhybrid against the original sources 
> >   results in less noise
> > - remove an unnecessary cp step doing the build
> 
> The price to pay is relatively minor: making it slightly harder to
> inspect commit history of these manual pages.  But these are not
> edited often anyway, so that's not a big deal.
> 
> > ok on the diff below? (I've left out the man page renames from the diff 
> > for brevity)
> 
> I don't have a strong opinion either way.  If you think it's worth it,
> i do not object.
> 
> From visual inspection, the diff looks correct to me.  I also tested
> building and installing in the affected directories and noticed no
> issues.  I did not run a complete make build / make release cycle
> though, but i trust you to not break that.
> 
> Yours,
>   Ingo
> 
> 

for me it's a good move:

- easier to find(1) our pages within the source tree
- there are so few of them it just looks inconsistent
- simpler

but i hate losing easy access to cvs history too. so i also have no
strong opinions.

jmc



pipex(4): Add missing lock around all sessions loop within pipex_ip_output()

2022-07-07 Thread Vitaliy Makkoveev
The `pipex_list_mtx' mutex(9) protects global pipex(4) lists so it need
to be taken while we perform this foreach loop.

The all sessions loop was reworked to make possible to drop the lock
within. This is required because pipex_ppp_output() takes scheduler lock
when performs ip_send().

Index: sys/net/pipex.c
===
RCS file: /cvs/src/sys/net/pipex.c,v
retrieving revision 1.143
diff -u -p -r1.143 pipex.c
--- sys/net/pipex.c 2 Jul 2022 08:50:42 -   1.143
+++ sys/net/pipex.c 7 Jul 2022 21:52:16 -
@@ -842,20 +842,39 @@ pipex_ip_output(struct mbuf *m0, struct 
 
m0->m_flags &= ~(M_BCAST|M_MCAST);
 
-   LIST_FOREACH(session_tmp, _session_list, session_list) {
+   mtx_enter(_list_mtx);
+
+   session_tmp = LIST_FIRST(_session_list);
+   while (session_tmp != NULL) {
+   struct pipex_session *session_save = NULL;
+
if (session_tmp->ownersc != session->ownersc)
-   continue;
+   goto next;
if ((session->flags & (PIPEX_SFLAGS_IP_FORWARD |
PIPEX_SFLAGS_IP6_FORWARD)) == 0)
-   continue;
+   goto next;
m = m_copym(m0, 0, M_COPYALL, M_NOWAIT);
if (m == NULL) {
counters_inc(session->stat_counters,
pxc_oerrors);
-   continue;
+   goto next;
}
+
+   refcnt_take(>pxs_refcnt);
+   mtx_leave(_list_mtx);
+
pipex_ppp_output(m, session_tmp, PPP_IP);
+
+   mtx_enter(_list_mtx);
+   session_save = session_tmp;
+next:
+   session_tmp = LIST_NEXT(session_tmp, session_list);
+   if (session_save != NULL)
+   pipex_rele_session(session_save);
}
+
+   mtx_leave(_list_mtx);
+
m_freem(m0);
}
 



Re: pipex(4): use per-session `pxs_mtx' mutex(9) for protection

2022-07-07 Thread Vitaliy Makkoveev
Please drop this diff.

Within rt_clone() we have the code section protected by kernel lock, and
this code section could be reached with mutex(9) held.

pipex(4) needs to be more refactored before introduce per-session
locking.

> On 28 Jun 2022, at 23:14, Vitaliy Makkoveev  wrote:
> 
> On Tue, Jun 28, 2022 at 09:05:09PM +0300, Vitaliy Makkoveev wrote:
>> The updated diff. It was triggered by Hrvoje Popovski, we could do
>> direct (*if_qstart)() call in pipex(4) PPPOE input path, and this
>> provides deadlock. The updated diff uses ip{,6}_send() instead of
>> ipv{4,6}_input().
>> 
> 
> I think, I found better solution. The diff below still uses
> ipv{4,6}_input(), but introduces custom pipex_if_enqueue()
> (*if_enqueue)() handler. Now we can be sure, our (*if_qstart)() handlers
> will never be called directly. Also we can be sure about netlock state
> within our (*if_qstart)() handlers and remove pipexintr().
> 
> We do direct (*if_qstart)() call only if we overflow `if_snd' queue, and
> of course we loose packets in this case, so the behavior mostly the
> same.
> 
> Index: sys/net/if_pppx.c
> ===
> RCS file: /cvs/src/sys/net/if_pppx.c,v
> retrieving revision 1.117
> diff -u -p -r1.117 if_pppx.c
> --- sys/net/if_pppx.c 26 Jun 2022 22:51:58 -  1.117
> +++ sys/net/if_pppx.c 28 Jun 2022 19:56:47 -
> @@ -651,6 +651,7 @@ pppx_add_session(struct pppx_dev *pxd, s
>   ifp->if_mtu = req->pr_peer_mru; /* XXX */
>   ifp->if_flags = IFF_POINTOPOINT | IFF_MULTICAST | IFF_UP;
>   ifp->if_xflags = IFXF_CLONED | IFXF_MPSAFE;
> + ifp->if_enqueue = pipex_if_enqueue;
>   ifp->if_qstart = pppx_if_qstart;
>   ifp->if_output = pppx_if_output;
>   ifp->if_ioctl = pppx_if_ioctl;
> @@ -659,8 +660,6 @@ pppx_add_session(struct pppx_dev *pxd, s
>   ifp->if_softc = pxi;
>   /* ifp->if_rdomain = req->pr_rdomain; */
>   if_counters_alloc(ifp);
> - /* XXXSMP: be sure pppx_if_qstart() called with NET_LOCK held */
> - ifq_set_maxlen(>if_snd, 1);
> 
>   /* XXXSMP breaks atomicity */
>   NET_UNLOCK();
> @@ -801,13 +800,16 @@ pppx_if_qstart(struct ifqueue *ifq)
>   struct mbuf *m;
>   int proto;
> 
> - NET_ASSERT_LOCKED();
> + mtx_enter(>pxi_session->pxs_mtx);
> +
>   while ((m = ifq_dequeue(ifq)) != NULL) {
>   proto = *mtod(m, int *);
>   m_adj(m, sizeof(proto));
> 
>   pipex_ppp_output(m, pxi->pxi_session, proto);
>   }
> +
> + mtx_leave(>pxi_session->pxs_mtx);
> }
> 
> int
> @@ -1041,11 +1043,10 @@ pppacopen(dev_t dev, int flags, int mode
>   ifp->if_flags = IFF_SIMPLEX | IFF_BROADCAST;
>   ifp->if_xflags = IFXF_CLONED | IFXF_MPSAFE;
>   ifp->if_rtrequest = p2p_rtrequest; /* XXX */
> + ifp->if_enqueue = pipex_if_enqueue;
>   ifp->if_output = pppac_output;
>   ifp->if_qstart = pppac_qstart;
>   ifp->if_ioctl = pppac_ioctl;
> - /* XXXSMP: be sure pppac_qstart() called with NET_LOCK held */
> - ifq_set_maxlen(>if_snd, 1);
> 
>   if_counters_alloc(ifp);
>   if_attach(ifp);
> @@ -1441,7 +1442,6 @@ pppac_qstart(struct ifqueue *ifq)
>   struct ip ip;
>   int rv;
> 
> - NET_ASSERT_LOCKED();
>   while ((m = ifq_dequeue(ifq)) != NULL) {
> #if NBPFILTER > 0
>   if (ifp->if_bpf) {
> Index: sys/net/pipex.c
> ===
> RCS file: /cvs/src/sys/net/pipex.c,v
> retrieving revision 1.142
> diff -u -p -r1.142 pipex.c
> --- sys/net/pipex.c   28 Jun 2022 08:01:40 -  1.142
> +++ sys/net/pipex.c   28 Jun 2022 19:56:47 -
> @@ -91,7 +91,6 @@ struct pool mppe_key_pool;
>  * Locks used to protect global data
>  *   A   atomic operation
>  *   I   immutable after creation
> - *   N   net lock
>  *   L   pipex_list_mtx
>  */
> 
> @@ -172,7 +171,6 @@ pipex_ioctl(void *ownersc, u_long cmd, c
> {
>   int ret = 0;
> 
> - NET_ASSERT_LOCKED();
>   switch (cmd) {
>   case PIPEXCSESSION:
>   ret = pipex_config_session(
> @@ -197,6 +195,19 @@ pipex_ioctl(void *ownersc, u_long cmd, c
>   return (ret);
> }
> 
> +int
> +pipex_if_enqueue(struct ifnet *ifp, struct mbuf *m)
> +{
> + struct ifqueue *ifq = >if_snd;
> + int error;
> +
> + if ((error = ifq_enqueue(ifq, m)) != 0)
> + return (error);
> + task_add(ifq->ifq_softnet, >ifq_bundle);
> +
> + return (0);
> +}
> +
> /
>  * Software Interrupt Handler
>  /
> @@ -575,18 +586,20 @@ pipex_config_session(struct pipex_sessio
>   struct pipex_session *session;
>   int error = 0;
> 
> - NET_ASSERT_LOCKED();
> -
>   session = pipex_lookup_by_session_id(req->pcr_protocol,
>   req->pcr_session_id);
>   if (session == NULL)
>   

Re: bgpd: assign local path_id to all prefixes

2022-07-07 Thread Theo Buehler
On Thu, Jul 07, 2022 at 05:27:58PM +0200, Claudio Jeker wrote:
> This diff is assigning a local path_id to all prefixes. This path_id will
> be used for sending out add-path updates. Since the RFC specifies that the
> path_id has no meaning we assing the path_ids randomly. They just need to
> be unique per rib entry. Now this code assigne the path_id in the
> Adj-RIB-In and then inherits the number to all other ribs. Currently the
> Adj-RIB-Out is excluded since that code is not yet ready for more than one
> path. That is the next step.

ok tb



bgpd: assign local path_id to all prefixes

2022-07-07 Thread Claudio Jeker
This diff is assigning a local path_id to all prefixes. This path_id will
be used for sending out add-path updates. Since the RFC specifies that the
path_id has no meaning we assing the path_ids randomly. They just need to
be unique per rib entry. Now this code assigne the path_id in the
Adj-RIB-In and then inherits the number to all other ribs. Currently the
Adj-RIB-Out is excluded since that code is not yet ready for more than one
path. That is the next step.

-- 
:wq Claudio

Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.551
diff -u -p -r1.551 rde.c
--- rde.c   7 Jul 2022 13:55:52 -   1.551
+++ rde.c   7 Jul 2022 14:29:04 -
@@ -1600,6 +1600,46 @@ done:
rde_filterstate_clean();
 }
 
+/*
+ * Check if path_id is already in use.
+ */
+static int
+pathid_conflict(struct rib_entry *re, uint32_t pathid)
+{
+   struct prefix *p;
+
+   if (re == NULL)
+   return 0;
+
+   TAILQ_FOREACH(p, >prefix_h, entry.list.rib)
+   if (p->path_id_tx == pathid)
+   return 1;
+   return 0;
+}
+
+static uint32_t
+pathid_assign(struct rde_peer *peer, uint32_t path_id,
+struct bgpd_addr *prefix, uint8_t prefixlen)
+{
+   struct rib_entry *re;
+   struct prefix *p = NULL;
+   uint32_t path_id_tx;
+
+   /* Assign a send side path_id to all paths */
+   re = rib_get(rib_byid(RIB_ADJ_IN), prefix, prefixlen);
+   if (re != NULL)
+   p = prefix_bypeer(re, peer, path_id);
+   if (p != NULL)
+   path_id_tx = p->path_id_tx;
+   else {
+   do {
+   /* assign new local path_id */
+   path_id_tx = arc4random();
+   } while (pathid_conflict(re, path_id_tx));
+   }
+   return path_id_tx;
+}
+
 int
 rde_update_update(struct rde_peer *peer, uint32_t path_id,
 struct filterstate *in, struct bgpd_addr *prefix, uint8_t prefixlen)
@@ -1608,15 +1648,18 @@ rde_update_update(struct rde_peer *peer,
enum filter_actions  action;
uint8_t  vstate;
uint16_t i;
+   uint32_t path_id_tx;
const char  *wmsg = "filtered, withdraw";
 
peer->prefix_rcvd_update++;
vstate = rde_roa_validity(_roa, prefix, prefixlen,
aspath_origin(in->aspath.aspath));
 
+   path_id_tx = pathid_assign(peer, path_id, prefix, prefixlen);
+
/* add original path to the Adj-RIB-In */
-   if (prefix_update(rib_byid(RIB_ADJ_IN), peer, path_id, in,
-   prefix, prefixlen, vstate) == 1)
+   if (prefix_update(rib_byid(RIB_ADJ_IN), peer, path_id, path_id_tx,
+   in, prefix, prefixlen, vstate) == 1)
peer->prefix_cnt++;
 
/* max prefix checker */
@@ -1644,8 +1687,8 @@ rde_update_update(struct rde_peer *peer,
rde_update_log("update", i, peer,
>exit_nexthop, prefix,
prefixlen);
-   prefix_update(rib, peer, path_id, , prefix,
-   prefixlen, vstate);
+   prefix_update(rib, peer, path_id, path_id_tx, ,
+   prefix, prefixlen, vstate);
} else if (prefix_withdraw(rib, peer, path_id, prefix,
prefixlen)) {
rde_update_log(wmsg, i, peer,
@@ -3719,7 +3762,8 @@ rde_softreconfig_in(struct rib_entry *re
 
if (action == ACTION_ALLOW) {
/* update Local-RIB */
-   prefix_update(rib, peer, p->path_id, ,
+   prefix_update(rib, peer, p->path_id,
+   p->path_id_tx, ,
, pt->prefixlen,
p->validation_state);
} else if (action == ACTION_DENY) {
@@ -3858,7 +3902,8 @@ rde_roa_softreload(struct rib_entry *re,
 
if (action == ACTION_ALLOW) {
/* update Local-RIB */
-   prefix_update(rib, peer, p->path_id, ,
+   prefix_update(rib, peer, p->path_id,
+   p->path_id_tx, ,
, pt->prefixlen,
p->validation_state);
} else if (action == ACTION_DENY) {
@@ -4026,6 +4071,7 @@ network_add(struct network_config *nc, s
struct in6_addr  prefix6;
uint8_t  vstate;
uint16_t i;
+   uint32_t path_id_tx;
 
if (nc->rd != 0) {
SIMPLEQ_FOREACH(vpn, >l3vpns, entry) {
@@ -4087,8 +4133,9 @@ network_add(struct network_config *nc, s
 
vstate = 

Re: [patch] rename tbl man pages

2022-07-07 Thread Ingo Schwarze
Hi Daniel,

Daniel Dickman wrote on Thu, Jul 07, 2022 at 12:03:18AM -0400:

> Over a decade ago there was some work in bsd.man.mk to build tbl pages 
> with mandoc. For example this commit from 2010:
> 
> 
> revision 1.32
> date: 2010/10/17 22:47:08;  author: schwarze;  state: Exp;  lines: +8 -18;
> Build tbl(1) pages with mandoc(1), not groff.
> Xenocara build checked myself, base build also by jmc@, thanks!
> "don't wait for me" deraadt@
> 
> Pages in base using tbl mostly look good already except for the
> rare .T{ macros; there may still be a few formatting issues
> in xenocara, please speak up when you run into them.
> Eventually, mandoc will catch up.

Today, the tbl(7) formatting of all the pages you are touching
is byte-by-byte identical between groff(1) and mandoc(1) -
with one minor exception in infocmp(1) where groff(1) renders
a few horizontal lines incorrectly due to a bug in groff(1).

> 
> 
> Back then there was some special infrastructure to build these man pages 
> if they were named something like *.6tbl.
> 
> That convention is a local OpenBSD convention, it does not exist outside 
> of our tree.
> 
> At this point the special naming for these man pages is no longer needed:

That is completely correct.

> * games/phantasia/phantasia.6tbl
> * gnu/usr.sbin/mkhybrid/src/mkhybrid.8tbl
> * share/man/man4/man4.hppa/cpu.4tbl
> * share/man/man4/wi.4tbl
> * share/man/man4/man4.hppa/cpu.4tbl
> * usr.bin/infocmp/infocmp.1tbl
> * usr.bin/tic/captoinfo.1tbl
> 
> The benefits are:
> - The affected Makefiles are shortened by 3+ lines
> - diffing external software like mkhybrid against the original sources 
>   results in less noise
> - remove an unnecessary cp step doing the build

The price to pay is relatively minor: making it slightly harder to
inspect commit history of these manual pages.  But these are not
edited often anyway, so that's not a big deal.

> ok on the diff below? (I've left out the man page renames from the diff 
> for brevity)

I don't have a strong opinion either way.  If you think it's worth it,
i do not object.

>From visual inspection, the diff looks correct to me.  I also tested
building and installing in the affected directories and noticed no
issues.  I did not run a complete make build / make release cycle
though, but i trust you to not break that.

Yours,
  Ingo


> Index: games/phantasia/Makefile
> ===
> RCS file: /cvs/src/games/phantasia/Makefile,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 Makefile
> --- games/phantasia/Makefile  24 Nov 2015 03:10:10 -  1.18
> +++ games/phantasia/Makefile  7 Jul 2022 01:24:22 -
> @@ -6,7 +6,7 @@ CFLAGS+=-DTERMIOS
>  DPADD=   ${LIBM} ${LIBCURSES}
>  LDADD=   -lm -lcurses
>  MAN= phantasia.6
> -CLEANFILES+=map setup setup.o phantglobs.o.bld phantasia.6
> +CLEANFILES+=map setup setup.o phantglobs.o.bld
>  
>  all: setup phantasia
>  
> @@ -19,9 +19,6 @@ phantglobs.o.bld: phantglobs.c
>  setup: phantglobs.o.bld setup.o monsters.asc ${DPADD} 
>   ${HOSTCC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} \
> phantglobs.o.bld setup.o ${LDADD}
> -
> -phantasia.6: phantasia.6tbl
> - cp ${.ALLSRC} ${.TARGET}
>  
>  beforeinstall: 
>   ./setup -m ${.CURDIR}/monsters.asc
> Index: gnu/usr.sbin/mkhybrid/mkhybrid/Makefile
> ===
> RCS file: /cvs/src/gnu/usr.sbin/mkhybrid/mkhybrid/Makefile,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 Makefile
> --- gnu/usr.sbin/mkhybrid/mkhybrid/Makefile   9 Sep 2015 20:02:31 -   
> 1.7
> +++ gnu/usr.sbin/mkhybrid/mkhybrid/Makefile   7 Jul 2022 01:24:22 -
> @@ -8,7 +8,6 @@
>  PROG=mkhybrid
>  MAN= mkhybrid.8
>  BINDIR=  /usr/sbin
> -CLEANFILES+= mkhybrid.8
>  .PATH:   ${.CURDIR}/../src ${.CURDIR}/../src/libhfs_iso 
> ${.CURDIR}/../src/libfile
>  
>  SRCS=data.c block.c low.c lfile.c btree.c node.c record.c lvolume.c \
> @@ -20,8 +19,5 @@ CFLAGS+=-DSYSTEM_ID_DEFAULT=\"OpenBSD\" 
>   -I${.CURDIR}/../src -I${.CURDIR}/../src/include \
>   -I${.CURDIR}/../src/libhfs_iso \
>   -I${.CURDIR}/../src/libfile
> -
> -mkhybrid.8: mkhybrid.8tbl
> - cp ${.ALLSRC} ${.TARGET}
>  
>  .include 
> Index: share/man/man4/man4.hppa/Makefile
> ===
> RCS file: /cvs/src/share/man/man4/man4.hppa/Makefile,v
> retrieving revision 1.29
> diff -u -p -u -r1.29 Makefile
> --- share/man/man4/man4.hppa/Makefile 30 Mar 2016 06:38:44 -  1.29
> +++ share/man/man4/man4.hppa/Makefile 7 Jul 2022 01:24:22 -
> @@ -6,9 +6,5 @@ MAN+= harmony.4 ie.4 intro.4 io.4 lasi.4
>  MAN+=phantomas.4 power.4 runway.4 ssio.4 uturn.4 wax.4
>  # tir.4 xbar.4 mcx.4
>  MANSUBDIR=hppa
> -CLEANFILES+= cpu.4
> -
> -cpu.4: cpu.4tbl
> - cp ${.ALLSRC} ${.TARGET}
>  
>  .include 
> Index: share/man/man4/Makefile

Re: [patch] rename tbl man pages

2022-07-07 Thread Jason McIntyre
On Thu, Jul 07, 2022 at 12:03:18AM -0400, Daniel Dickman wrote:
> Over a decade ago there was some work in bsd.man.mk to build tbl pages 
> with mandoc. For example this commit from 2010:
> 
> 
> revision 1.32
> date: 2010/10/17 22:47:08;  author: schwarze;  state: Exp;  lines: +8 -18;
> Build tbl(1) pages with mandoc(1), not groff.
> Xenocara build checked myself, base build also by jmc@, thanks!
> "don't wait for me" deraadt@
> 
> Pages in base using tbl mostly look good already except for the
> rare .T{ macros; there may still be a few formatting issues
> in xenocara, please speak up when you run into them.
> Eventually, mandoc will catch up.
> 
> 
> Back then there was some special infrastructure to build these man pages 
> if they were named something like *.6tbl.
> 
> That convention is a local OpenBSD convention, it does not exist outside 
> of our tree.
> 
> At this point the special naming for these man pages is no longer needed:
> 
> * games/phantasia/phantasia.6tbl
> * gnu/usr.sbin/mkhybrid/src/mkhybrid.8tbl
> * share/man/man4/man4.hppa/cpu.4tbl
> * share/man/man4/wi.4tbl
> * share/man/man4/man4.hppa/cpu.4tbl
> * usr.bin/infocmp/infocmp.1tbl
> * usr.bin/tic/captoinfo.1tbl
> 
> The benefits are:
> - The affected Makefiles are shortened by 3+ lines
> - diffing external software like mkhybrid against the original sources 
>   results in less noise
> - remove an unnecessary cp step doing the build
> 
> ok on the diff below? (I've left out the man page renames from the diff 
> for brevity)
> 
> 

hi.

if we can do it without issue, it would definitely be preferrable. i'm
pretty sure this is a question for ingo, though.

jmc

> 
> Index: games/phantasia/Makefile
> ===
> RCS file: /cvs/src/games/phantasia/Makefile,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 Makefile
> --- games/phantasia/Makefile  24 Nov 2015 03:10:10 -  1.18
> +++ games/phantasia/Makefile  7 Jul 2022 01:24:22 -
> @@ -6,7 +6,7 @@ CFLAGS+=-DTERMIOS
>  DPADD=   ${LIBM} ${LIBCURSES}
>  LDADD=   -lm -lcurses
>  MAN= phantasia.6
> -CLEANFILES+=map setup setup.o phantglobs.o.bld phantasia.6
> +CLEANFILES+=map setup setup.o phantglobs.o.bld
>  
>  all: setup phantasia
>  
> @@ -19,9 +19,6 @@ phantglobs.o.bld: phantglobs.c
>  setup: phantglobs.o.bld setup.o monsters.asc ${DPADD} 
>   ${HOSTCC} ${CFLAGS} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} \
> phantglobs.o.bld setup.o ${LDADD}
> -
> -phantasia.6: phantasia.6tbl
> - cp ${.ALLSRC} ${.TARGET}
>  
>  beforeinstall: 
>   ./setup -m ${.CURDIR}/monsters.asc
> Index: gnu/usr.sbin/mkhybrid/mkhybrid/Makefile
> ===
> RCS file: /cvs/src/gnu/usr.sbin/mkhybrid/mkhybrid/Makefile,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 Makefile
> --- gnu/usr.sbin/mkhybrid/mkhybrid/Makefile   9 Sep 2015 20:02:31 -   
> 1.7
> +++ gnu/usr.sbin/mkhybrid/mkhybrid/Makefile   7 Jul 2022 01:24:22 -
> @@ -8,7 +8,6 @@
>  PROG=mkhybrid
>  MAN= mkhybrid.8
>  BINDIR=  /usr/sbin
> -CLEANFILES+= mkhybrid.8
>  .PATH:   ${.CURDIR}/../src ${.CURDIR}/../src/libhfs_iso 
> ${.CURDIR}/../src/libfile
>  
>  SRCS=data.c block.c low.c lfile.c btree.c node.c record.c lvolume.c \
> @@ -20,8 +19,5 @@ CFLAGS+=-DSYSTEM_ID_DEFAULT=\"OpenBSD\" 
>   -I${.CURDIR}/../src -I${.CURDIR}/../src/include \
>   -I${.CURDIR}/../src/libhfs_iso \
>   -I${.CURDIR}/../src/libfile
> -
> -mkhybrid.8: mkhybrid.8tbl
> - cp ${.ALLSRC} ${.TARGET}
>  
>  .include 
> Index: share/man/man4/man4.hppa/Makefile
> ===
> RCS file: /cvs/src/share/man/man4/man4.hppa/Makefile,v
> retrieving revision 1.29
> diff -u -p -u -r1.29 Makefile
> --- share/man/man4/man4.hppa/Makefile 30 Mar 2016 06:38:44 -  1.29
> +++ share/man/man4/man4.hppa/Makefile 7 Jul 2022 01:24:22 -
> @@ -6,9 +6,5 @@ MAN+= harmony.4 ie.4 intro.4 io.4 lasi.4
>  MAN+=phantomas.4 power.4 runway.4 ssio.4 uturn.4 wax.4
>  # tir.4 xbar.4 mcx.4
>  MANSUBDIR=hppa
> -CLEANFILES+= cpu.4
> -
> -cpu.4: cpu.4tbl
> - cp ${.ALLSRC} ${.TARGET}
>  
>  .include 
> Index: share/man/man4/Makefile
> ===
> RCS file: /cvs/src/share/man/man4/Makefile,v
> retrieving revision 1.817
> diff -u -p -u -r1.817 Makefile
> --- share/man/man4/Makefile   18 Jan 2022 07:53:39 -  1.817
> +++ share/man/man4/Makefile   7 Jul 2022 01:24:22 -
> @@ -113,9 +113,4 @@ SUBDIR=   man4.alpha man4.amd64 man4.arm64
>   man4.hppa man4.i386 man4.landisk man4.loongson man4.luna88k \
>   man4.macppc man4.octeon man4.powerpc64 man4.riscv64 man4.sparc64
>  
> -CLEANFILES+= wi.4
> -
> -wi.4: wi.4tbl
> - cp ${.ALLSRC} ${.TARGET}
> -
>  .include 
> Index: share/man/man4/man4.hppa/Makefile
> 

Re: [v3] amd64: simplify TSC sync testing

2022-07-07 Thread Masato Asou
Hi,

I tested your patch on my OpenSUSE + Xen on Ryzen7 box.
It works fine for me.

OpenBSD 7.1-current (GENERIC.MP) #1: Thu Jul  7 15:22:32 JST 2022
a...@xen-obsd1.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8556376064 (8159MB)
avail mem = 8279695360 (7896MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc10 (18 entries)
bios0: vendor Xen version "4.14.5_02-150300.3." date 06/08/2022
bios0: Xen HVM domU
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 3700X 8-Core Processor, 3593.65 MHz, 17-71-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,DBKP,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache
cpu0: 512KB 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 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 7 3700X 8-Core Processor, 3593.27 MHz, 17-71-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,DBKP,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: AMD Ryzen 7 3700X 8-Core Processor, 3593.26 MHz, 17-71-00
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,DBKP,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache
cpu2: 512KB 64b/line 8-way L2 cache
cpu2: smt 0, core 4, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: AMD Ryzen 7 3700X 8-Core Processor, 3593.25 MHz, 17-71-00
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,DBKP,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache
cpu3: 512KB 64b/line 8-way L2 cache
cpu3: smt 0, core 6, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: AMD Ryzen 7 3700X 8-Core Processor, 3593.27 MHz, 17-71-00
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,DBKP,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu4: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache
cpu4: 512KB 64b/line 8-way L2 cache
cpu4: smt 0, core 8, package 0
cpu5 at mainbus0: apid 10 (application processor)
cpu5: AMD Ryzen 7 3700X 8-Core Processor, 3593.32 MHz, 17-71-00
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,DBKP,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu5: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache
cpu5: 512KB 64b/line 8-way L2 cache
cpu5: smt 0, core 10, package 0
cpu6 at mainbus0: apid 12 (application processor)
cpu6: AMD Ryzen 7 3700X 8-Core Processor, 3593.34 MHz, 17-71-00
cpu6: