Reported by:	Mark Millard on freebsd-current@
Fixes:		c763f99d11fd ("elfctl: prefix disable flags with "no"")
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation

MFC after:	2 weeks
MFC with:	00134a07898fa807b8a1fcb2596f0e3644143f69
Reported by:	se

Reviewed by:	markj
Obtained from:	CheriBSD
Differential Revision:	https://reviews.freebsd.org/D34173

- Add a missing ')' to a warning.

- Consistently use {} when expanding variables.

- Remove a spurious blank line.

Reviewed by:	imp, emaste
Obtained from:	CheriBSD
Differential Revision:	https://reviews.freebsd.org/D34172

sbcut() returns mbufs in reverse order so is not suitable for reading
data from the socket buffer.  Instead, check for already-received data
in the receive worker thread before passing offload PDUs up to the
iSCSI layer.  This uses soreceive() to read data from the socket and
is also to use M_WAITOK since it now runs from a worker thread instead
of an interrupt thread.

Also, fix decoding of the data segment length for pre-offload PDUs.

Reported by:	Jithesh Arakkan @ Chelsio
Fixes:		a8c4147edcdc cxgbei: Parse all PDUs received prior to enabling offload mode.
Sponsored by:	Chelsio Communications

FUSE file systems that do not set FUSE_NO_OPENDIR_SUPPORT do not
guarantee that d_off will be valid after closing and reopening a
directory.  That conflicts with NFS's statelessness, that results in
unresolvable bugs when NFS reads large directories, if:

* The file system _does_ change the d_off field for the last directory
  entry previously returned by VOP_READDIR, or
* The file system deletes the last directory entry previously seen by
  NFS.

Rather than doing a poor job of exporting such file systems, it's better
just to refuse.

Even though this is technically a breaking change, 13.0-RELEASE's
NFS-FUSE support was bad enough that an MFC should be allowed.

MFC after:	3 weeks.
Reviewed by:	rmacklem
Differential Revision: https://reviews.freebsd.org/D33726

In its lowest common denominator, FUSE does not require that a directory
entry's d_off field is valid outside of the lifetime of the directory's
FUSE file handle.  But since NFS is stateless, it must reopen the
directory on every call to VOP_READDIR.  That means reading the
directory all the way from the first entry.  Not only does this create
an O(n^2) condition for large directories, but it can also result in
incorrect behavior if either:

* The file system _does_ change the d_off field for the last directory
  entry previously seen by NFS, or
* The file system deletes the last directory entry previously seen by
  NFS.

Handily, for file systems that set FUSE_NO_OPENDIR_SUPPORT d_off is
guaranteed to be valid for the lifetime of the directory entry, there is
no need to read the directory from the start.

MFC after:	3 weeks
Reviewed by:	rmacklem

The FUSE protocol does not require that a directory entry's d_off field
outlive the lifetime of its directory's file handle.  Since the NFS
server must reopen the directory on every VOP_READDIR call, that means
it can't pass uio->uio_offset down to the FUSE server.  Instead, it must
read the directory from 0 each time.  It may need to issue multiple
FUSE_READDIR operations until it finds the d_off field that it's looking
for.  That was the intention behind SVN r348209 and r297887, but a logic
bug prevented subsequent FUSE_READDIR operations from ever being issued,
rendering large directories incompletely browseable.

MFC after:	3 weeks
Reviewed by:	rmacklem