1. 20 May, 2022 8 commits
  2. 04 May, 2022 8 commits
  3. 03 May, 2022 4 commits
  4. 02 May, 2022 2 commits
  5. 01 May, 2022 3 commits
    • HardenedBSD Sync Service's avatar
    • Ed Maste's avatar
      ssh: use upstream SSH_OPENSSL_VERSION macro · eb845555
      Ed Maste authored
      With the upgrade to OpenSSH 6.7p1 in commit a0ee8cc6 we replaced
      WITH_OPENSSL ifdefs with an OPENSSL_VERSION macro, later changing it
      A few years later OpenSSH made an equivalent change (with a different
      macro name), in commit 4d94b031ff88.  Switch to the macro name they
      MFC after:	1 week
      Sponsored by:	The FreeBSD Foundation
      (cherry picked from commit 6e24fe61)
      (cherry picked from commit 41406f9251c0e186fe820f70e9da0606bff71dae)
    • Greg Foster's avatar
      lacp: short timeout erroneously declares link-flapping · 3cbc8109
      Greg Foster authored
      Panasas was seeing a higher-than-expected number of link-flap events.
      After joint debugging with the switch vendor, we determined there were
      problems on both sides; either of which might cause the occasional
      event, but together caused lots of them.
      On the switch side, an internal queuing issue was causing LACP PDUs --
      which should be sent every second, in short-timeout mode -- to sometimes
      be sent slightly later than they should have been. In some cases, two
      successive PDUs were late, but we never saw three late PDUs in a row.
      On the FreeBSD side, we saw a link-flap event every time there were two
      late PDUs, while the spec says that it takes *three* seconds of downtime
      to trigger that event. It turns out that if a PDU was received shortly
      before the timer code was run, it would decrement less than a full
      second after the PDU arrived. Then two delayed PDUs would cause two
      additional decrements, causing it to reach zero less than three seconds
      after the most-recent on-time PDU.
      The solution is to note the time a PDU arrives, and only decrement if at
      least a full second has elapsed since then.
      Reported by:	Greg Foster <gfoster@panasas.com>
      Reviewed by:	gallatin
      Tested by:	Greg Foster <gfoster@panasas.com>
      MFC after:	3 days
      Sponsored by:	Panasas
      Differential Revision:	https://reviews.freebsd.org/D35070
      (cherry picked from commit 00a80538)
  6. 28 Apr, 2022 2 commits
  7. 27 Apr, 2022 10 commits
    • HardenedBSD Sync Service's avatar
    • Hans Petter Selasky's avatar
      xhci(4): Ensure the so-called data toggle gets properly reset. · 8a047df9
      Hans Petter Selasky authored
      Use the drop and enable endpoint context commands to force a reset of
      the data toggle for USB 2.0 and USB 3.0 after:
       - clear endpoint halt command (when the driver wishes).
       - set config command (when the kernel or user-space wants).
       - set alternate setting command (only affected endpoints).
      Some XHCI HW implementations may not allow the endpoint reset command when
      the endpoint context is not in the halted state.
      Reported by:		Juniper and Gary Jennejohn
      MFC after:		1 week
      Sponsored by:		NVIDIA Networking
      (cherry picked from commit cda31e73)
    • J.R. Oldroyd's avatar
      e1000: Try auto-negotiation for fixed 100 or 10 configuration · 59fc91f9
      J.R. Oldroyd authored
      Currently if an e1000 interface is set to a fixed media configuration,
      for gigabit, it will participate in auto-negotiation as required by
      IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration
      for 100 or 10, it does NOT participate in auto-negotiation.
      By my reading of Clauses 28 and 37, while auto-negotiation is optional
      for 100 and 10, it is not prohibited and is, in fact, "highly
      This patch enables auto-negotiation for fixed 100 and 10 media
      configuration, in a similar manner to that already performed for 1000.
      I.e., the patch enables advertising of just the manually configured
      settings with the goal of allowing the remote end to match the manually
      configured settings if it has them available.
      To be clear, this patch does NOT allow an em(4) interface that has been
      manually configured with specific media settings to respond to
      auto-negotiation by then configuring different parameters to those that
      were manually configured. The intent of this patch is to fully comply
      with the requirements of Clause 37, but for 100 and 10.
      The need for this has arisen on an em(4) link where the other end is
      under a different administrative control and is set to full
      auto-negotiation. Due to the cable length GigE is not working well. It
      is desired to set the em(4) end to "media 100baseTX mediatype
      full-duplex" which does work when both ends are configured that way.
      Currently, because em(4) does not participate in autoneg for this
      setting, the remote defaults to half-duplex - i.e., there's a duplex
      mismatch and things don't work. With this patch, em(4) would inform the
      remote that it has only 100baseTX full, the remote would match that and
      it will work.
      Approved by:	erj
      Differential Revision:	https://reviews.freebsd.org/D34449
      (cherry picked from commit 9ab4dfce)
    • Kevin Bowling's avatar
      e1000: Update mc filter before RCTL flags · adf0ac34
      Kevin Bowling authored
      Update mc filter array before changing RCTL flags as in 5a3eb620
      Approved by:	grehan
      (cherry picked from commit 07ede751)
    • Kevin Bowling's avatar
      ixgbe: Update mc filter before FCTRL flags · fc3ef237
      Kevin Bowling authored
      Update mc filter array before changing FCTRL flags, similar to 5a3eb620
      Approved by:	grehan
      (cherry picked from commit 395cc55d)
    • HardenedBSD Sync Service's avatar
    • Kristof Provost's avatar
      pf: counter argument to pfr_pool_get() may never be NULL · a618bb0f
      Kristof Provost authored
      Coverity points out that if counter was NULL when passed to
      pfr_pool_get() we could potentially end up dereferencing it.
      Happily all users of the function pass a non-NULL pointer. Enforce this
      by assertion and remove the pointless NULL check.
      Reported by:	Coverity (CID 273309)
      MFC after:	1 week
      Sponsored by:	Rubicon Communications, LLC ("Netgate")
      (cherry picked from commit efc64d02)
    • Kristof Provost's avatar
      pfsync: NULL check before dereference · f3b722fe
      Kristof Provost authored
      Move the use of 'sc' to after the NULL check.
      It's very unlikely that we'd actually hit this, but Coverity is correct
      that it's not a good idea to dereference the pointer and only then NULL
      check it.
      Reported by:	Coverity (CID 1398362)
      MFC after:	1 week
      Sponsored by:	Rubicon Communications, LLC ("Netgate")
      (cherry picked from commit 43020350)
    • Kristof Provost's avatar
      pf: remove pointless NULL check · 5bc3ab86
      Kristof Provost authored
      pfi_kkif_attach() always returns non-NULL, and we dereference the
      pointer before we check it, so that's pointless.
      Reported by:	Coverity (CID 1007345)
      MFC after:	1 week
      Sponsored by:	Rubicon Communications, LLC ("Netgate")
      (cherry picked from commit ed6287c1)
    • Kristof Provost's avatar
      callout: fix using shared rmlocks · 8bd26421
      Kristof Provost authored
      15b1eb14 changed the callout code to store the CALLOUT_SHAREDLOCK flag
      in c_iflags (where it used to be c_flags), but failed to update the
      check in softclock_call_cc(). This resulted in the callout code always
      taking the write lock, even if a read lock had been requested (with
      the CALLOUT_SHAREDLOCK flag in callout_init_rm()).
      Reviewed by:	markj
      MFC after:	1 week
      Sponsored by:	Rubicon Communications, LLC ("Netgate")
      Differential Revision:	https://reviews.freebsd.org/D34959
      (cherry picked from commit a879e40c)
  8. 26 Apr, 2022 3 commits