9fc7a59f ian Feb. 11, 2017, 1:07 a.m.
where atomic.h was being included without ensuring that types.h (via
param.h) was included first, as required by atomic(9).
cgit ViewVC
333b68ab mm Feb. 11, 2017, 1 a.m.
Sync libarchive with vendor

Vendor bugfixes:
cpio reader sanity fix (OSS-Fuzz 504)
WARC reader sanity fixes (OSS-Fuzz 511, 526, 532, 552)
mtree reader time parsing fix (OSS-Fuzz 538)
XAR reader memleak fix (OSS-Fuzz 551)

MFC after:	1 week
cgit ViewVC
b291029e behlendorf1 Feb. 11, 2017, 12:09 a.m.
- Pass $VDEV_ENC_SYSFS_PATH to 'zpool [iostat|status] -c' to include
  enclosure LED sysfs path.

- Set LEDs correctly after import.  This includes clearing any erroniously
  set LEDs prior to the import, and setting the LED for any UNAVAIL drives.

- Include symlink for vdev_attach-led.sh in Makefile.am.

- Print the VDEV path in all-syslog.sh, and fix it so the pool GUID actually
  prints.    

Reviewed-by: Don Brady <don.brady@intel.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Tony Hutter <hutter2@llnl.gov>
Closes #5716 
Closes #5751
cgit
65a736bc behlendorf1 Feb. 10, 2017, 11:18 p.m.
This clears vdev_enc_sysfs_path from the label if the VDEV's
/sys/class/block/<dev>/device/enclosure_device path isn't present.

This is important in the case where a disk that is labeled with
vdev_enc_sysfs_path is pulled out and put into another enclosure.
In that case, it's possible that the old sysfs path would be used to
turn on the fault LED for the disk's old slot postion, assuming the
new slot didn't have a LED sysfs entry.

Reviewed-by: Don Brady <don.brady@intel.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Tony Hutter <hutter2@llnl.gov>
Closes #5524 
Closes #5773
cgit
638a0d36 mm Feb. 10, 2017, 11:12 p.m.
Vendor bugfixes:
cpio reader sanity fix (OSS-Fuzz 504)
WARC reader sanity fixes (OSS-Fuzz 511, 526, 532, 552)
mtree reader time parsing fix (OSS-Fuzz 538)
XAR reader memleak fix (OSS-Fuzz 551)
cgit ViewVC
28ef82eb ken Feb. 10, 2017, 10:02 p.m.
The isp(4) driver was changing the tag type for REQUEST SENSE
commands to Head of Queue, when the CAM CCB flag
CAM_TAG_ACTION_VALID was NOT set.  CAM_TAG_ACTION_VALID is set
when the tag action in the XPT_SCSI_IO is not CAM_TAG_ACTION_NONE
and when the target has tagged queueing turned on.

In most cases when CAM_TAG_ACTION_VALID is not set, it is because
the target is not doing tagged queueing.  In those cases, trying to
send a Head of Queue tag may cause problems.  Instead, default to
sending a simple tag.

IBM tape drives claim to support tagged queueing in their standard
Inquiry data, but have the DQue bit set in the control mode page
(mode page 10).  CAM correctly detects that these drives do not
support tagged queueing, and clears the CAM_TAG_ACTION_VALID flag
on CCBs sent down to the drives.

This caused the isp(4) driver to go down the path of setting the
tag action to a default value, and for Request Sense commands only,
set the tag action to Head of Queue.

If an IBM tape drive does get a Head of Queue tag, it rejects it with
Invalid Message Error (0x49,0x00).  (The Qlogic firmware translates that
to a Transport Error, which the driver translates to an Unrecoverable
HBA Error, or CAM_UNREC_HBA_ERROR.) So, by default, it wasn't possible
to get a good response from a REQUEST SENSE to an FC-attached IBM
tape drive with the isp(4) driver.

IBM tape drives (tested on an LTO-5 with G9N1 firmware and a TS1150
with 4470 firmware) also have a bug in that sending a command with a
non-simple tag attribute breaks the tape drive's Command Reference
Number (CRN) accounting and causes it to ignore all subsequent
commands because it and the initiator disagree about the next
expected CRN.  The drives do reject the initial command with a head
of queue tag with an Invalid Message Error (0x49,0x00), but after that
they ignore any subsequent commands.  IBM confirmed that it is a bug,
and sent me test firmware that fixes the bug.  However tape drives in
the field will still exhibit the bug until they are upgraded.

Request Sense is not often sent to targets because most errors are
reported automatically through autosense in Fibre Channel and other
modern transports.  ("Modern" meaning post SCSI-2.)  So this is not
an error that would crop up frequently.  But Request Sense is useful on
tape devices to report status information, aside from error reporting.

This problem is less serious without FC-Tape features turned on,
specifically precise delivery of commands (which enables Command
Reference Numbers), enabled on the target and initiator.  Without
FC-Tape features turned on, the target would return an error and
things would continue on.

And it also does not cause problems for targets that do tagged
queueing, because in those cases the isp(4) driver just uses the
tag type that is specified in the CCB, assuming the
CAM_TAG_ACTION_VALID flag is set, and defaults to sending a Simple
tag action if it isn't an ordered or head of queue tag.

sys/dev/isp/isp.c:
	In isp_start(), don't try to send Request Sense commands
	with the Head of Queue tag attribute if the CCB doesn't
	have a valid tag action.  The tag action likely isn't valid
	because the target doesn't support tagged queueing.

Sponsored by:	Spectra Logic
MFC after:	3 days
cgit ViewVC
bb9b7104 jhb Feb. 10, 2017, 7:45 p.m.
One of the ibcs2 files contains some actual changes (new headers) as
it hasn't been regenerated after older changes to makesyscalls.sh.
cgit ViewVC
28e59198 ngie Feb. 10, 2017, 7:31 p.m.
Some recent changes to vm related to mmap(2) have broken the prot checks that
would result with an EINVAL with this case

I suspect r313352 is the root-cause the issue

PR:		216976
Sponsored by:	Dell EMC Isilon
cgit ViewVC
807a7231 jhb Feb. 10, 2017, 7:25 p.m.
This information is less useful when the generated files are included in
source control along with the source.  If needed it can be reconstructed
from the $FreeBSD$ tag in the generated file.  Removing this information
from the generated output permits committing the generated files along
with the change to the system call master list without having inconsistent
metadata in the generated files.

Reviewed by:	emaste, kib
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D9497
cgit ViewVC
b6c03f21 emaste Feb. 10, 2017, 7:17 p.m.
ld.bfd generates two PT_LOAD segments, but certain linkers or linker
configurations generate three PT_LOAD segments (one additional for
RELRO).

PR:		216975
Reported by:	Shawn Webb
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
cgit ViewVC
d65b2f7e emaste Feb. 10, 2017, 7:11 p.m.
The message refers to program header segments, not sections.

PR:		216975
cgit ViewVC
449705db behlendorf1 Feb. 10, 2017, 6:54 p.m.
Authored by: Simon Klinkert <simon.klinkert@gmail.com>
Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
Reviewed by: John Kennedy <john.kennedy@delphix.com>
Approved by: Richard Lowe <richlowe@richlowe.net>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Ported-by: George Melikov <mail@gmelikov.ru>

OpenZFS-issue: https://www.illumos.org/issues/5704
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/bde3d61
Closes #5767
cgit
cfff3743 glebius Feb. 10, 2017, 5:46 p.m.
friend tcp_fields_to_host(). There is third party code that also uses
this inline.

Reviewed by:	ae
cgit ViewVC
10addc1e glebius Feb. 10, 2017, 5:37 p.m.
00dffd7e glebius Feb. 10, 2017, 5:34 p.m.
On other systems it may be API structure for SIOCADDRT/SIOCDELRT.

Reviewed by:	emaste, dim
cgit ViewVC