date:20181210

Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-10 Thread Stefan Esser

Am 10.12.18 um 07:47 schrieb Warner Losh:
> 
> 
> On Sun, Dec 9, 2018, 11:40 PM Cy Schubert   wrote:
> 
> In message <201812100619.wba6jb0c064...@pdx.rh.cn85.dnsmgr.net
> >,
> "Rodney W. Gri
> mes" writes:
> > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter
> mailto:oliver.pin...@hardenedbsd.org>
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > > On Sunday, December 9, 2018, Warner Losh  > wrote:
> > > >
> > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes <
> > > >> free...@pdx.rh.cn85.dnsmgr.net
> > wrote:
> > > >>
> > > >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org
> >, Cy
> > > >> Schubert
> > > >> > > writes:
> > > >> > > > Author: cy
> > > >> > > > Date: Sun Dec  9 06:45:49 2018
> > > >> > > > New Revision: 341759
> > > >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759
> > > >> > > >
> > > >> > > > Log:
> > > >> > > >   MFV r341618:
> > > >> > > >
> > > >> > > >   Update wpa 2.6 --> 2.7.
> > > >> > >
> > > >> > > Relnotes: yes
> > > >> >
> > > >> > As an FYI, or maybe a new procedure, doing a reply to
> > > >> > a commit message adding relnotes: yes does very little
> > > >> > to insure that this commit gets refered to in release
> > > >> > notes.
> > > >> >
> > > >> > What about we add RELNOTES.missed to the tree
> > > >> > next to UPDATING, and when someone forgets to tag
> > > >> > the Relnotes:yes into a commit you just follow up
> > > >> > with a commit to that file, stating the svn revision
> > > >> > which was missing the note and then we have a nice
> > > >> > documented and clean way to extract the missing
> > > >> > release note items, rather than trying to cull it
> > > >> > from a thread in a mail list archive.
> > > >> >
> > > >> > The file would get truncated to 0 at appropriate
> > > >> > times on various branches.
> > > >> >
> > > >>
> > > >> How about just RELNOTES. You put the revision that is relevant and
> a qui
> > ck
> > > >> blurb. That way we don't have to look in two places. All release
> notes g
> > o
> > > >> in here, no exceptions. You can retroactively tag them, or you can
> commi
> > t
> > > >> this as part of commit.
> >
> > My one concern is that if we remove the Relnotes: yes line
> > from the commits then we may end up totally ignoring the
> > need to put entries in RELNOTES, which unlike UPDATING
> > do not have consequences if ignored.
> >
> > > >
> > > >
> > > >>
> > > > I don't really know SVN, but there wouldn't be a chicken egg probem
> durin
> > g
> > > > commit time? I mean you would really know the SVN id. So you could
> only a
> > dd
> > > > a specific revision in a different commit to RELEASE file.
> > > >
> > >
> > > Generally, you can guess really well, and fix it in the case of a lost
> race
> > > easily.
> >
> > No reason to guess, if you add the RELNOTES change with the commit
> > then it is the revision that added the RELNOTES entry, so a log view
> > of RELNOTES would show you the revision.  If you do it after words
> > or edit an existing entry in the RELNOTES file that is also fairly
> > clear as that commit has no other files touched.
> >
> > >
> > > You'd add the release notes text in full to the file, with a pointer
> to the
> > > revision(s) for the feature.
> >
> > If you modify RELNOTES with the commit adding the feature we
> > could easily use a pointer of "this commit", the svn version number
> > of that added entry is self referencing to the actual change,
> > which I actually rather like the idea of.
> >
> > >
> > > Warner
> > >
> > > >
> > > >> Have a blurb at the top that tells people what
> > > >> order to add them in, and you'd be set. We'd then retire "relnotes:
> yes"
> > > >> in
> > > >> the commit message. This would also allow 'helpers' to format the
> RELNOT
> > ES
> > > >> file as we go rather than having to play 2 years of catch-up at 
> major
> > > >> branch times.
> >
> > Yes.  You could actually "delete" an entry from RELNOTES once a
> > proper entry in the actual release notes had been created, such
> > that RELNOTES is really a list of pending items.
> >
> > > >>
> > > >> Having it in the commit message just doesn't work, and this is one
> of ma
> > ny
> > > >> reasons: Cy forgot. Other times I'll do something and it's only a 
> month
> > > >> later I realize it needs to be in the release notes aft

svn commit: r341782 - head/sys/dev/sfxge

2018-12-10 Thread Andrew Rybchenko

Author: arybchik
Date: Mon Dec 10 09:35:33 2018
New Revision: 341782
URL: https://svnweb.freebsd.org/changeset/base/341782

Log:
  sfxge(4): populate per-event queue stats in sysctl
  
  In order to find out why the first event queue and corresponding
  interrupt is triggered more frequent, it is useful to know which
  events go to each event queue.
  
  Sponsored by:   Solarflare Communications, Inc.
  MFC after:  1 week
  Differential Revision:  https://reviews.freebsd.org/D18418

Modified:
  head/sys/dev/sfxge/sfxge.h
  head/sys/dev/sfxge/sfxge_ev.c

Modified: head/sys/dev/sfxge/sfxge.h
==
--- head/sys/dev/sfxge/sfxge.h  Mon Dec 10 04:16:40 2018(r341781)
+++ head/sys/dev/sfxge/sfxge.h  Mon Dec 10 09:35:33 2018(r341782)
@@ -184,6 +184,10 @@ struct sfxge_evq {
unsigned intbuf_base_id;
unsigned intentries;
charlock_name[SFXGE_LOCK_NAME_MAX];
+#if EFSYS_OPT_QSTATS
+   clock_t stats_update_time;
+   uint64_tstats[EV_NQSTATS];
+#endif
 } __aligned(CACHE_LINE_SIZE);
 
 #defineSFXGE_NDESCS1024
@@ -275,6 +279,9 @@ struct sfxge_softc {
struct ifnet*ifnet;
unsigned intif_flags;
struct sysctl_oid   *stats_node;
+#if EFSYS_OPT_QSTATS
+   struct sysctl_oid   *evqs_stats_node;
+#endif
struct sysctl_oid   *txqs_node;
 
struct task task_reset;

Modified: head/sys/dev/sfxge/sfxge_ev.c
==
--- head/sys/dev/sfxge/sfxge_ev.c   Mon Dec 10 04:16:40 2018
(r341781)
+++ head/sys/dev/sfxge/sfxge_ev.c   Mon Dec 10 09:35:33 2018
(r341782)
@@ -443,29 +443,94 @@ sfxge_ev_wake_up(void *arg, uint32_t index)
 #if EFSYS_OPT_QSTATS
 
 static void
+sfxge_evq_stat_update(struct sfxge_evq *evq)
+{
+   clock_t now;
+
+   SFXGE_EVQ_LOCK(evq);
+
+   if (__predict_false(evq->init_state != SFXGE_EVQ_STARTED))
+   goto out;
+
+   now = ticks;
+   if ((unsigned int)(now - evq->stats_update_time) < (unsigned int)hz)
+   goto out;
+
+   evq->stats_update_time = now;
+   efx_ev_qstats_update(evq->common, evq->stats);
+
+out:
+   SFXGE_EVQ_UNLOCK(evq);
+}
+
+static int
+sfxge_evq_stat_handler(SYSCTL_HANDLER_ARGS)
+{
+   struct sfxge_evq *evq = arg1;
+   struct sfxge_softc *sc = evq->sc;
+   unsigned int id = arg2;
+
+   SFXGE_ADAPTER_LOCK(sc);
+
+   sfxge_evq_stat_update(evq);
+
+   SFXGE_ADAPTER_UNLOCK(sc);
+
+   return (SYSCTL_OUT(req, &evq->stats[id], sizeof(evq->stats[id])));
+}
+
+static int
+sfxge_evq_stat_init(struct sfxge_evq *evq)
+{
+   struct sfxge_softc *sc = evq->sc;
+   struct sysctl_ctx_list *ctx = device_get_sysctl_ctx(sc->dev);
+   char name[16];
+   struct sysctl_oid *evq_stats_node;
+   unsigned int id;
+
+   snprintf(name, sizeof(name), "%u", evq->index);
+   evq_stats_node = SYSCTL_ADD_NODE(ctx,
+SYSCTL_CHILDREN(sc->evqs_stats_node),
+OID_AUTO, name, CTLFLAG_RD, NULL, "");
+   if (evq_stats_node == NULL)
+   return (ENOMEM);
+
+   for (id = 0; id < EV_NQSTATS; id++) {
+   SYSCTL_ADD_PROC(
+   ctx, SYSCTL_CHILDREN(evq_stats_node),
+   OID_AUTO, efx_ev_qstat_name(sc->enp, id),
+   CTLTYPE_U64|CTLFLAG_RD,
+   evq, id, sfxge_evq_stat_handler, "Q",
+   "");
+   }
+
+   return (0);
+}
+
+static void
 sfxge_ev_stat_update(struct sfxge_softc *sc)
 {
struct sfxge_evq *evq;
unsigned int index;
clock_t now;
+   unsigned int id;
 
SFXGE_ADAPTER_LOCK(sc);
 
-   if (__predict_false(sc->evq[0]->init_state != SFXGE_EVQ_STARTED))
-   goto out;
-
now = ticks;
if ((unsigned int)(now - sc->ev_stats_update_time) < (unsigned int)hz)
goto out;
 
sc->ev_stats_update_time = now;
 
-   /* Add event counts from each event queue in turn */
+   memset(sc->ev_stats, 0, sizeof(sc->ev_stats));
+
+   /* Update and add event counts from each event queue in turn */
for (index = 0; index < sc->evq_count; index++) {
evq = sc->evq[index];
-   SFXGE_EVQ_LOCK(evq);
-   efx_ev_qstats_update(evq->common, sc->ev_stats);
-   SFXGE_EVQ_UNLOCK(evq);
+   sfxge_evq_stat_update(evq);
+   for (id = 0; id < EV_NQSTATS; id++)
+   sc->ev_stats[id] += evq->stats[id];
}
 out:
SFXGE_ADAPTER_UNLOCK(sc);
@@ -672,7 +737,7 @@ sfxge_ev_qstop(struct sfxge_softc *sc, unsigned int in
 
 #if EFSYS_OPT_QS

svn commit: r341783 - head/sys/dev/sfxge/common

2018-12-10 Thread Andrew Rybchenko

Author: arybchik
Date: Mon Dec 10 09:35:45 2018
New Revision: 341783
URL: https://svnweb.freebsd.org/changeset/base/341783

Log:
  sfxge(4): report support for Tx checksum op descriptors
  
  FreeBSD driver needs a patch to provide a means for packets
  which do not need checksum offload but have flow ID set
  to avoid hitting only the first Tx queue (which has been used
  for packets not needing checksum offload).
  
  This should be possible on Huntington, Medford or Medford2 chips
  since these support toggling checksum offload on any given queue
  dynamically by means of pushing option descriptors.
  
  The patch for FreeBSD driver will then need a means to figure out
  whether the feature can be used, and testing adapter family might
  not be a good solution.
  
  This patch adds a feature bit specifically to indicate support
  for checksum option descriptors. The new feature bits may have
  more users in future, apart from the mentioned FreeBSD patch.
  
  Submitted by:   Ivan Malov 
  Sponsored by:   Solarflare Communications, Inc.
  MFC after:  1 week
  Differential Revision:  https://reviews.freebsd.org/D18388

Modified:
  head/sys/dev/sfxge/common/efx.h
  head/sys/dev/sfxge/common/efx_nic.c

Modified: head/sys/dev/sfxge/common/efx.h
==
--- head/sys/dev/sfxge/common/efx.h Mon Dec 10 09:35:33 2018
(r341782)
+++ head/sys/dev/sfxge/common/efx.h Mon Dec 10 09:35:45 2018
(r341783)
@@ -1261,6 +1261,7 @@ efx_bist_stop(
 #defineEFX_FEATURE_FW_ASSISTED_TSO 0x1000
 #defineEFX_FEATURE_FW_ASSISTED_TSO_V2  0x2000
 #defineEFX_FEATURE_PACKED_STREAM   0x4000
+#defineEFX_FEATURE_TXQ_CKSUM_OP_DESC   0x8000
 
 typedef enum efx_tunnel_protocol_e {
EFX_TUNNEL_PROTOCOL_NONE = 0,

Modified: head/sys/dev/sfxge/common/efx_nic.c
==
--- head/sys/dev/sfxge/common/efx_nic.c Mon Dec 10 09:35:33 2018
(r341782)
+++ head/sys/dev/sfxge/common/efx_nic.c Mon Dec 10 09:35:45 2018
(r341783)
@@ -257,7 +257,8 @@ efx_nic_create(
EFX_FEATURE_PIO_BUFFERS |
EFX_FEATURE_FW_ASSISTED_TSO |
EFX_FEATURE_FW_ASSISTED_TSO_V2 |
-   EFX_FEATURE_PACKED_STREAM;
+   EFX_FEATURE_PACKED_STREAM |
+   EFX_FEATURE_TXQ_CKSUM_OP_DESC;
break;
 #endif /* EFSYS_OPT_HUNTINGTON */
 
@@ -277,7 +278,8 @@ efx_nic_create(
EFX_FEATURE_MCDI_DMA |
EFX_FEATURE_PIO_BUFFERS |
EFX_FEATURE_FW_ASSISTED_TSO_V2 |
-   EFX_FEATURE_PACKED_STREAM;
+   EFX_FEATURE_PACKED_STREAM |
+   EFX_FEATURE_TXQ_CKSUM_OP_DESC;
break;
 #endif /* EFSYS_OPT_MEDFORD */
 
@@ -293,7 +295,8 @@ efx_nic_create(
EFX_FEATURE_MCDI_DMA |
EFX_FEATURE_PIO_BUFFERS |
EFX_FEATURE_FW_ASSISTED_TSO_V2 |
-   EFX_FEATURE_PACKED_STREAM;
+   EFX_FEATURE_PACKED_STREAM |
+   EFX_FEATURE_TXQ_CKSUM_OP_DESC;
break;
 #endif /* EFSYS_OPT_MEDFORD2 */
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341768 - head/sbin/ping

2018-12-10 Thread Bruce Evans


On Sun, 9 Dec 2018, Eugene Grosbein wrote:


Log:
 ping(8): remove needless comparision with LONG_MAX
 after unsigned long ultmp changed to long ltmp in r340245.

 MFC after: 1 week


A range check is needed, and is now not even attempted for large positive
values.  The logic for the range check was broken in r340245.  The LONG_MAX
was a vestige of the correct logic.  Several other vestiges remain.


Modified: head/sbin/ping/ping.c
==
--- head/sbin/ping/ping.c   Sun Dec  9 19:14:21 2018(r341767)
+++ head/sbin/ping/ping.c   Sun Dec  9 21:11:15 2018(r341768)
@@ -313,7 +313,7 @@ main(int argc, char *const *argv)
break;
case 'c':
ltmp = strtol(optarg, &ep, 0);
-   if (*ep || ep == optarg || ltmp > LONG_MAX || ltmp <=0)
+   if (*ep || ep == optarg || ltmp <=0)
errx(EX_USAGE,
"invalid count of packets to transmit: 
`%s'",
optarg);


The bugs in r340245 visible in this patch are:
- lost range checking for large positive values.  Before r340245, this was
  done hackishly by using strtoul() so that the in-bound error value
  ULONG_MAX was out of bounds for the range check against LONG_MAX.  This
  range check also checked for large values which don't overflow u_long.
  Changing to use strtol() broke this.  LONG_MAX is in-band for strtol(),
  any check of it alone is buggy; the inherited check of it was nonsense.
- style bug: nonsense use of a temporary variable.  ultmp exists and has
  type u_long to hold the result of of strtoul(), mainly so that the results
  that don't need to be larger than LONG_MAX can be checked before clobbering
  them by assignment to a non-temporary variable of type long.  Now going
  through ltmp makes no difference since ltmp's type is the same as the
  type of the final variable and there is no reason to preserve the current
  value of the final variable; clobbering has already occurred in strtol()
  (clamp overflowing values to LONG_MAX and set errno to ERANGE to indicate
  the error).
- style bug: no space after '<='

The main bug near here before r340245 and visible in the patch for it and
fixed in r340245 is:
- the hackish range checking doesn't work for negative values unless they
  are large enough to cause overflow as u_longs.  strtoul() converts -n
  by evaluating n as a u_long and negating the result.  So small negative
  values were detected as errors after becoming > LONG_MAX, but values
  between about -(double)ULONG_MAX and LONG_MIN wee not detected as errors
  after becoming <= LONG_MAX.

The main bugs not near here that are not similar and are not fixed in any
version are:
- in all of the "packet size too large" error messages the converted value
  is printed (in decimal) instead of the arg (quoted).  Simpler messages
  like the one visible in the above patch just print the arg, and they
  even quote the arg consistently.  The arg may have leading whitespace or
  signs, or a non-decimal base, and then printing its converted value in
  decimal obfuscates it.  This is the main bug used to justify r340245.
  After not detecting some negative values, they were misprinted as large
  positive values (near ULONG_MAX).

Related style/quality bugs:
- the simpler error message mostly just say "invalid" without distinguishing
  between invalid formats and invalid due to overflow or invalid due to
  being negative or invalid due to failing another range check.  Sometimes,
  often just due to implementation details of the range check, some range
  check failures cause a differently encrypted undocumented exit code
  (EX_NOPERM instead of EX_USAGE) and a different error message with more
  details.
- the "invalid" messages give no hint of the the valid range together no
  hint of range errors in either the message or the exit code
- the man page gives no hint of the valid range for most or all numeric
  args, even for the "packet size too large" case where the error messages
  give the top end of the range (this is a fairly arbitrary limit for non-root
  only; most other cases have a less arbitrary limit of LONG_MAX or INT_MAX).
- the special error handling for "packet size too large" is too fussy unless
  most error handling is done almost perfectly.  The error handling is messy
  enough without it.  The important thing about this case is that it is
  special for non-root, but neither the message nor the man page mentions
  special cases for non-root.  The man page doesn't even mention valid
  ranges for this.  Only the exit code distinguishes this case.  Perfect
  error handling would first distingish sub-cases of EINVAL errors (signs
  and purer gargage), ERANGE errors, and other range check errors with more
  resricted ranges for non-root.  Then print specific messages inclu

svn commit: r341784 - head/sys/dev/sfxge

2018-12-10 Thread Andrew Rybchenko

Author: arybchik
Date: Mon Dec 10 09:35:53 2018
New Revision: 341784
URL: https://svnweb.freebsd.org/changeset/base/341784

Log:
  sfxge(4): prepare the number of Tx queues on event queue 0 to become variable
  
  The number of Tx queues on event queue 0 can depend on the NIC family type,
  and this property will be leveraged by future patches.
  This patch prepares the code for this change.
  
  Submitted by:   Ivan Malov 
  Sponsored by:   Solarflare Communications, Inc.
  MFC after:  1 week
  Differential Revision:  https://reviews.freebsd.org/D18389

Modified:
  head/sys/dev/sfxge/sfxge.c
  head/sys/dev/sfxge/sfxge_ev.c
  head/sys/dev/sfxge/sfxge_tx.c
  head/sys/dev/sfxge/sfxge_tx.h

Modified: head/sys/dev/sfxge/sfxge.c
==
--- head/sys/dev/sfxge/sfxge.c  Mon Dec 10 09:35:45 2018(r341783)
+++ head/sys/dev/sfxge/sfxge.c  Mon Dec 10 09:35:53 2018(r341784)
@@ -151,8 +151,8 @@ sfxge_estimate_rsrc_limits(struct sfxge_softc *sc)
 
limits.edl_min_evq_count = 1;
limits.edl_max_evq_count = evq_max;
-   limits.edl_min_txq_count = SFXGE_TXQ_NTYPES;
-   limits.edl_max_txq_count = evq_max + SFXGE_TXQ_NTYPES - 1;
+   limits.edl_min_txq_count = SFXGE_EVQ0_N_TXQ(sc);
+   limits.edl_max_txq_count = evq_max + SFXGE_EVQ0_N_TXQ(sc) - 1;
limits.edl_min_rxq_count = 1;
limits.edl_max_rxq_count = evq_max;
 
@@ -168,12 +168,12 @@ sfxge_estimate_rsrc_limits(struct sfxge_softc *sc)
return (rc);
}
 
-   KASSERT(txq_allocated >= SFXGE_TXQ_NTYPES,
-   ("txq_allocated < SFXGE_TXQ_NTYPES"));
+   KASSERT(txq_allocated >= SFXGE_EVQ0_N_TXQ(sc),
+   ("txq_allocated < %u", SFXGE_EVQ0_N_TXQ(sc)));
 
sc->evq_max = MIN(evq_allocated, evq_max);
sc->evq_max = MIN(rxq_allocated, sc->evq_max);
-   sc->evq_max = MIN(txq_allocated - (SFXGE_TXQ_NTYPES - 1),
+   sc->evq_max = MIN(txq_allocated - (SFXGE_EVQ0_N_TXQ(sc) - 1),
  sc->evq_max);
 
KASSERT(sc->evq_max <= evq_max,
@@ -205,7 +205,7 @@ sfxge_set_drv_limits(struct sfxge_softc *sc)
limits.edl_min_evq_count = limits.edl_max_evq_count =
sc->intr.n_alloc;
limits.edl_min_txq_count = limits.edl_max_txq_count =
-   sc->intr.n_alloc + SFXGE_TXQ_NTYPES - 1;
+   sc->intr.n_alloc + SFXGE_EVQ0_N_TXQ(sc) - 1;
limits.edl_min_rxq_count = limits.edl_max_rxq_count =
sc->intr.n_alloc;
 

Modified: head/sys/dev/sfxge/sfxge_ev.c
==
--- head/sys/dev/sfxge/sfxge_ev.c   Mon Dec 10 09:35:45 2018
(r341783)
+++ head/sys/dev/sfxge/sfxge_ev.c   Mon Dec 10 09:35:53 2018
(r341784)
@@ -269,9 +269,10 @@ sfxge_get_txq_by_label(struct sfxge_evq *evq, enum sfx
 {
unsigned int index;
 
-   KASSERT((evq->index == 0 && label < SFXGE_TXQ_NTYPES) ||
+   KASSERT((evq->index == 0 && label < SFXGE_EVQ0_N_TXQ(evq->sc)) ||
(label == SFXGE_TXQ_IP_TCP_UDP_CKSUM), ("unexpected txq label"));
-   index = (evq->index == 0) ? label : (evq->index - 1 + SFXGE_TXQ_NTYPES);
+   index = (evq->index == 0) ?
+   label : (evq->index - 1 + SFXGE_EVQ0_N_TXQ(evq->sc));
return (evq->sc->txq[index]);
 }
 

Modified: head/sys/dev/sfxge/sfxge_tx.c
==
--- head/sys/dev/sfxge/sfxge_tx.c   Mon Dec 10 09:35:45 2018
(r341783)
+++ head/sys/dev/sfxge/sfxge_tx.c   Mon Dec 10 09:35:53 2018
(r341784)
@@ -1973,7 +1973,7 @@ sfxge_tx_init(struct sfxge_softc *sc)
goto fail_tx_dpl_put_max;
}
 
-   sc->txq_count = SFXGE_TXQ_NTYPES - 1 + sc->intr.n_alloc;
+   sc->txq_count = SFXGE_EVQ0_N_TXQ(sc) - 1 + sc->intr.n_alloc;
 
sc->tso_fw_assisted = sfxge_tso_fw_assisted;
if ((~encp->enc_features & EFX_FEATURE_FW_ASSISTED_TSO) ||
@@ -2002,9 +2002,9 @@ sfxge_tx_init(struct sfxge_softc *sc)
goto fail2;
 
for (index = 0;
-index < sc->txq_count - SFXGE_TXQ_NTYPES + 1;
+index < sc->txq_count - SFXGE_EVQ0_N_TXQ(sc) + 1;
 index++) {
-   if ((rc = sfxge_tx_qinit(sc, SFXGE_TXQ_NTYPES - 1 + index,
+   if ((rc = sfxge_tx_qinit(sc, SFXGE_EVQ0_N_TXQ(sc) - 1 + index,
SFXGE_TXQ_IP_TCP_UDP_CKSUM, index)) != 0)
goto fail3;
}

Modified: head/sys/dev/sfxge/sfxge_tx.h
==
--- head/sys/dev/sfxge/sfxge_tx.h   Mon Dec 10 09:35:45 2018
(r341783)
+++ head/sys/dev/sfxge/sfxge_tx.h   Mon Dec 10 09:35:53 2018
(r341784)
@@ -139,6 +139,8 @@ enum sfxge_txq_type {
SFXGE_TXQ_NTYPES
 };
 
+#defineSFXGE_EVQ0_N_TXQ(_sc)   SFXGE_TXQ_NTYPES
+
 #defineSFXGE_

svn commit: r341785 - head/sys/dev/sfxge

2018-12-10 Thread Andrew Rybchenko

Author: arybchik
Date: Mon Dec 10 09:36:05 2018
New Revision: 341785
URL: https://svnweb.freebsd.org/changeset/base/341785

Log:
  sfxge(4): use n Tx queues instead of n + 2 on EF10 HW
  
  On EF10 HW we can avoid sending packets without checksum offload
  or with IP-only checksum offload to dedicated queues. Instead, we
  can use option descriptors to change offload policy on any queue
  during runtime. Thus, we don't need to create two dedicated queues.
  
  Submitted by:   Ivan Malov 
  Sponsored by:   Solarflare Communications, Inc.
  MFC after:  1 week
  Differential Revision:  https://reviews.freebsd.org/D18390

Modified:
  head/sys/dev/sfxge/sfxge.c
  head/sys/dev/sfxge/sfxge.h
  head/sys/dev/sfxge/sfxge_ev.c
  head/sys/dev/sfxge/sfxge_tx.c
  head/sys/dev/sfxge/sfxge_tx.h

Modified: head/sys/dev/sfxge/sfxge.c
==
--- head/sys/dev/sfxge/sfxge.c  Mon Dec 10 09:35:53 2018(r341784)
+++ head/sys/dev/sfxge/sfxge.c  Mon Dec 10 09:36:05 2018(r341785)
@@ -762,6 +762,11 @@ sfxge_create(struct sfxge_softc *sc)
}
sc->rxq_entries = sfxge_rx_ring_entries;
 
+   if (efx_nic_cfg_get(enp)->enc_features & EFX_FEATURE_TXQ_CKSUM_OP_DESC)
+   sc->txq_dynamic_cksum_toggle_supported = B_TRUE;
+   else
+   sc->txq_dynamic_cksum_toggle_supported = B_FALSE;
+
if (!ISP2(sfxge_tx_ring_entries) ||
(sfxge_tx_ring_entries < EFX_TXQ_MINNDESCS) ||
(sfxge_tx_ring_entries > efx_nic_cfg_get(enp)->enc_txq_max_ndescs)) 
{

Modified: head/sys/dev/sfxge/sfxge.h
==
--- head/sys/dev/sfxge/sfxge.h  Mon Dec 10 09:35:53 2018(r341784)
+++ head/sys/dev/sfxge/sfxge.h  Mon Dec 10 09:36:05 2018(r341785)
@@ -294,6 +294,8 @@ struct sfxge_softc {
efx_nic_t   *enp;
efsys_lock_tenp_lock;
 
+   boolean_t   txq_dynamic_cksum_toggle_supported;
+
unsigned intrxq_entries;
unsigned inttxq_entries;
 

Modified: head/sys/dev/sfxge/sfxge_ev.c
==
--- head/sys/dev/sfxge/sfxge_ev.c   Mon Dec 10 09:35:53 2018
(r341784)
+++ head/sys/dev/sfxge/sfxge_ev.c   Mon Dec 10 09:36:05 2018
(r341785)
@@ -269,8 +269,11 @@ sfxge_get_txq_by_label(struct sfxge_evq *evq, enum sfx
 {
unsigned int index;
 
-   KASSERT((evq->index == 0 && label < SFXGE_EVQ0_N_TXQ(evq->sc)) ||
-   (label == SFXGE_TXQ_IP_TCP_UDP_CKSUM), ("unexpected txq label"));
+   KASSERT((evq->sc->txq_dynamic_cksum_toggle_supported) ? (label == 0) :
+   ((evq->index == 0 && label < SFXGE_TXQ_NTYPES) ||
+(label == SFXGE_TXQ_IP_TCP_UDP_CKSUM)),
+   ("unexpected txq label"));
+
index = (evq->index == 0) ?
label : (evq->index - 1 + SFXGE_EVQ0_N_TXQ(evq->sc));
return (evq->sc->txq[index]);

Modified: head/sys/dev/sfxge/sfxge_tx.c
==
--- head/sys/dev/sfxge/sfxge_tx.c   Mon Dec 10 09:35:53 2018
(r341784)
+++ head/sys/dev/sfxge/sfxge_tx.c   Mon Dec 10 09:36:05 2018
(r341785)
@@ -35,7 +35,7 @@
 
 /* Theory of operation:
  *
- * Tx queues allocation and mapping
+ * Tx queues allocation and mapping on Siena
  *
  * One Tx queue with enabled checksum offload is allocated per Rx channel
  * (event queue).  Also 2 Tx queues (one without checksum offload and one
@@ -46,6 +46,17 @@
  * if event queue index is 0, TxQ-index = TxQ-label * [0..SFXGE_TXQ_NTYPES)
  * else TxQ-index = SFXGE_TXQ_NTYPES + EvQ-index - 1
  * See sfxge_get_txq_by_label() sfxge_ev.c
+ *
+ * Tx queue allocation and mapping on EF10
+ *
+ * One Tx queue with enabled checksum offload is allocated per Rx
+ * channel (event queue). Checksum offload on all Tx queues is enabled or
+ * disabled dynamically by inserting option descriptors, so the additional
+ * queues used on Siena are not required.
+ *
+ * TxQ label is always set to zero on EF10 hardware.
+ * So, event queue to Tx queue mapping is simple:
+ * TxQ-index = EvQ-index
  */
 
 #include 
@@ -139,38 +150,75 @@ static void sfxge_tx_qlist_post(struct sfxge_txq *txq)
 static void sfxge_tx_qunblock(struct sfxge_txq *txq);
 static int sfxge_tx_queue_tso(struct sfxge_txq *txq, struct mbuf *mbuf,
  const bus_dma_segment_t *dma_seg, int n_dma_seg,
- int vlan_tagged);
+ int n_extra_descs);
 
+static inline void
+sfxge_next_stmp(struct sfxge_txq *txq, struct sfxge_tx_mapping **pstmp)
+{
+   KASSERT((*pstmp)->flags == 0, ("stmp flags are not 0"));
+   if (__predict_false(*pstmp ==
+   &txq->stmp[txq->ptr_mask]))
+

svn commit: r341786 - in head/sys/dev: rtwn/usb usb usb/wlan

2018-12-10 Thread Andriy Voskoboinyk

Author: avos
Date: Mon Dec 10 09:45:57 2018
New Revision: 341786
URL: https://svnweb.freebsd.org/changeset/base/341786

Log:
  rtwn, rsu: add more USB ids.
  
  PR:   233638
  Submitted by: cezary.sl...@gmail.com
  MFC after:3 days

Modified:
  head/sys/dev/rtwn/usb/rtwn_usb_attach.h
  head/sys/dev/usb/usbdevs
  head/sys/dev/usb/wlan/if_rsu.c

Modified: head/sys/dev/rtwn/usb/rtwn_usb_attach.h
==
--- head/sys/dev/rtwn/usb/rtwn_usb_attach.h Mon Dec 10 09:36:05 2018
(r341785)
+++ head/sys/dev/rtwn/usb/rtwn_usb_attach.h Mon Dec 10 09:45:57 2018
(r341786)
@@ -118,6 +118,7 @@ static const STRUCT_USB_HOST_ID rtwn_devs[] = {
RTWN_RTL8188EU_DEV(DLINK,   DWA123D1),
RTWN_RTL8188EU_DEV(DLINK,   DWA125D1),
RTWN_RTL8188EU_DEV(ELECOM,  WDC150SU2M),
+   RTWN_RTL8188EU_DEV(TPLINK,  WN722N),
RTWN_RTL8188EU_DEV(REALTEK, RTL8188ETV),
RTWN_RTL8188EU_DEV(REALTEK, RTL8188EU),
 #undef RTWN_RTL8188EU_DEV

Modified: head/sys/dev/usb/usbdevs
==
--- head/sys/dev/usb/usbdevsMon Dec 10 09:36:05 2018(r341785)
+++ head/sys/dev/usb/usbdevsMon Dec 10 09:45:57 2018(r341786)
@@ -4346,6 +4346,7 @@ product SITECOMEU RT3072_40x0048  RT3072
 product SITECOMEU RT3072_5 0x004a  RT3072
 product SITECOMEU WL349V1  0x004b  WL-349 v1
 product SITECOMEU RT3072_6 0x004d  RT3072
+product SITECOMEU WLA1000  0x005b  WLA-1000
 product SITECOMEU RTL8188CU_1  0x0052  RTL8188CU
 product SITECOMEU RTL8188CU_2  0x005c  RTL8188CU
 product SITECOMEU RTL8192CU0x0061  RTL8192CU
@@ -4611,6 +4612,7 @@ product TOSHIBA TRANSMEMORY   0x6545  USB ThumbDrive
 product TPLINK T4U 0x0101  Archer T4U
 product TPLINK WN822NV40x0108  TL-WN822N v4
 product TPLINK WN823NV20x0109  TL-WN823N v2
+product TPLINK WN722N  0x010c  TL-WN722N
 product TPLINK T4UV2   0x010d  Archer T4U ver 2
 product TPLINK T4UHV2  0x010e  Archer T4UH ver 2
 product TPLINK RTL8153 0x0601  RTL8153 USB 10/100/1000 LAN

Modified: head/sys/dev/usb/wlan/if_rsu.c
==
--- head/sys/dev/usb/wlan/if_rsu.c  Mon Dec 10 09:36:05 2018
(r341785)
+++ head/sys/dev/usb/wlan/if_rsu.c  Mon Dec 10 09:45:57 2018
(r341786)
@@ -114,6 +114,7 @@ static const STRUCT_USB_HOST_ID rsu_devs[] = {
   RSU_HT_NOT_SUPPORTED) }
RSU_DEV(ASUS,   RTL8192SU),
RSU_DEV(AZUREWAVE,  RTL8192SU_4),
+   RSU_DEV(SITECOMEU,  WLA1000),
RSU_DEV_HT(ACCTON,  RTL8192SU),
RSU_DEV_HT(ASUS,USBN10),
RSU_DEV_HT(AZUREWAVE,   RTL8192SU_1),
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341787 - in head/sys: arm/include mips/include powerpc/include

2018-12-10 Thread Hans Petter Selasky

Author: hselasky
Date: Mon Dec 10 13:38:13 2018
New Revision: 341787
URL: https://svnweb.freebsd.org/changeset/base/341787

Log:
  Implement atomic_swap_xxx() for all platforms.
  
  Differential Revision:https://reviews.freebsd.org/D18450
  Reviewed by:  kib@
  MFC after:3 days
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/arm/include/atomic.h
  head/sys/mips/include/atomic.h
  head/sys/powerpc/include/atomic.h

Modified: head/sys/arm/include/atomic.h
==
--- head/sys/arm/include/atomic.h   Mon Dec 10 09:45:57 2018
(r341786)
+++ head/sys/arm/include/atomic.h   Mon Dec 10 13:38:13 2018
(r341787)
@@ -55,6 +55,13 @@
 #include 
 #endif /* Arch >= v6 */
 
+static __inline u_long
+atomic_swap_long(volatile u_long *p, u_long v)
+{
+
+   return (atomic_swap_32((volatile uint32_t *)p, v));
+}
+
 #define atomic_clear_ptr   atomic_clear_32
 #define atomic_clear_acq_ptr   atomic_clear_acq_32
 #define atomic_clear_rel_ptr   atomic_clear_rel_32

Modified: head/sys/mips/include/atomic.h
==
--- head/sys/mips/include/atomic.h  Mon Dec 10 09:45:57 2018
(r341786)
+++ head/sys/mips/include/atomic.h  Mon Dec 10 13:38:13 2018
(r341787)
@@ -755,4 +755,68 @@ atomic_thread_fence_seq_cst(void)
 #defineatomic_store_rel_ptratomic_store_rel_long
 #defineatomic_readandclear_ptr atomic_readandclear_long
 
+static __inline unsigned int
+atomic_swap_int(volatile unsigned int *ptr, const unsigned int value)
+{
+   unsigned int retval;
+
+   retval = *ptr;
+
+   while (!atomic_fcmpset_int(ptr, &retval, value))
+   ;
+   return (retval);
+}
+
+static __inline uint32_t
+atomic_swap_32(volatile uint32_t *ptr, const uint32_t value)
+{
+   uint32_t retval;
+
+   retval = *ptr;
+
+   while (!atomic_fcmpset_32(ptr, &retval, value))
+   ;
+   return (retval);
+}
+
+#if defined(__mips_n64) || defined(__mips_n32)
+static __inline uint64_t
+atomic_swap_64(volatile uint64_t *ptr, const uint64_t value)
+{
+   uint64_t retval;
+
+   retval = *ptr;
+
+   while (!atomic_fcmpset_64(ptr, &retval, value))
+   ;
+   return (retval);
+}
+#endif
+
+static __inline unsigned long
+atomic_swap_long(volatile unsigned long *ptr, const unsigned long value)
+{
+   unsigned long retval;
+
+   retval = *ptr;
+
+   while (!atomic_fcmpset_32((volatile uint32_t *)ptr,
+   (uint32_t *)&retval, value))
+   ;
+   return (retval);
+}
+
+static __inline uintptr_t
+atomic_swap_ptr(volatile uintptr_t *ptr, const uintptr_t value)
+{
+   uintptr_t retval;
+
+   retval = *ptr;
+
+   while (!atomic_fcmpset_32((volatile uint32_t *)ptr,
+   (uint32_t *)&retval, value))
+   ;
+   return (retval);
+}
+
 #endif /* ! _MACHINE_ATOMIC_H_ */

Modified: head/sys/powerpc/include/atomic.h
==
--- head/sys/powerpc/include/atomic.h   Mon Dec 10 09:45:57 2018
(r341786)
+++ head/sys/powerpc/include/atomic.h   Mon Dec 10 13:38:13 2018
(r341787)
@@ -852,6 +852,9 @@ atomic_swap_64(volatile u_long *p, u_long v)
 #defineatomic_fetchadd_64  atomic_fetchadd_long
 #defineatomic_swap_longatomic_swap_64
 #defineatomic_swap_ptr atomic_swap_64
+#else
+#defineatomic_swap_long(p,v)   atomic_swap_32((volatile u_int *)(p), v)
+#defineatomic_swap_ptr(p,v)atomic_swap_32((volatile u_int *)(p), v)
 #endif
 
 #undef __ATOMIC_REL
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341789 - head/sys/compat/linuxkpi/common/include/asm

2018-12-10 Thread Hans Petter Selasky

Author: hselasky
Date: Mon Dec 10 13:41:33 2018
New Revision: 341789
URL: https://svnweb.freebsd.org/changeset/base/341789

Log:
  Remove no longer needed ifdefs in the LinuxKPI, after r341787.
  
  Differential Revision:https://reviews.freebsd.org/D18450
  Reviewed by:  kib@
  MFC after:3 days
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/compat/linuxkpi/common/include/asm/atomic-long.h
  head/sys/compat/linuxkpi/common/include/asm/atomic.h

Modified: head/sys/compat/linuxkpi/common/include/asm/atomic-long.h
==
--- head/sys/compat/linuxkpi/common/include/asm/atomic-long.h   Mon Dec 10 
13:41:28 2018(r341788)
+++ head/sys/compat/linuxkpi/common/include/asm/atomic-long.h   Mon Dec 10 
13:41:33 2018(r341789)
@@ -78,15 +78,7 @@ atomic_long_dec(atomic_long_t *v)
 static inline long
 atomic_long_xchg(atomic_long_t *v, long val)
 {
-#if defined(__i386__) || defined(__amd64__) || defined(__aarch64__)
return atomic_swap_long(&v->counter, val);
-#else
-   long ret = atomic_long_read(v);
-
-   while (!atomic_fcmpset_long(&v->counter, &ret, val))
-   ;
-   return (ret);
-#endif
 }
 
 static inline long

Modified: head/sys/compat/linuxkpi/common/include/asm/atomic.h
==
--- head/sys/compat/linuxkpi/common/include/asm/atomic.hMon Dec 10 
13:41:28 2018(r341788)
+++ head/sys/compat/linuxkpi/common/include/asm/atomic.hMon Dec 10 
13:41:33 2018(r341789)
@@ -128,15 +128,7 @@ atomic_clear_mask(unsigned int mask, atomic_t *v)
 static inline int
 atomic_xchg(atomic_t *v, int i)
 {
-#if !defined(__mips__)
return (atomic_swap_int(&v->counter, i));
-#else
-   int ret = atomic_read(v);
-
-   while (!atomic_fcmpset_int(&v->counter, &ret, i))
-   ;
-   return (ret);
-#endif
 }
 
 static inline int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341795 - head/sbin/ping

2018-12-10 Thread Eugene Grosbein

Author: eugen
Date: Mon Dec 10 14:39:21 2018
New Revision: 341795
URL: https://svnweb.freebsd.org/changeset/base/341795

Log:
  ping(8): add space after "<=" as per style(9).
  
  MFC after:1 week
  X-MFC-with:   r341768

Modified:
  head/sbin/ping/ping.c

Modified: head/sbin/ping/ping.c
==
--- head/sbin/ping/ping.c   Mon Dec 10 14:24:41 2018(r341794)
+++ head/sbin/ping/ping.c   Mon Dec 10 14:39:21 2018(r341795)
@@ -313,7 +313,7 @@ main(int argc, char *const *argv)
break;
case 'c':
ltmp = strtol(optarg, &ep, 0);
-   if (*ep || ep == optarg || ltmp <=0)
+   if (*ep || ep == optarg || ltmp <= 0)
errx(EX_USAGE,
"invalid count of packets to transmit: 
`%s'",
optarg);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341796 - head

2018-12-10 Thread Ed Maste

Author: emaste
Date: Mon Dec 10 14:50:11 2018
New Revision: 341796
URL: https://svnweb.freebsd.org/changeset/base/341796

Log:
  Clean stale wpa dependencies and objects after r341759
  
  The wpa update added some source files with the same name as a file in
  another directory (found via .PATH in the previous version).  Having a
  stale entry in a .depend file means the new file won't be built, so test
  for this case and if found remove all of wpa's dependency files.
  
  MFC with: r341759
  Sponsored by: The FreeBSD Foundation

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Mon Dec 10 14:39:21 2018(r341795)
+++ head/Makefile.inc1  Mon Dec 10 14:50:11 2018(r341796)
@@ -977,6 +977,14 @@ _cleanobj_fast_depend_hack: .PHONY
rm -f ${OBJTOP}/usr.sbin/ntp/libntpevent/.depend.*; \
fi
 
+# 20181209  r341759 track migration across wpa update
+   @if [ -e "${OBJTOP}/usr.sbin/wpa/wpa_supplicant/.depend.rrm.o" ] && \
+   egrep -q 'src/ap/rrm.c' \
+   ${OBJTOP}/usr.sbin/wpa/wpa_supplicant/.depend.rrm.o; then \
+   echo "Removing stale wpa dependencies and objects"; \
+   rm -f ${OBJTOP}/usr.sbin/wpa/*/.depend*; \
+   fi
+
 _worldtmp: .PHONY
@echo
@echo "--"
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341797 - in head/sys/powerpc: aim include powerpc

2018-12-10 Thread Leandro Lupori

Author: luporl
Date: Mon Dec 10 14:54:28 2018
New Revision: 341797
URL: https://svnweb.freebsd.org/changeset/base/341797

Log:
  ppc64: handle exception 0x1500 (soft patch)
  
  This change adds a hypervisor trap handler for exception 0x1500 (soft patch),
  normalizing all VSX registers and returning.
  This avoids a kernel panic due to unknown exception.
  
  Change made with the collaboration of leonardo.bianconi_eldorado.org.br,
  that found out that this is a hypervisor exception and not a supervisor one,
  and fixed this in the code.
  
  Reviewed by:  jhibbits, sbruno
  Differential Revision:https://reviews.freebsd.org/D17806

Modified:
  head/sys/powerpc/aim/aim_machdep.c
  head/sys/powerpc/include/trap.h
  head/sys/powerpc/powerpc/db_trace.c
  head/sys/powerpc/powerpc/trap.c

Modified: head/sys/powerpc/aim/aim_machdep.c
==
--- head/sys/powerpc/aim/aim_machdep.c  Mon Dec 10 14:50:11 2018
(r341796)
+++ head/sys/powerpc/aim/aim_machdep.c  Mon Dec 10 14:54:28 2018
(r341797)
@@ -366,6 +366,7 @@ aim_cpu_init(vm_offset_t toc)
bcopy(&hypertrapcode, (void *)(EXC_HEA + trap_offset), trapsize);
bcopy(&hypertrapcode, (void *)(EXC_HMI + trap_offset), trapsize);
bcopy(&hypertrapcode, (void *)(EXC_HVI + trap_offset), trapsize);
+   bcopy(&hypertrapcode, (void *)(EXC_SOFT_PATCH + trap_offset), trapsize);
#endif
 
bcopy(&rstcode, (void *)(EXC_RST + trap_offset), (size_t)&rstcodeend -

Modified: head/sys/powerpc/include/trap.h
==
--- head/sys/powerpc/include/trap.h Mon Dec 10 14:50:11 2018
(r341796)
+++ head/sys/powerpc/include/trap.h Mon Dec 10 14:54:28 2018
(r341797)
@@ -103,6 +103,9 @@
 #defineEXC_SPFPD   0x2f30  /* SPE Floating-point Data */
 #defineEXC_SPFPR   0x2f40  /* SPE Floating-point Round */
 
+/* POWER8 */
+#define EXC_SOFT_PATCH 0x1500  /* POWER8 Soft Patch Exception */
+
 #defineEXC_LAST0x2f00  /* Last possible exception 
vector */
 
 #defineEXC_AST 0x3000  /* Fake AST vector */

Modified: head/sys/powerpc/powerpc/db_trace.c
==
--- head/sys/powerpc/powerpc/db_trace.c Mon Dec 10 14:50:11 2018
(r341796)
+++ head/sys/powerpc/powerpc/db_trace.c Mon Dec 10 14:54:28 2018
(r341797)
@@ -255,6 +255,7 @@ db_backtrace(struct thread *td, db_addr_t fp, int coun
case EXC_DECR: trapstr = "DECR"; break;
case EXC_PERF: trapstr = "PERF"; break;
case EXC_VSX: trapstr = "VSX"; break;
+   case EXC_SOFT_PATCH: trapstr = "SOFT_PATCH"; break;
default: trapstr = NULL; break;
}
if (trapstr != NULL) {

Modified: head/sys/powerpc/powerpc/trap.c
==
--- head/sys/powerpc/powerpc/trap.c Mon Dec 10 14:50:11 2018
(r341796)
+++ head/sys/powerpc/powerpc/trap.c Mon Dec 10 14:54:28 2018
(r341797)
@@ -95,6 +95,7 @@ static void   syscall(struct trapframe *frame);
voidhandle_kernel_slb_spill(int, register_t, register_t);
 static int handle_user_slb_spill(pmap_t pm, vm_offset_t addr);
 extern int n_slbs;
+static voidnormalize_inputs(void);
 #endif
 
 extern vm_offset_t __startkernel;
@@ -147,6 +148,7 @@ static struct powerpc_exception powerpc_exceptions[] =
{ EXC_VECAST_G4,"altivec assist" },
{ EXC_THRM, "thermal management" },
{ EXC_RUNMODETRC,   "run mode/trace" },
+   { EXC_SOFT_PATCH, "soft patch exception" },
{ EXC_LAST, NULL }
 };
 
@@ -382,6 +384,17 @@ trap(struct trapframe *frame)
ucode = BUS_OBJERR;
break;
 
+#if defined(__powerpc64__) && defined(AIM)
+   case EXC_SOFT_PATCH:
+   /*
+* Point to the instruction that generated the 
exception to execute it again,
+* and normalize the register values.
+*/
+   frame->srr0 -= 4;
+   normalize_inputs();
+   break;
+#endif
+
default:
trap_fatal(frame);
}
@@ -908,6 +921,49 @@ fix_unaligned(struct thread *td, struct trapframe *fra
 
return (-1);
 }
+
+#if defined(__powerpc64__) && defined(AIM)
+#define MSKNSHL(x, m, n) "(((" #x ") & " #m ") << " #n ")"
+#define MSKNSHR(x, m, n) "(((" #x ") & " #m ") >> " #n ")"
+
+/* xvcpsgndp instruction, built in opcode format.
+ * This can be changed to use mnemonic after a toolchain update.
+ */
+#define XVCPSGNDP(xt, xa, xb

Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-10 Thread Ed Maste

On Sun, 9 Dec 2018 at 02:08, Cy Schubert  wrote:
>
> In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy Schubert
> writes:
> > Author: cy
> > Date: Sun Dec  9 06:45:49 2018
> > New Revision: 341759
> > URL: https://svnweb.freebsd.org/changeset/base/341759
> >
> > Log:
> >   MFV r341618:
> >
> >   Update wpa 2.6 --> 2.7.
>
> In order to build this cleanly, artifacts from wpa 2.6 need to be
> removed first. Either build using a clean /usr/obj or if building using
> -DNO_CLEAN, rm -rf /usr/obj/opt/src/svn-current/*/usr.sbin/wpa first.

We've been able to build with -DNO_CLEAN for about a year and a half;
I added automatic cleanup of old dependencies for this wpa update in
r341796.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341798 - head/sbin/ipfw

2018-12-10 Thread Andrey V. Elsukov

Author: ae
Date: Mon Dec 10 15:42:13 2018
New Revision: 341798
URL: https://svnweb.freebsd.org/changeset/base/341798

Log:
  Use correct size for IPv4 address in gethostbyaddr().
  
  When u_long is 8 bytes, it returns EINVAL and 'ipfw -N show' doesn't work.
  
  Reported by:  Claudio Eichenberger 
  MFC after:1 week

Modified:
  head/sbin/ipfw/ipfw2.c

Modified: head/sbin/ipfw/ipfw2.c
==
--- head/sbin/ipfw/ipfw2.c  Mon Dec 10 14:54:28 2018(r341797)
+++ head/sbin/ipfw/ipfw2.c  Mon Dec 10 15:42:13 2018(r341798)
@@ -1256,7 +1256,8 @@ print_ip(struct buf_pr *bp, const struct format_opts *
(cmd->o.opcode == O_IP_SRC || cmd->o.opcode == O_IP_DST) ?
32 : contigmask((uint8_t *)&(a[1]), 32);
if (mb == 32 && co.do_resolv)
-   he = gethostbyaddr((char *)&(a[0]), sizeof(u_long), AF_INET);
+   he = gethostbyaddr((char *)&(a[0]), sizeof(in_addr_t),
+   AF_INET);
if (he != NULL) /* resolved to name */
bprintf(bp, "%s", he->h_name);
else if (mb == 0)   /* any */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341799 - head/sbin/ipfw

2018-12-10 Thread Andrey V. Elsukov

Author: ae
Date: Mon Dec 10 16:23:11 2018
New Revision: 341799
URL: https://svnweb.freebsd.org/changeset/base/341799

Log:
  Rework how protocol number is tracked in rule. Save it when O_PROTO
  opcode will be printed. This should solve the problem, when protocol
  name is not printed in `ipfw -N show`.
  
  Reported by:  Claudio Eichenberger 
  MFC after:1 week

Modified:
  head/sbin/ipfw/ipfw2.c

Modified: head/sbin/ipfw/ipfw2.c
==
--- head/sbin/ipfw/ipfw2.c  Mon Dec 10 15:42:13 2018(r341798)
+++ head/sbin/ipfw/ipfw2.c  Mon Dec 10 16:23:11 2018(r341799)
@@ -1511,6 +1511,7 @@ print_instruction(struct buf_pr *bp, const struct form
bprintf(bp, " %s", pe->p_name);
else
bprintf(bp, " %u", cmd->arg1);
+   state->proto = cmd->arg1;
break;
case O_MACADDR2:
print_mac(bp, insntod(cmd, mac));
@@ -1992,10 +1993,10 @@ print_proto(struct buf_pr *bp, struct format_opts *fo,
 struct show_state *state)
 {
ipfw_insn *cmd;
-   int l, proto, ip4, ip6, tmp;
+   int l, proto, ip4, ip6;
 
/* Count all O_PROTO, O_IP4, O_IP6 instructions. */
-   proto = tmp = ip4 = ip6 = 0;
+   proto = ip4 = ip6 = 0;
for (l = state->rule->act_ofs, cmd = state->rule->cmd;
l > 0; l -= F_LEN(cmd), cmd += F_LEN(cmd)) {
switch (cmd->opcode) {
@@ -2031,18 +2032,13 @@ print_proto(struct buf_pr *bp, struct format_opts *fo,
if (cmd == NULL || (cmd->len & F_OR))
for (l = proto; l > 0; l--) {
cmd = print_opcode(bp, fo, state, O_PROTO);
-   if (cmd != NULL && (cmd->len & F_OR) == 0)
+   if (cmd == NULL || (cmd->len & F_OR) == 0)
break;
-   tmp = cmd->arg1;
}
/* Initialize proto, it is used by print_newports() */
-   if (tmp != 0)
-   state->proto = tmp;
-   else if (ip6 != 0)
-   state->proto = IPPROTO_IPV6;
-   else
-   state->proto = IPPROTO_IP;
state->flags |= HAVE_PROTO;
+   if (state->proto == 0 && ip6 != 0)
+   state->proto = IPPROTO_IPV6;
 }
 
 static int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-10 Thread Ian Lepore

On Sun, 2018-12-09 at 23:47 -0700, Warner Losh wrote:
> On Sun, Dec 9, 2018, 11:40 PM Cy Schubert  wrote:
> 
> > 
> > In message <201812100619.wba6jb0c064...@pdx.rh.cn85.dnsmgr.net>,
> > "Rodney W. Gri
> > mes" writes:
> > > 
> > > > 
> > > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter <
> > oliver.pin...@hardenedbsd.org
> > > 
> > > > 
> > > > 
> > > > wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On Sunday, December 9, 2018, Warner Losh 
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes <
> > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > In message <201812090645.wb96jnso066...@repo.freebsd.or
> > > > > > > > g>, Cy
> > > > > > Schubert
> > > > > > > 
> > > > > > > > 
> > > > > > > > writes:
> > > > > > > > > 
> > > > > > > > > Author: cy
> > > > > > > > > Date: Sun Dec  9 06:45:49 2018
> > > > > > > > > New Revision: 341759
> > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/341759
> > > > > > > > > 
> > > > > > > > > Log:
> > > > > > > > >   MFV r341618:
> > > > > > > > > 
> > > > > > > > >   Update wpa 2.6 --> 2.7.
> > > > > > > > Relnotes: yes
> > > > > > > As an FYI, or maybe a new procedure, doing a reply to
> > > > > > > a commit message adding relnotes: yes does very little
> > > > > > > to insure that this commit gets refered to in release
> > > > > > > notes.
> > > > > > > 
> > > > > > > What about we add RELNOTES.missed to the tree
> > > > > > > next to UPDATING, and when someone forgets to tag
> > > > > > > the Relnotes:yes into a commit you just follow up
> > > > > > > with a commit to that file, stating the svn revision
> > > > > > > which was missing the note and then we have a nice
> > > > > > > documented and clean way to extract the missing
> > > > > > > release note items, rather than trying to cull it
> > > > > > > from a thread in a mail list archive.
> > > > > > > 
> > > > > > > The file would get truncated to 0 at appropriate
> > > > > > > times on various branches.
> > > > > > > 
> > > > > > How about just RELNOTES. You put the revision that is
> > > > > > relevant and
> > a qui
> > > 
> > > ck
> > > > 
> > > > > 
> > > > > > 
> > > > > > blurb. That way we don't have to look in two places. All
> > > > > > release
> > notes g
> > > 
> > > o
> > > > 
> > > > > 
> > > > > > 
> > > > > > in here, no exceptions. You can retroactively tag them, or
> > > > > > you can
> > commi
> > > 
> > > t
> > > > 
> > > > > 
> > > > > > 
> > > > > > this as part of commit.
> > > My one concern is that if we remove the Relnotes: yes line
> > > from the commits then we may end up totally ignoring the
> > > need to put entries in RELNOTES, which unlike UPDATING
> > > do not have consequences if ignored.
> > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > I don't really know SVN, but there wouldn't be a chicken egg
> > > > > probem
> > durin
> > > 
> > > g
> > > > 
> > > > > 
> > > > > commit time? I mean you would really know the SVN id. So you
> > > > > could
> > only a
> > > 
> > > dd
> > > > 
> > > > > 
> > > > > a specific revision in a different commit to RELEASE file.
> > > > > 
> > > > Generally, you can guess really well, and fix it in the case of
> > > > a lost
> > race
> > > 
> > > > 
> > > > easily.
> > > No reason to guess, if you add the RELNOTES change with the
> > > commit
> > > then it is the revision that added the RELNOTES entry, so a log
> > > view
> > > of RELNOTES would show you the revision.  If you do it after
> > > words
> > > or edit an existing entry in the RELNOTES file that is also
> > > fairly
> > > clear as that commit has no other files touched.
> > > 
> > > > 
> > > > 
> > > > You'd add the release notes text in full to the file, with a
> > > > pointer
> > to the
> > > 
> > > > 
> > > > revision(s) for the feature.
> > > If you modify RELNOTES with the commit adding the feature we
> > > could easily use a pointer of "this commit", the svn version
> > > number
> > > of that added entry is self referencing to the actual change,
> > > which I actually rather like the idea of.
> > > 
> > > > 
> > > > 
> > > > Warner
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Have a blurb at the top that tells people what
> > > > > > order to add them in, and you'd be set. We'd then retire
> > > > > > "relnotes:
> > yes"
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > in
> > > > > > the commit message. This would also allow 'helpers' to
> > > > > > format the
> > RELNOT
> > > 
> > > ES
> > > > 
> > > > > 
> > > > > > 
> > > > > > file as we go rather than having to play 2 years of catch-
> > > > > > up at
> > major
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > branch times.
> > > Yes.  You could actually "delete" an entry from RELNOTES once a
> > > proper entry in the actual release notes had been created, such
> > > that RELNOTES is really a list of pending items.
> > > 
> > > > 
> > > > > 
> > > > >

Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-10 Thread Rodney W. Grimes

> On Sun, 2018-12-09 at 23:47 -0700, Warner Losh wrote:
> > On Sun, Dec 9, 2018, 11:40 PM Cy Schubert  > wrote:
> > 
> > > 
> > > In message <201812100619.wba6jb0c064...@pdx.rh.cn85.dnsmgr.net>,
> > > "Rodney W. Gri
> > > mes" writes:
> > > > 
> > > > > 
> > > > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter <
> > > oliver.pin...@hardenedbsd.org
> > > > 
> > > > > 
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sunday, December 9, 2018, Warner Losh 
> > > > > > wrote:
> > > > > > 
> > > > > > > 
> > > > > > > On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes <
> > > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > In message <201812090645.wb96jnso066...@repo.freebsd.or
> > > > > > > > > g>, Cy
> > > > > > > Schubert
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > writes:
> > > > > > > > > > 
> > > > > > > > > > Author: cy
> > > > > > > > > > Date: Sun Dec??9 06:45:49 2018
> > > > > > > > > > New Revision: 341759
> > > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/341759
> > > > > > > > > > 
> > > > > > > > > > Log:
> > > > > > > > > > ? MFV r341618:
> > > > > > > > > > 
> > > > > > > > > > ? Update wpa 2.6 --> 2.7.
> > > > > > > > > Relnotes: yes
> > > > > > > > As an FYI, or maybe a new procedure, doing a reply to
> > > > > > > > a commit message adding relnotes: yes does very little
> > > > > > > > to insure that this commit gets refered to in release
> > > > > > > > notes.
> > > > > > > > 
> > > > > > > > What about we add RELNOTES.missed to the tree
> > > > > > > > next to UPDATING, and when someone forgets to tag
> > > > > > > > the Relnotes:yes into a commit you just follow up
> > > > > > > > with a commit to that file, stating the svn revision
> > > > > > > > which was missing the note and then we have a nice
> > > > > > > > documented and clean way to extract the missing
> > > > > > > > release note items, rather than trying to cull it
> > > > > > > > from a thread in a mail list archive.
> > > > > > > > 
> > > > > > > > The file would get truncated to 0 at appropriate
> > > > > > > > times on various branches.
> > > > > > > > 
> > > > > > > How about just RELNOTES. You put the revision that is
> > > > > > > relevant and
> > > a qui
> > > > 
> > > > ck
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > blurb. That way we don't have to look in two places. All
> > > > > > > release
> > > notes g
> > > > 
> > > > o
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > in here, no exceptions. You can retroactively tag them, or
> > > > > > > you can
> > > commi
> > > > 
> > > > t
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > this as part of commit.
> > > > My one concern is that if we remove the Relnotes: yes line
> > > > from the commits then we may end up totally ignoring the
> > > > need to put entries in RELNOTES, which unlike UPDATING
> > > > do not have consequences if ignored.
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > I don't really know SVN, but there wouldn't be a chicken egg
> > > > > > probem
> > > durin
> > > > 
> > > > g
> > > > > 
> > > > > > 
> > > > > > commit time? I mean you would really know the SVN id. So you
> > > > > > could
> > > only a
> > > > 
> > > > dd
> > > > > 
> > > > > > 
> > > > > > a specific revision in a different commit to RELEASE file.
> > > > > > 
> > > > > Generally, you can guess really well, and fix it in the case of
> > > > > a lost
> > > race
> > > > 
> > > > > 
> > > > > easily.
> > > > No reason to guess, if you add the RELNOTES change with the
> > > > commit
> > > > then it is the revision that added the RELNOTES entry, so a log
> > > > view
> > > > of RELNOTES would show you the revision.??If you do it after
> > > > words
> > > > or edit an existing entry in the RELNOTES file that is also
> > > > fairly
> > > > clear as that commit has no other files touched.
> > > > 
> > > > > 
> > > > > 
> > > > > You'd add the release notes text in full to the file, with a
> > > > > pointer
> > > to the
> > > > 
> > > > > 
> > > > > revision(s) for the feature.
> > > > If you modify RELNOTES with the commit adding the feature we
> > > > could easily use a pointer of "this commit", the svn version
> > > > number
> > > > of that added entry is self referencing to the actual change,
> > > > which I actually rather like the idea of.
> > > > 
> > > > > 
> > > > > 
> > > > > Warner
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Have a blurb at the top that tells people what
> > > > > > > order to add them in, and you'd be set. We'd then retire
> > > > > > > "relnotes:
> > > yes"
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > in
> > > > > > > the commit message. This would also allow 'helpers' to
> > > > > > > format the
> > > RELNOT
> > > > 
> > > > ES
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > file as we go rather than having to play 2 y

Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-10 Thread Warner Losh

On Mon, Dec 10, 2018 at 10:14 AM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Sun, 2018-12-09 at 23:47 -0700, Warner Losh wrote:
> > > On Sun, Dec 9, 2018, 11:40 PM Cy Schubert  > > wrote:
> > >
> > > >
> > > > In message <201812100619.wba6jb0c064...@pdx.rh.cn85.dnsmgr.net>,
> > > > "Rodney W. Gri
> > > > mes" writes:
> > > > >
> > > > > >
> > > > > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter <
> > > > oliver.pin...@hardenedbsd.org
> > > > >
> > > > > >
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sunday, December 9, 2018, Warner Losh 
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes <
> > > > > > > > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > In message <201812090645.wb96jnso066...@repo.freebsd.or
> > > > > > > > > > g>, Cy
> > > > > > > > Schubert
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > writes:
> > > > > > > > > > >
> > > > > > > > > > > Author: cy
> > > > > > > > > > > Date: Sun Dec??9 06:45:49 2018
> > > > > > > > > > > New Revision: 341759
> > > > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/341759
> > > > > > > > > > >
> > > > > > > > > > > Log:
> > > > > > > > > > > ? MFV r341618:
> > > > > > > > > > >
> > > > > > > > > > > ? Update wpa 2.6 --> 2.7.
> > > > > > > > > > Relnotes: yes
> > > > > > > > > As an FYI, or maybe a new procedure, doing a reply to
> > > > > > > > > a commit message adding relnotes: yes does very little
> > > > > > > > > to insure that this commit gets refered to in release
> > > > > > > > > notes.
> > > > > > > > >
> > > > > > > > > What about we add RELNOTES.missed to the tree
> > > > > > > > > next to UPDATING, and when someone forgets to tag
> > > > > > > > > the Relnotes:yes into a commit you just follow up
> > > > > > > > > with a commit to that file, stating the svn revision
> > > > > > > > > which was missing the note and then we have a nice
> > > > > > > > > documented and clean way to extract the missing
> > > > > > > > > release note items, rather than trying to cull it
> > > > > > > > > from a thread in a mail list archive.
> > > > > > > > >
> > > > > > > > > The file would get truncated to 0 at appropriate
> > > > > > > > > times on various branches.
> > > > > > > > >
> > > > > > > > How about just RELNOTES. You put the revision that is
> > > > > > > > relevant and
> > > > a qui
> > > > >
> > > > > ck
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > blurb. That way we don't have to look in two places. All
> > > > > > > > release
> > > > notes g
> > > > >
> > > > > o
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > in here, no exceptions. You can retroactively tag them, or
> > > > > > > > you can
> > > > commi
> > > > >
> > > > > t
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > this as part of commit.
> > > > > My one concern is that if we remove the Relnotes: yes line
> > > > > from the commits then we may end up totally ignoring the
> > > > > need to put entries in RELNOTES, which unlike UPDATING
> > > > > do not have consequences if ignored.
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > I don't really know SVN, but there wouldn't be a chicken egg
> > > > > > > probem
> > > > durin
> > > > >
> > > > > g
> > > > > >
> > > > > > >
> > > > > > > commit time? I mean you would really know the SVN id. So you
> > > > > > > could
> > > > only a
> > > > >
> > > > > dd
> > > > > >
> > > > > > >
> > > > > > > a specific revision in a different commit to RELEASE file.
> > > > > > >
> > > > > > Generally, you can guess really well, and fix it in the case of
> > > > > > a lost
> > > > race
> > > > >
> > > > > >
> > > > > > easily.
> > > > > No reason to guess, if you add the RELNOTES change with the
> > > > > commit
> > > > > then it is the revision that added the RELNOTES entry, so a log
> > > > > view
> > > > > of RELNOTES would show you the revision.??If you do it after
> > > > > words
> > > > > or edit an existing entry in the RELNOTES file that is also
> > > > > fairly
> > > > > clear as that commit has no other files touched.
> > > > >
> > > > > >
> > > > > >
> > > > > > You'd add the release notes text in full to the file, with a
> > > > > > pointer
> > > > to the
> > > > >
> > > > > >
> > > > > > revision(s) for the feature.
> > > > > If you modify RELNOTES with the commit adding the feature we
> > > > > could easily use a pointer of "this commit", the svn version
> > > > > number
> > > > > of that added entry is self referencing to the actual change,
> > > > > which I actually rather like the idea of.
> > > > >
> > > > > >
> > > > > >
> > > > > > Warner
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Have a blurb at the top that tells people what
> > > > > > > > order to add them in, and you'd be set. We'd t

svn commit: r341800 - in head: sys/kern tests/sys/kern

2018-12-10 Thread John Baldwin

Author: jhb
Date: Mon Dec 10 19:39:24 2018
New Revision: 341800
URL: https://svnweb.freebsd.org/changeset/base/341800

Log:
  Don't report stale signal information for non-signal events in ptrace_lwpinfo.
  
  Once a signal's siginfo was copied to 'td_si' as part of the signal
  exchange in issignal(), it was never cleared.  This caused future
  thread events that are reported as SIGTRAP events without signal
  information to report the stale siginfo in 'td_si'.  For example, if a
  debugger created a new process and used SIGSTOP to stop it after
  PT_ATTACH, future system call entry / exit events would set PL_FLAG_SI
  with the SIGSTOP siginfo in pl_siginfo.  This broke 'catch syscall' in
  current versions of gdb as it assumed PL_FLAG_SI with SIGTRAP
  indicates a breakpoint or single step trap.
  
  Reviewed by:  kib
  MFC after:1 week
  Differential Revision:https://reviews.freebsd.org/D18487

Modified:
  head/sys/kern/kern_sig.c
  head/tests/sys/kern/ptrace_test.c

Modified: head/sys/kern/kern_sig.c
==
--- head/sys/kern/kern_sig.cMon Dec 10 16:23:11 2018(r341799)
+++ head/sys/kern/kern_sig.cMon Dec 10 19:39:24 2018(r341800)
@@ -2847,6 +2847,8 @@ issignal(struct thread *td)
sig = ptracestop(td, sig, &ksi);
mtx_lock(&ps->ps_mtx);
 
+   td->td_si.si_signo = 0;
+
/* 
 * Keep looking if the debugger discarded or
 * replaced the signal.

Modified: head/tests/sys/kern/ptrace_test.c
==
--- head/tests/sys/kern/ptrace_test.c   Mon Dec 10 16:23:11 2018
(r341799)
+++ head/tests/sys/kern/ptrace_test.c   Mon Dec 10 19:39:24 2018
(r341800)
@@ -3772,6 +3772,78 @@ ATF_TC_BODY(ptrace__PT_CONTINUE_different_thread, tc)
 }
 #endif
 
+/*
+ * Verify that PT_LWPINFO doesn't return stale siginfo.
+ */
+ATF_TC_WITHOUT_HEAD(ptrace__PT_LWPINFO_stale_siginfo);
+ATF_TC_BODY(ptrace__PT_LWPINFO_stale_siginfo, tc)
+{
+   struct ptrace_lwpinfo pl;
+   pid_t fpid, wpid;
+   int events, status;
+
+   ATF_REQUIRE((fpid = fork()) != -1);
+   if (fpid == 0) {
+   trace_me();
+   raise(SIGABRT);
+   exit(1);
+   }
+
+   /* The first wait() should report the stop from SIGSTOP. */
+   wpid = waitpid(fpid, &status, 0);
+   ATF_REQUIRE(wpid == fpid);
+   ATF_REQUIRE(WIFSTOPPED(status));
+   ATF_REQUIRE(WSTOPSIG(status) == SIGSTOP);
+
+   ATF_REQUIRE(ptrace(PT_CONTINUE, fpid, (caddr_t)1, 0) == 0);
+
+   /* The next stop should report the SIGABRT in the child body. */
+   wpid = waitpid(fpid, &status, 0);
+   ATF_REQUIRE(wpid == fpid);
+   ATF_REQUIRE(WIFSTOPPED(status));
+   ATF_REQUIRE(WSTOPSIG(status) == SIGABRT);
+
+   ATF_REQUIRE(ptrace(PT_LWPINFO, wpid, (caddr_t)&pl, sizeof(pl)) != -1);
+   ATF_REQUIRE(pl.pl_flags & PL_FLAG_SI);
+   ATF_REQUIRE(pl.pl_siginfo.si_signo == SIGABRT);
+
+   /*
+* Continue the process ignoring the signal, but enabling
+* syscall traps.
+*/
+   ATF_REQUIRE(ptrace(PT_SYSCALL, fpid, (caddr_t)1, 0) == 0);
+
+   /*
+* The next stop should report a system call entry from
+* exit().  PL_FLAGS_SI should not be set.
+*/
+   wpid = waitpid(fpid, &status, 0);
+   ATF_REQUIRE(wpid == fpid);
+   ATF_REQUIRE(WIFSTOPPED(status));
+   ATF_REQUIRE(WSTOPSIG(status) == SIGTRAP);
+
+   ATF_REQUIRE(ptrace(PT_LWPINFO, wpid, (caddr_t)&pl, sizeof(pl)) != -1);
+   ATF_REQUIRE(pl.pl_flags & PL_FLAG_SCE);
+   ATF_REQUIRE((pl.pl_flags & PL_FLAG_SI) == 0);
+
+   /* Disable syscall tracing and continue the child to let it exit. */
+   ATF_REQUIRE(ptrace(PT_GET_EVENT_MASK, fpid, (caddr_t)&events,
+   sizeof(events)) == 0);
+   events &= ~PTRACE_SYSCALL;
+   ATF_REQUIRE(ptrace(PT_SET_EVENT_MASK, fpid, (caddr_t)&events,
+   sizeof(events)) == 0);
+   ATF_REQUIRE(ptrace(PT_CONTINUE, fpid, (caddr_t)1, 0) == 0);
+
+   /* The last event should be for the child process's exit. */
+   wpid = waitpid(fpid, &status, 0);
+   ATF_REQUIRE(WIFEXITED(status));
+   ATF_REQUIRE(WEXITSTATUS(status) == 1);
+
+   wpid = wait(&status);
+   ATF_REQUIRE(wpid == -1);
+   ATF_REQUIRE(errno == ECHILD);
+}
+
 ATF_TP_ADD_TCS(tp)
 {
 
@@ -3831,6 +3903,7 @@ ATF_TP_ADD_TCS(tp)
 #if defined(HAVE_BREAKPOINT) && defined(SKIP_BREAK)
ATF_TP_ADD_TC(tp, ptrace__PT_CONTINUE_different_thread);
 #endif
+   ATF_TP_ADD_TC(tp, ptrace__PT_LWPINFO_stale_siginfo);
 
return (atf_no_error());
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "sv

svn commit: r341801 - head/sys/mips/conf

2018-12-10 Thread Warner Losh

Author: imp
Date: Mon Dec 10 21:33:01 2018
New Revision: 341801
URL: https://svnweb.freebsd.org/changeset/base/341801

Log:
  Remove stray hints files.

Deleted:
  head/sys/mips/conf/ADM5120.hints
  head/sys/mips/conf/IDT.hints
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341802 - head/usr.bin/truss

2018-12-10 Thread John Baldwin

Author: jhb
Date: Mon Dec 10 21:47:19 2018
New Revision: 341802
URL: https://svnweb.freebsd.org/changeset/base/341802

Log:
  Validate the string size parameter passed to -s.
  
  Use strtonum() to reject negative sizes instead of core dumping.
  
  PR:   232206
  Submitted by: David Carlier 
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D17537

Modified:
  head/usr.bin/truss/main.c

Modified: head/usr.bin/truss/main.c
==
--- head/usr.bin/truss/main.c   Mon Dec 10 21:33:01 2018(r341801)
+++ head/usr.bin/truss/main.c   Mon Dec 10 21:47:19 2018(r341802)
@@ -71,6 +71,7 @@ main(int ac, char **av)
struct trussinfo *trussinfo;
char *fname;
char **command;
+   const char *errstr;
pid_t pid;
int c;
 
@@ -118,7 +119,9 @@ main(int ac, char **av)
fname = optarg;
break;
case 's':   /* Specified string size */
-   trussinfo->strsize = atoi(optarg);
+   trussinfo->strsize = strtonum(optarg, 0, INT_MAX, 
&errstr);
+   if (errstr)
+   errx(1, "maximum string size is %s: %s", 
errstr, optarg);
break;
case 'S':   /* Don't trace signals */
trussinfo->flags |= NOSIGS;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread John Baldwin

On 12/8/18 7:43 PM, Warner Losh wrote:
> 
> 
> On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling   wrote:
> 
> On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik  > wrote:
> 
> >
> > Fully satisfying solution would be that all architectures get 64-bit
> > ops, even if in the worst case they end up taking a lock. Then
> > subsystems would not have to ifdef on anything. However, there
> > was some opposition to this proposal and I don't think this is
> > important enough to push.
> 
> Mateusz,
> 
> Who is opposing this particular polyfill solution?  Scott Long brought
> up a situation in driver development where this would be useful as
> well.  The polyfills lower the cognitive load and #ifdef soup which
> are the right call here regardless of performance on toy ports.
> 
> 
> I don't recall seeing the opposition either. It would have to be a global 
> lock for all 64bit atomics but I think it would only be 2 atomics on 
> those architectures. 

It would have to be a spin lock, so in the case of unrl you would be trading
an operation on one of N regular mutexes for a single spin lock that was
also contested by other things.  This would be pretty crappy.  For drivers
that aren't actually used on platforms without 32-bit atomics we can simply
not build them in sys/modules/Makefile or not put them in GENERIC.  For
something in the core kernel like unrl I think we will have to do what
Mateusz has done here.

-- 
John Baldwin


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread Konstantin Belousov

On Mon, Dec 10, 2018 at 02:15:20PM -0800, John Baldwin wrote:
> On 12/8/18 7:43 PM, Warner Losh wrote:
> > 
> > 
> > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling  >  wrote:
> > 
> > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik  > > wrote:
> > 
> > >
> > > Fully satisfying solution would be that all architectures get 64-bit
> > > ops, even if in the worst case they end up taking a lock. Then
> > > subsystems would not have to ifdef on anything. However, there
> > > was some opposition to this proposal and I don't think this is
> > > important enough to push.
> > 
> > Mateusz,
> > 
> > Who is opposing this particular polyfill solution?  Scott Long brought
> > up a situation in driver development where this would be useful as
> > well.  The polyfills lower the cognitive load and #ifdef soup which
> > are the right call here regardless of performance on toy ports.
> > 
> > 
> > I don't recall seeing the opposition either. It would have to be a global 
> > lock for all 64bit atomics but I think it would only be 2 atomics on 
> > those architectures. 
> 
> It would have to be a spin lock, so in the case of unrl you would be trading
> an operation on one of N regular mutexes for a single spin lock that was
> also contested by other things.  This would be pretty crappy.  For drivers
> that aren't actually used on platforms without 32-bit atomics we can simply
> not build them in sys/modules/Makefile or not put them in GENERIC.  For
> something in the core kernel like unrl I think we will have to do what
> Mateusz has done here.

It is worse. All atomics that acess the same location must use the same
lock. Otherwise, you could observe torn writes and out of thin air
values. Since you cannot know in advance which locations are acceses
by the locked variant, all freebsd atomics ops have to be switched to
locked variant on the architecture.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread Ian Lepore

On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote:
> On 12/8/18 7:43 PM, Warner Losh wrote:
> > 
> > 
> > 
> > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling  > m  wrote:
> > 
> > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik  > m > wrote:
> > 
> > >
> > > Fully satisfying solution would be that all architectures get
> > 64-bit
> > > ops, even if in the worst case they end up taking a lock.
> > Then
> > > subsystems would not have to ifdef on anything. However,
> > there
> > > was some opposition to this proposal and I don't think this
> > is
> > > important enough to push.
> > 
> > Mateusz,
> > 
> > Who is opposing this particular polyfill solution?  Scott Long
> > brought
> > up a situation in driver development where this would be useful
> > as
> > well.  The polyfills lower the cognitive load and #ifdef soup
> > which
> > are the right call here regardless of performance on toy ports.
> > 
> > 
> > I don't recall seeing the opposition either. It would have to be a
> > global lock for all 64bit atomics but I think it would only be
> > 2 atomics on those architectures. 
> It would have to be a spin lock, so in the case of unrl you would be
> trading
> an operation on one of N regular mutexes for a single spin lock that
> was
> also contested by other things.  This would be pretty crappy.  For
> drivers
> that aren't actually used on platforms without 32-bit atomics we can
> simply
> not build them in sys/modules/Makefile or not put them in
> GENERIC.  For
> something in the core kernel like unrl I think we will have to do
> what
> Mateusz has done here.
> 

On a single-core system all you need to implement 64-bit atomics in the
kernel is to disable interrupts around using normal load/store
operations on the values. Do we have any platforms that are SMP but
don't have hardware primitives for 64-bit atomics?

-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread Kevin Bowling

Right we are talking about a polyfill for systems that have 1-2 cores
in practice.  You're not going to crank high parallelism on these
global locks in practice and the common lock may help performance due
to cache residence for all we know.  This is a lot of ballyhoo for a
decision that should favor the reduction of complexity, clean KPIs,
and overwhelming majority of machines that have 64b atomics, not
scattering ifdefs in the code for niche performance.

Regards,
Kevin
On Mon, Dec 10, 2018 at 4:57 PM Ian Lepore  wrote:
>
> On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote:
> > On 12/8/18 7:43 PM, Warner Losh wrote:
> > >
> > >
> > >
> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling  > > m  wrote:
> > >
> > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik  > > m > wrote:
> > >
> > > >
> > > > Fully satisfying solution would be that all architectures get
> > > 64-bit
> > > > ops, even if in the worst case they end up taking a lock.
> > > Then
> > > > subsystems would not have to ifdef on anything. However,
> > > there
> > > > was some opposition to this proposal and I don't think this
> > > is
> > > > important enough to push.
> > >
> > > Mateusz,
> > >
> > > Who is opposing this particular polyfill solution?  Scott Long
> > > brought
> > > up a situation in driver development where this would be useful
> > > as
> > > well.  The polyfills lower the cognitive load and #ifdef soup
> > > which
> > > are the right call here regardless of performance on toy ports.
> > >
> > >
> > > I don't recall seeing the opposition either. It would have to be a
> > > global lock for all 64bit atomics but I think it would only be
> > > 2 atomics on those architectures.
> > It would have to be a spin lock, so in the case of unrl you would be
> > trading
> > an operation on one of N regular mutexes for a single spin lock that
> > was
> > also contested by other things.  This would be pretty crappy.  For
> > drivers
> > that aren't actually used on platforms without 32-bit atomics we can
> > simply
> > not build them in sys/modules/Makefile or not put them in
> > GENERIC.  For
> > something in the core kernel like unrl I think we will have to do
> > what
> > Mateusz has done here.
> >
>
> On a single-core system all you need to implement 64-bit atomics in the
> kernel is to disable interrupts around using normal load/store
> operations on the values. Do we have any platforms that are SMP but
> don't have hardware primitives for 64-bit atomics?
>
> -- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread Justin Hibbits

On Mon, Dec 10, 2018, 17:57 Ian Lepore  On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote:
> > On 12/8/18 7:43 PM, Warner Losh wrote:
> > >
> > >
> > >
> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling  > > m  wrote:
> > >
> > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik  > > m > wrote:
> > >
> > > >
> > > > Fully satisfying solution would be that all architectures get
> > > 64-bit
> > > > ops, even if in the worst case they end up taking a lock.
> > > Then
> > > > subsystems would not have to ifdef on anything. However,
> > > there
> > > > was some opposition to this proposal and I don't think this
> > > is
> > > > important enough to push.
> > >
> > > Mateusz,
> > >
> > > Who is opposing this particular polyfill solution?  Scott Long
> > > brought
> > > up a situation in driver development where this would be useful
> > > as
> > > well.  The polyfills lower the cognitive load and #ifdef soup
> > > which
> > > are the right call here regardless of performance on toy ports.
> > >
> > >
> > > I don't recall seeing the opposition either. It would have to be a
> > > global lock for all 64bit atomics but I think it would only be
> > > 2 atomics on those architectures.
> > It would have to be a spin lock, so in the case of unrl you would be
> > trading
> > an operation on one of N regular mutexes for a single spin lock that
> > was
> > also contested by other things.  This would be pretty crappy.  For
> > drivers
> > that aren't actually used on platforms without 32-bit atomics we can
> > simply
> > not build them in sys/modules/Makefile or not put them in
> > GENERIC.  For
> > something in the core kernel like unrl I think we will have to do
> > what
> > Mateusz has done here.
> >
>
> On a single-core system all you need to implement 64-bit atomics in the
> kernel is to disable interrupts around using normal load/store
> operations on the values. Do we have any platforms that are SMP but
> don't have hardware primitives for 64-bit atomics?
>
> -- Ian
>

There were some dual processor G4 machines. I have one.  It doesn't have 64
bit atomics.

- Justin

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread Warner Losh

On Mon, Dec 10, 2018, 5:27 PM Justin Hibbits 
>
> On Mon, Dec 10, 2018, 17:57 Ian Lepore 
>> On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote:
>> > On 12/8/18 7:43 PM, Warner Losh wrote:
>> > >
>> > >
>> > >
>> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > > m  wrote:
>> > >
>> > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik > > > m > wrote:
>> > >
>> > > >
>> > > > Fully satisfying solution would be that all architectures get
>> > > 64-bit
>> > > > ops, even if in the worst case they end up taking a lock.
>> > > Then
>> > > > subsystems would not have to ifdef on anything. However,
>> > > there
>> > > > was some opposition to this proposal and I don't think this
>> > > is
>> > > > important enough to push.
>> > >
>> > > Mateusz,
>> > >
>> > > Who is opposing this particular polyfill solution?  Scott Long
>> > > brought
>> > > up a situation in driver development where this would be useful
>> > > as
>> > > well.  The polyfills lower the cognitive load and #ifdef soup
>> > > which
>> > > are the right call here regardless of performance on toy ports.
>> > >
>> > >
>> > > I don't recall seeing the opposition either. It would have to be a
>> > > global lock for all 64bit atomics but I think it would only be
>> > > 2 atomics on those architectures.
>> > It would have to be a spin lock, so in the case of unrl you would be
>> > trading
>> > an operation on one of N regular mutexes for a single spin lock that
>> > was
>> > also contested by other things.  This would be pretty crappy.  For
>> > drivers
>> > that aren't actually used on platforms without 32-bit atomics we can
>> > simply
>> > not build them in sys/modules/Makefile or not put them in
>> > GENERIC.  For
>> > something in the core kernel like unrl I think we will have to do
>> > what
>> > Mateusz has done here.
>> >
>>
>> On a single-core system all you need to implement 64-bit atomics in the
>> kernel is to disable interrupts around using normal load/store
>> operations on the values. Do we have any platforms that are SMP but
>> don't have hardware primitives for 64-bit atomics?
>>
>> -- Ian
>>
>
> There were some dual processor G4 machines. I have one.  It doesn't have
> 64 bit atomics.
>

There is a 32 bit mips machine like this as well. For drivers it's not too
bad, but for core functions in the MI part of the kernel, all known
implementations super duper suck.

Warner

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread Kevin Bowling

Humor me with a kernel feature that will sue 64b atomics while both
instruction streams are ping ponging on the hypothetical lock because
this thread is getting pretty far out there..
On Mon, Dec 10, 2018 at 5:27 PM Justin Hibbits  wrote:
>
>
>
> On Mon, Dec 10, 2018, 17:57 Ian Lepore >
>> On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote:
>> > On 12/8/18 7:43 PM, Warner Losh wrote:
>> > >
>> > >
>> > >
>> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > > m  wrote:
>> > >
>> > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik > > > m > wrote:
>> > >
>> > > >
>> > > > Fully satisfying solution would be that all architectures get
>> > > 64-bit
>> > > > ops, even if in the worst case they end up taking a lock.
>> > > Then
>> > > > subsystems would not have to ifdef on anything. However,
>> > > there
>> > > > was some opposition to this proposal and I don't think this
>> > > is
>> > > > important enough to push.
>> > >
>> > > Mateusz,
>> > >
>> > > Who is opposing this particular polyfill solution?  Scott Long
>> > > brought
>> > > up a situation in driver development where this would be useful
>> > > as
>> > > well.  The polyfills lower the cognitive load and #ifdef soup
>> > > which
>> > > are the right call here regardless of performance on toy ports.
>> > >
>> > >
>> > > I don't recall seeing the opposition either. It would have to be a
>> > > global lock for all 64bit atomics but I think it would only be
>> > > 2 atomics on those architectures.
>> > It would have to be a spin lock, so in the case of unrl you would be
>> > trading
>> > an operation on one of N regular mutexes for a single spin lock that
>> > was
>> > also contested by other things.  This would be pretty crappy.  For
>> > drivers
>> > that aren't actually used on platforms without 32-bit atomics we can
>> > simply
>> > not build them in sys/modules/Makefile or not put them in
>> > GENERIC.  For
>> > something in the core kernel like unrl I think we will have to do
>> > what
>> > Mateusz has done here.
>> >
>>
>> On a single-core system all you need to implement 64-bit atomics in the
>> kernel is to disable interrupts around using normal load/store
>> operations on the values. Do we have any platforms that are SMP but
>> don't have hardware primitives for 64-bit atomics?
>>
>> -- Ian
>
>
> There were some dual processor G4 machines. I have one.  It doesn't have 64 
> bit atomics.
>
> - Justin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341803 - head/libexec/rc

2018-12-10 Thread Conrad Meyer

Author: cem
Date: Tue Dec 11 01:38:50 2018
New Revision: 341803
URL: https://svnweb.freebsd.org/changeset/base/341803

Log:
  rc.subr: Implement list_vars without using 'read'
  
  'read' pessimistically read(2)s one byte at a time, which can be quite
  silly for large environments in slow emulators.
  
  In my boring user environment, truss shows that the number of read()
  syscalls to source rc.subr and invoke list_vars is reduced by something like
  3400 to 60.  ministat(1) shows a significant time difference of about -71%
  for my environment.
  
  Suggested by: jilles
  Discussed with:   dteske, jhb, jilles
  Differential Revision:https://reviews.freebsd.org/D18481

Modified:
  head/libexec/rc/rc.subr

Modified: head/libexec/rc/rc.subr
==
--- head/libexec/rc/rc.subr Mon Dec 10 21:47:19 2018(r341802)
+++ head/libexec/rc/rc.subr Tue Dec 11 01:38:50 2018(r341803)
@@ -58,17 +58,29 @@ JID=0
 #  -
 
 # list_vars pattern
-#  List vars matching pattern.
+#  List variables matching glob pattern.
 # 
 list_vars()
 {
-   set | { while read LINE; do
-   var="${LINE%%=*}"
-   case "$var" in
-   "$LINE"|*[!a-zA-Z0-9_]*) continue ;;
-   $1) echo $var
+   # Localize 'set' option below.
+   local -
+   local IFS=$'\n' line varname
+
+   # Disable path expansion in unquoted 'for' parameters below.
+   set -o noglob
+
+   for line in $(set); do
+   varname="${line%%=*}"
+
+   case "$varname" in
+   "$line"|*[!a-zA-Z0-9_]*)
+   continue
+   ;;
+   $1)
+   echo $varname
+   ;;
esac
-   done; }
+   done
 }
 
 # set_rcvar [var] [defval] [desc]
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341805 - head/sys/powerpc/booke

2018-12-10 Thread Justin Hibbits

Author: jhibbits
Date: Tue Dec 11 02:03:00 2018
New Revision: 341805
URL: https://svnweb.freebsd.org/changeset/base/341805

Log:
  powerpc/booke: Don't get and use the load offset for TOC on APs
  
  The code was a near exact copy of the code in startup, but it doesn't need
  the complexity since the kernel is already relocated.  With
  VM_MIN_KERNEL_ADDRESS as currently set to KERNBASE, this doesn't cause a
  problem, because it's a zero offset.  However, when KERNBASE is changed to a
  physical load address, it then has a non-zero offset, and ends up with an
  invalid stack pointer, causing the AP to hang.

Modified:
  head/sys/powerpc/booke/locore.S

Modified: head/sys/powerpc/booke/locore.S
==
--- head/sys/powerpc/booke/locore.S Tue Dec 11 01:49:06 2018
(r341804)
+++ head/sys/powerpc/booke/locore.S Tue Dec 11 02:03:00 2018
(r341805)
@@ -549,14 +549,9 @@ bp_kernload:
add %r2,%r1,%r2
mtspr   SPR_SPRG8, %r2
 
-   /* Get load offset */
-   ld  %r31,-0x8000(%r2) /* First TOC entry is TOC base */
-   subf%r31,%r31,%r2   /* Subtract from real TOC base to get base */
-
/* Set up the stack pointer */
ld  %r1,TOC_REF(tmpstack)(%r2)
addi%r1,%r1,TMPSTACKSZ-96
-   add %r1,%r1,%r31
 #else
 /*
  * Setup a temporary stack
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341806 - head/share/vt/keymaps

2018-12-10 Thread David Bright

Author: dab
Date: Tue Dec 11 02:14:40 2018
New Revision: 341806
URL: https://svnweb.freebsd.org/changeset/base/341806

Log:
  Add uk.macbook.kbd keymap (vt)
  
  PR:   215185
  Submitted by: James Wright 
  Reported by:  James Wright 
  Reviewed by:  emaste (earlier version)
  MFC after:1 week
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D18395

Added:
  head/share/vt/keymaps/uk.macbook.kbd   (contents, props changed)
Modified:
  head/share/vt/keymaps/INDEX.keymaps
  head/share/vt/keymaps/Makefile

Modified: head/share/vt/keymaps/INDEX.keymaps
==
--- head/share/vt/keymaps/INDEX.keymaps Tue Dec 11 02:03:00 2018
(r341805)
+++ head/share/vt/keymaps/INDEX.keymaps Tue Dec 11 02:14:40 2018
(r341806)
@@ -520,6 +520,12 @@ uk.dvorak.kbd:fr:Royaume Uni Dvorak
 uk.dvorak.kbd:pt:Reino Unido Dvorak
 uk.dvorak.kbd:es:Británico Dvorak
 
+uk.macbook.kbd:en:United Kingdom Macbook
+uk.macbook.kbd:de:Vereinigtes Königreich Macbook
+uk.macbook.kbd:fr:Royaume Uni Macbook
+uk.macbook.kbd:pt:Reino Unido Macbook
+uk.macbook.kbd:es:Británico Macbook
+
 us.kbd:en:United States of America
 us.kbd:de:US-amerikanisch
 us.kbd:fr:États Unis d'Amérique

Modified: head/share/vt/keymaps/Makefile
==
--- head/share/vt/keymaps/Makefile  Tue Dec 11 02:03:00 2018
(r341805)
+++ head/share/vt/keymaps/Makefile  Tue Dec 11 02:14:40 2018
(r341806)
@@ -74,6 +74,7 @@ FILES=INDEX.keymaps \
uk.capsctrl.kbd \
uk.dvorak.kbd \
uk.kbd \
+   uk.macbook.kbd \
us.acc.kbd \
us.ctrl.kbd \
us.dvorak.kbd \

Added: head/share/vt/keymaps/uk.macbook.kbd
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/vt/keymaps/uk.macbook.kbdTue Dec 11 02:14:40 2018
(r341806)
@@ -0,0 +1,115 @@
+# $FreeBSD$
+# by James Wright 
+# alt
+# scan   cntrl  altalt   cntrl lock
+# code  base   shift  cntrl  shift  altshift  cntrl  shift state
+# --
+  000   nopnopnopnopnopnopnopnop O
+  001   escescescescescescdebug  esc O
+  002   '1''!'nopnop'1''!'nopnop O
+  003   '2''@'nulnul0x20ac '@'nulnul O
+  004   '3'0xa3   nopnop'#'0xa3   nopnop O
+  005   '4''$'nopnop'4''$'nopnop O
+  006   '5''%'nopnop'5''%'nopnop O
+  007   '6''^'rs rs '6''^'rs rs  O
+  008   '7''&'nopnop'7''&'nopnop O
+  009   '8''*'nopnop'8''*'nopnop O
+  010   '9''('nopnop'9''('nopnop O
+  011   '0'')'nopnop'0'')'nopnop O
+  012   '-''_'us us '-''_'us us  O
+  013   '=''+'nopnop'=''+'nopnop O
+  014   bs bs deldelbs bs deldel O
+  015   ht btab   nopnopht btab   nopnop O
+  016   'q''Q'dc1dc1'q''Q'dc1dc1 C
+  017   'w''W'etbetb'w''W'etbetb C
+  018   'e''E'enqenq'e''E'enqenq C
+  019   'r''R'dc2dc2'r''R'dc2dc2 C
+  020   't''T'dc4dc4't''T'dc4dc4 C
+  021   'y''Y'em em 'y''Y'em em  C
+  022   'u''U'naknak'u''U'naknak C
+  023   'i''I'ht ht 'i''I'ht ht  C
+  024   'o''O'si si 'o''O'si si  C
+  025   'p''P'dledle'p''P'dledle C
+  026   '[''{'escesc'[''{'escesc O
+  027   ']''}'gs gs ']''}'gs gs  O
+  028   cr cr nl nl cr cr nl nl  O
+  029   lctrl  lctrl  lctrl  lctrl  lctrl  lctrl  lctrl  lctrl   O
+  030   'a''A'sohsoh'a''A'sohsoh C
+  031   's''S'dc3dc3's''S'dc3dc3 C
+  032   'd''D'eoteot'd''D'eoteot C
+  033   'f''F'ackack'f''F'ackack C
+  034   'g''G'belbel'g''G'belbel C
+  035   'h''H'bs bs 'h''H'bs bs  C
+  036   'j''J'nl nl 'j''J'nl nl  C
+  037   'k''K'vt vt 'k''K'vt vt  C
+  038   'l''L'f

svn commit: r341807 - head/sys/riscv/riscv

2018-12-10 Thread Mark Johnston

Author: markj
Date: Tue Dec 11 02:15:56 2018
New Revision: 341807
URL: https://svnweb.freebsd.org/changeset/base/341807

Log:
  Use inline tests for individual PTE bits in the RISC-V pmap.
  
  Inline tests for PTE_* bits are easy to read and don't really require a
  predicate function, and predicates which operate on a pt_entry_t are
  inconvenient when working with L1 and L2 page table entries.
  
  Reviewed by:  jhb
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D18461

Modified:
  head/sys/riscv/riscv/pmap.c

Modified: head/sys/riscv/riscv/pmap.c
==
--- head/sys/riscv/riscv/pmap.c Tue Dec 11 02:14:40 2018(r341806)
+++ head/sys/riscv/riscv/pmap.c Tue Dec 11 02:15:56 2018(r341807)
@@ -356,36 +356,6 @@ pmap_l3(pmap_t pmap, vm_offset_t va)
return (pmap_l2_to_l3(l2, va));
 }
 
-
-static __inline int
-pmap_is_write(pt_entry_t entry)
-{
-
-   return (entry & PTE_W);
-}
-
-static __inline int
-pmap_l3_valid(pt_entry_t l3)
-{
-
-   return (l3 & PTE_V);
-}
-
-static inline int
-pmap_page_accessed(pt_entry_t pte)
-{
-
-   return (pte & PTE_A);
-}
-
-/* Checks if the page is dirty. */
-static inline int
-pmap_page_dirty(pt_entry_t pte)
-{
-
-   return (pte & PTE_D);
-}
-
 static __inline void
 pmap_resident_count_inc(pmap_t pmap, int count)
 {
@@ -898,7 +868,7 @@ pmap_extract_and_hold(pmap_t pmap, vm_offset_t va, vm_
 retry:
l3p = pmap_l3(pmap, va);
if (l3p != NULL && (l3 = pmap_load(l3p)) != 0) {
-   if ((pmap_is_write(l3)) || ((prot & VM_PROT_WRITE) == 0)) {
+   if ((l3 & PTE_W) != 0 || (prot & VM_PROT_WRITE) == 0) {
phys = PTE_TO_PHYS(l3);
if (vm_page_pa_tryrelock(pmap, phys, &pa))
goto retry;
@@ -1777,7 +1747,7 @@ pmap_remove_l3(pmap_t pmap, pt_entry_t *l3, vm_offset_
if (old_l3 & PTE_SW_MANAGED) {
phys = PTE_TO_PHYS(old_l3);
m = PHYS_TO_VM_PAGE(phys);
-   if (pmap_page_dirty(old_l3))
+   if ((old_l3 & PTE_D) != 0)
vm_page_dirty(m);
if (old_l3 & PTE_A)
vm_page_aflag_set(m, PGA_REFERENCED);
@@ -1935,7 +1905,7 @@ pmap_remove_all(vm_page_t m)
/*
 * Update the vm_page_t clean and reference bits.
 */
-   if (pmap_page_dirty(tl3))
+   if ((tl3 & PTE_D) != 0)
vm_page_dirty(m);
pmap_unuse_l3(pmap, pv->pv_va, pmap_load(l2), &free);
TAILQ_REMOVE(&m->md.pv_list, pv, pv_next);
@@ -1997,9 +1967,9 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, vm_offset_t
for (l3p = pmap_l2_to_l3(l2, sva); sva != va_next; l3p++,
sva += L3_SIZE) {
l3 = pmap_load(l3p);
-   if (pmap_l3_valid(l3)) {
+   if ((l3 & PTE_V) != 0) {
entry = pmap_load(l3p);
-   entry &= ~(PTE_W);
+   entry &= ~PTE_W;
pmap_load_store(l3p, entry);
/* XXX: Use pmap_invalidate_range */
pmap_invalidate_page(pmap, sva);
@@ -2186,7 +2156,7 @@ pmap_enter(pmap_t pmap, vm_offset_t va, vm_page_t m, v
/*
 * Is the specified virtual address already mapped?
 */
-   if (pmap_l3_valid(orig_l3)) {
+   if ((orig_l3 & PTE_V) != 0) {
/*
 * Wiring change, just update stats. We don't worry about
 * wiring PT pages as they remain resident as long as there
@@ -2217,10 +2187,9 @@ pmap_enter(pmap_t pmap, vm_offset_t va, vm_page_t m, v
/*
 * No, might be a protection or wiring change.
 */
-   if ((orig_l3 & PTE_SW_MANAGED) != 0) {
-   if (pmap_is_write(new_l3))
-   vm_page_aflag_set(m, PGA_WRITEABLE);
-   }
+   if ((orig_l3 & PTE_SW_MANAGED) != 0 &&
+   (new_l3 & PTE_W) != 0)
+   vm_page_aflag_set(m, PGA_WRITEABLE);
goto validate;
}
 
@@ -2245,7 +2214,7 @@ pmap_enter(pmap_t pmap, vm_offset_t va, vm_page_t m, v
 * concurrent calls to pmap_page_test_mappings() and
 * pmap_ts_referenced().
 */
-   if (pmap_page_dirty(orig_l3))
+   if ((orig_l3 & PTE_D) != 0)
vm_page_dirty(om);
if ((orig_l3 & PTE_A) != 0)
v

svn commit: r341808 - head/sys/riscv/riscv

2018-12-10 Thread Mark Johnston

Author: markj
Date: Tue Dec 11 02:16:27 2018
New Revision: 341808
URL: https://svnweb.freebsd.org/changeset/base/341808

Log:
  Remove an unused malloc(9) type.
  
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/riscv/riscv/pmap.c

Modified: head/sys/riscv/riscv/pmap.c
==
--- head/sys/riscv/riscv/pmap.c Tue Dec 11 02:15:56 2018(r341807)
+++ head/sys/riscv/riscv/pmap.c Tue Dec 11 02:16:27 2018(r341808)
@@ -213,8 +213,6 @@ __FBSDID("$FreeBSD$");
 LIST_HEAD(pmaplist, pmap);
 static struct pmaplist allpmaps;
 
-static MALLOC_DEFINE(M_VMPMAP, "pmap", "PMAP L1");
-
 struct pmap kernel_pmap_store;
 
 vm_offset_t virtual_avail; /* VA of first avail page (after kernel bss) */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341809 - in head: lib/libc/sys sys/kern

2018-12-10 Thread Konstantin Belousov

Author: kib
Date: Tue Dec 11 02:48:49 2018
New Revision: 341809
URL: https://svnweb.freebsd.org/changeset/base/341809

Log:
  Remove special case handling for getfhat(fd, NULL, handle).
  
  There is no reason for it to behave differently from openat(fd, NULL).
  Also the handling did not worked because the substituted path was from
  the system address space, causing EFAULT.
  
  Submitted by: Jack Halford 
  MFC after:1 week
  Differential revision:https://reviews.freebsd.org/D18501

Modified:
  head/lib/libc/sys/getfh.2
  head/sys/kern/vfs_syscalls.c

Modified: head/lib/libc/sys/getfh.2
==
--- head/lib/libc/sys/getfh.2   Tue Dec 11 02:16:27 2018(r341808)
+++ head/lib/libc/sys/getfh.2   Tue Dec 11 02:48:49 2018(r341809)
@@ -29,7 +29,7 @@
 .\"@(#)getfh.2 8.1 (Berkeley) 6/9/93
 .\" $FreeBSD$
 .\"
-.Dd December 7, 2018
+.Dd December 11, 2018
 .Dt GETFH 2
 .Os
 .Sh NAME
@@ -76,12 +76,12 @@ and
 .Fn lgetfh
 except when the
 .Fa path
-specifies a relative or NULL path, or the
+specifies a relative path, or the
 .Dv AT_BENEATH
 flag is provided.
 For
 .Fn getfhat
-and relative or NULL
+and relative
 .Fa path ,
 the status is retrieved from a file relative to
 the directory associated with the file descriptor

Modified: head/sys/kern/vfs_syscalls.c
==
--- head/sys/kern/vfs_syscalls.cTue Dec 11 02:16:27 2018
(r341808)
+++ head/sys/kern/vfs_syscalls.cTue Dec 11 02:48:49 2018
(r341809)
@@ -4196,8 +4196,8 @@ sys_getfhat(struct thread *td, struct getfhat_args *ua
 
if ((uap->flags & ~(AT_SYMLINK_NOFOLLOW | AT_BENEATH)) != 0)
return (EINVAL);
-   return (kern_getfhat(td, uap->flags, uap->fd, uap->path ? uap->path : 
".",
-   UIO_USERSPACE, uap->fhp));
+   return (kern_getfhat(td, uap->flags, uap->fd, uap->path, UIO_USERSPACE,
+   uap->fhp));
 }
 
 static int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341810 - in head/sys: kern x86/x86

2018-12-10 Thread Konstantin Belousov

Author: kib
Date: Tue Dec 11 02:54:36 2018
New Revision: 341810
URL: https://svnweb.freebsd.org/changeset/base/341810

Log:
  Free bootstacks after AP startup.
  
  Bootstacks are unused after APs executed sched_throw() in
  init_secondary_tail() and started executing on proper idle thread
  stack.  Add sysinit that detects that the idle thread for each CPU was
  scheduled at least once, and free corresponding bootstack.
  
  Slight addition of the code (~200 bytes) is compensated by the saving,
  because even on typical small modern desktop CPU we leak 128K of
  memory otherwise (4 pages x 8 threads).
  
  Reviewed by:  jhb
  MFC after:1 week
  Differential revision:https://reviews.freebsd.org/D18486

Modified:
  head/sys/kern/kern_thread.c
  head/sys/x86/x86/mp_x86.c

Modified: head/sys/kern/kern_thread.c
==
--- head/sys/kern/kern_thread.c Tue Dec 11 02:48:49 2018(r341809)
+++ head/sys/kern/kern_thread.c Tue Dec 11 02:54:36 2018(r341810)
@@ -197,7 +197,7 @@ thread_ctor(void *mem, int size, void *arg, int flags)
 
td = (struct thread *)mem;
td->td_state = TDS_INACTIVE;
-   td->td_oncpu = NOCPU;
+   td->td_lastcpu = td->td_oncpu = NOCPU;
 
td->td_tid = tid_alloc();
 

Modified: head/sys/x86/x86/mp_x86.c
==
--- head/sys/x86/x86/mp_x86.c   Tue Dec 11 02:48:49 2018(r341809)
+++ head/sys/x86/x86/mp_x86.c   Tue Dec 11 02:54:36 2018(r341810)
@@ -1071,9 +1071,23 @@ init_secondary_tail(void)
/* NOTREACHED */
 }
 
-/***
- * local functions and data
- */
+static void
+smp_after_idle_runnable(void *arg __unused)
+{
+   struct thread *idle_td;
+   int cpu;
+
+   for (cpu = 1; cpu < mp_ncpus; cpu++) {
+   idle_td = pcpu_find(cpu)->pc_idlethread;
+   while (idle_td->td_lastcpu == NOCPU &&
+   idle_td->td_oncpu == NOCPU)
+   cpu_spinwait();
+   kmem_free((vm_offset_t)bootstacks[cpu], kstack_pages *
+   PAGE_SIZE);
+   }
+}
+SYSINIT(smp_after_idle_runnable, SI_SUB_SMP, SI_ORDER_ANY,
+smp_after_idle_runnable, NULL);
 
 /*
  * We tell the I/O APIC code about all the CPUs we want to receive
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r341811 - head/sys/dev/ahci

2018-12-10 Thread Xin LI

Author: delphij
Date: Tue Dec 11 05:10:22 2018
New Revision: 341811
URL: https://svnweb.freebsd.org/changeset/base/341811

Log:
  Remove questionable initialization for ICH8M, rely on BIOS to properly
  initialize the controller.
  
  According to the datasheet, the old code checks if port 2 (P2E, 0x4) was
  the only enabled port (except port 0, which was ignored by mask 0xfe),
  and issue a write to the PCS register to disable all but port 0, right
  before ahci_ctlr_reset.
  
  Some other operating systems would issue a port enable to all ports, but
  since the current code only does the special initialization for ICH8M,
  it entirely and rely on BIOS to do the right thing (the alternative
  would be https://reviews.freebsd.org/D18300?id=50922 , should we see
  reports that we really need to do it).
  
  Reviewed by:  mav
  MFC after:3 months
  Differential Revision:https://reviews.freebsd.org/D18300

Modified:
  head/sys/dev/ahci/ahci_pci.c

Modified: head/sys/dev/ahci/ahci_pci.c
==
--- head/sys/dev/ahci/ahci_pci.cTue Dec 11 02:54:36 2018
(r341810)
+++ head/sys/dev/ahci/ahci_pci.cTue Dec 11 05:10:22 2018
(r341811)
@@ -358,10 +358,7 @@ static int
 ahci_pci_ctlr_reset(device_t dev)
 {
 
-   if (pci_read_config(dev, PCIR_DEVVENDOR, 4) == 0x28298086 &&
-   (pci_read_config(dev, 0x92, 1) & 0xfe) == 0x04)
-   pci_write_config(dev, 0x92, 0x01, 1);
-   return ahci_ctlr_reset(dev);
+   return(ahci_ctlr_reset(dev));
 }
 
 static int
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r341682 - head/sys/sys

2018-12-10 Thread Scott Long

> On Dec 10, 2018, at 4:47 PM, Konstantin Belousov  wrote:
> 
> On Mon, Dec 10, 2018 at 02:15:20PM -0800, John Baldwin wrote:
>> On 12/8/18 7:43 PM, Warner Losh wrote:
>>> 
>>> 
>>> On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling >>  wrote:
>>> 
>>>On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik >> > wrote:
>>> 

 Fully satisfying solution would be that all architectures get 64-bit
 ops, even if in the worst case they end up taking a lock. Then
 subsystems would not have to ifdef on anything. However, there
 was some opposition to this proposal and I don't think this is
 important enough to push.
>>> 
>>>Mateusz,
>>> 
>>>Who is opposing this particular polyfill solution?  Scott Long brought
>>>up a situation in driver development where this would be useful as
>>>well.  The polyfills lower the cognitive load and #ifdef soup which
>>>are the right call here regardless of performance on toy ports.
>>> 
>>> 
>>> I don't recall seeing the opposition either. It would have to be a global 
>>> lock for all 64bit atomics but I think it would only be 2 atomics on 
>>> those architectures. 
>> 
>> It would have to be a spin lock, so in the case of unrl you would be trading
>> an operation on one of N regular mutexes for a single spin lock that was
>> also contested by other things.  This would be pretty crappy.  For drivers
>> that aren't actually used on platforms without 32-bit atomics we can simply
>> not build them in sys/modules/Makefile or not put them in GENERIC.  For
>> something in the core kernel like unrl I think we will have to do what
>> Mateusz has done here.
> 
> It is worse. All atomics that acess the same location must use the same
> lock. Otherwise, you could observe torn writes and out of thin air
> values. Since you cannot know in advance which locations are acceses
> by the locked variant, all freebsd atomics ops have to be switched to
> locked variant on the architecture.

64bit atomics on I486 already suffer the risk of torn reads; the implementation
merely does a CLI to protect against local preemption (though you could still
get unlucky with an NMI).  I suppose you could argue that SMP isn’t really
viable on I486 and therefore this fact is irrelevant, but it does illustrate
precedence for having API completeness in a platform.

Really, this isn’t that hard.  Part of the existing contract of using atomics is
that you carefully evaluate all uses of the variable and decide when to use
an atomic instruction.  Arguing that we can’t make this process automatic
and foolproof for 64bit quantities, especially for a subset of subset of
platforms/architectures, and therefore we should be even more of a difficult
landmine, is not…. I don’t know what to say… sensical?

64bit operations are a reality for MI code in a modern OS, and I’m tired of
having to tip-toe around them due to incomplete MD implementations.  The
instructions have been available on Intel CPUs for 25 years!  My
very strong preference is to have a complete and functional implementation
of atomic.h for any architecture that is hooked up to the build.  We can then
tackle the details of optimization and edge case refinement, just like we do
with every other API and service that we work on.  It doesn’t have to be
perfect to be useful, and at this point we’re providing neither perfection nor
utility, just “buts” and “what ifs”.

Going forward, I’m going to start using 64bit atomics where they’re prudent,
instead of avoiding them due to this niche 32bit argument.  If that means
more and more of what I do no longer compiles on a mips or a ppc32, then
that’s a sacrifice that is fine with me.  It still creates extra development 
work,
and having a uniformly available implementation would be much nicer.

Scott

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

37 matches

Mail list logo