Skip to content
GitLab
  1. 26 Oct, 2021 1 commit
    • Rick Macklem's avatar
      nfscl: Add a missing delegation lock release · 23024f00
      Rick Macklem authored 
      There was a case in nfscl_doiods() where the function would return
without releasing the delegation shared lock, if it was aquired by
the call to nfscl_getstateid().  This patch adds that release.

I have never observed a failure due to this missing release, so I
do not know if it ever happens in practice.  However, since the pNFS
client is not yet heavily used, it might be the case.

Found by code inspection during a recent NFSv4 IETF working group
testing event.

MFC after:	2 week
      23024f00
  3. 25 Oct, 2021 23 commits
  5. 24 Oct, 2021 4 commits
    • Mateusz Piotrowski's avatar
      Makefile.inc1: Remove mentions of removed target "update" · eab5358b
      Mateusz Piotrowski authored 
      This is follow-up to commits e290182b and 1f7d11e6.
      eab5358b
    • Hans Petter Selasky's avatar
      usb(4): Fix for use after free in combination with EVDEV_SUPPORT. · aad0c65d
      Hans Petter Selasky authored 
      When EVDEV_SUPPORT was introduced, the USB transfers may be running
after the main FIFO is closed. In connection to this a race may appear
which can lead to use-after-free scenarios. Fix this for all FIFO
consumers by initializing and resetting the FIFO queues under the
lock used by the client. Then the client driver will see an empty
queue in all cases a race may appear.

Found by:	pho@
MFC after:	1 week
Sponsored by:	NVIDIA Networking
      aad0c65d
    • Hans Petter Selasky's avatar
      mixer(3): Fix spelling in comment. · 790b5264
      Hans Petter Selasky authored 
      s/MIX_STATUS_XXX/MIX_MODE_XXX/g

Differential Revision:	https://reviews.freebsd.org/D32548
Submitted by:	christos@
Sponsored by:	NVIDIA Networking
      790b5264
    • Jason A. Harmening's avatar
      unionfs: implement vnode-based cache lookup · fd8ad212
      Jason A. Harmening authored 
      unionfs uses a per-directory hashtable to cache subdirectory nodes.
Currently this hashtable is looked up using the directory name, but
since unionfs nodes aren't removed from the cache until they're
reclaimed, this poses some problems.  For example, if a directory is
created on a unionfs mount shortly after deleting a previous directory
with the same path, the cache may end up reusing the node for the
previous directory, including its upper/lower FS vnodes.  Operations
against those vnodes with then likely fail because the vnodes
represent deleted files; for example UFS will reject VOP_MKDIR()
against such a vnode because its effective link count is 0.  This may
then manifest as e.g. mkdir(2) or open(2) returning ENOENT for an
attempt to create a file under the re-created directory.

While it would be possible to fix this by explicitly managing the
name-based cache during delete or rename operations, or by rejecting
cache hits if the underlying FS vnodes don't match those passed to
unionfs_nodeget(), it seems cleaner to instead hash the unionfs nodes
based on their underlying FS vnodes.  Since unionfs prefers to operate
against the upper vnode if one is present, the lower vnode will only
be used for hashing as long as the upper vnode is NULL.  This should
also make hashing faster by eliminating string traversal and using
the already-computed hash index stored in each vnode.

While here, fix a couple of other cache-related issues:

--Remove 8 bytes of unnecessary baggage from each unionfs node by
  getting rid of the stored hash mask field.  The mask is knowable
  at compile time.

--When a matching node is found in the cache, reference its vnode
  using vrefl() while still holding the vnode interlock.  Previously
  unionfs_nodeget() would vref() the vnode after the interlock was
  dropped, but the vnode may be reclaimed during that window.  This
  caused intermittent panics from vn_lock(9) during unionfs stress
  testing.

Reviewed by:	kib, markj
Tested by:	pho
Differential Revision:	https://reviews.freebsd.org/D32533
      fd8ad212
  7. 23 Oct, 2021 1 commit
    • Kirk McKusick's avatar
      Allow biodone() to be used as a completion routine. · dfd704b7
      Kirk McKusick authored 
      An ordered series of BIO_READ and BIO_WRITE operations are
typically done as:

	while (work to do) {
		setup bp for I/O
		g_io_request(bp, consumer);
		biowait(bp);
	}

Here you need to have biodone() called at the completion of
the I/O to set the BIO_DONE flag and awaken the biowait(). The
obvious way to do this would be to set bio_done = biodone, but
biodone() will only take the desired action if bio_done == NULL.
The relevant code at the end of biodone() is:

	done = bp->bio_done;
	if (done == NULL) {
		mtxp = mtx_pool_find(mtxpool_sleep, bp);
		mtx_lock(mtxp);
		bp->bio_flags |= BIO_DONE;
		wakeup(bp);
		mtx_unlock(mtxp);
	} else
		done(bp);

This code would infinitely recurse if biodone() is specified as the
routine to use at completion. So before this change, a wrapper done
function had to be written:

static void
g_io_done(struct bio *bp)
{

	bp->bio_done = NULL;
	biodone(bp);
	bp->bio_done = g_io_done;
}

This commit changes

	if (done == NULL)

to

	if (done == NULL || done == biodone)

which eliminates the need for the wrapper function.

Reviewed by:  kib
Sponsored by: Netflix
      dfd704b7
  9. 24 Oct, 2021 1 commit
  11. 23 Oct, 2021 9 commits
  13. 22 Oct, 2021 1 commit
    • Ed Maste's avatar
      Add libfido2 to the build · 7b1e19ad
      Ed Maste authored 
      From https://github.com/Yubico/libfido2:

    libfido2 provides library functionality and command-line tools to
    communicate with a FIDO device over USB, and to verify attestation
    and assertion signatures.

    libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2)
    protocols.

libfido2 will be used by ssh to support FIDO/U2F keys. It is currently
intended only for use by ssh, and so is installed as a PRIVATELIB and is
placed in the ssh pkgbase package.

This is currently disabled for the 32-bit library build as libfido2 is
not compatible with the COMPAT_32BIT hack in usb_ioctl.h.

Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D32448
      7b1e19ad