ken [Fri, 9 May 2014 03:59:12 +0000 (03:59 +0000)]
MFC mpr(4) driver changes.
This includes r265386, r265424, and r265473.
------------------------------------------------------------------------
r265386 | ken | 2014-05-05 13:53:03 -0600 (Mon, 05 May 2014) | 15 lines
Adjust #if statements inside mprsas_send_smpcmd() to more accurately
reflect when unmapped I/O support was added.
For FreeBSD 10, it arrived just prior to __FreeBSD_version 1000028.
For FreeBSD 9, it arrived just prior to __FreeBSD_version 902001.
Also, fix compiler warnings in mprsas_send_smpcmd() that happen in the
i386 PAE build for non-unmapped I/O builds. These were fixed in mps(4)
in revision 241145, but didn't make it into the mpr(4) driver. This
change should only affect FreeBSD versions outside the above revisions,
and thus doesn't affect head.
Sponsored by: Spectra Logic Corporation
------------------------------------------------------------------------
------------------------------------------------------------------------
r265424 | ken | 2014-05-06 00:18:43 -0600 (Tue, 06 May 2014) | 33 lines
Fix a problem with async notifications in the mpr(4) driver.
This problem only occurs on versions of FreeBSD prior to the recent CAM
locking changes. (i.e. stable/9 and older versions of stable/10) This
change should be a no-op for head and stable/10.
If a path isn't specified, xpt_register_async() will create a fully
wildcarded path and acquire a lock (the XPT lock in older versions,
and via xpt_path_lock() in newer versions) to call xpt_action() for the
XPT_SASYNC_CB CCB. It will then drop the lock and if the requested event
includes AC_FOUND_DEVICE or AC_PATH_REGISTERED, it will get the caller up
to date with any device arrivals or path registrations.
The issue is that before the locking changes, each SIM lock would get
acquired in turn during the EDT tree traversal process. If a path is
specified for xpt_register_async(), it won't acquire and drop its own lock,
but instead expects the caller to hold its own SIM lock. That works for
the first part of xpt_register_async(), but causes a recursive lock
acquisition once the EDT traversal happens and it comes to the SIM in
question. And it isn't possible to call xpt_action() without holding a SIM
lock.
The locking changes fix this by using the XPT topology lock for EDT
traversal, so it is no longer an issue to hold the SIM lock while calling
xpt_register_async().
The solution for FreeBSD versions before the locking changes is to request
notification of all device arrivals (so we pass a NULL path into
xpt_register_async()) and then filter out the arrivals that are not ours.
Sponsored by: Spectra Logic Corporation
------------------------------------------------------------------------
------------------------------------------------------------------------
r265473 | ken | 2014-05-06 16:13:38 -0600 (Tue, 06 May 2014) | 7 lines
Change the device name for mpr(4) from /dev/mpr_N to /dev/mprN.
This is more consistent with the existing mps(4) behavior.
Reviewed by: Steve McConnell <stephen.mcconnell@avagotech.com>
melifaro [Thu, 8 May 2014 21:03:31 +0000 (21:03 +0000)]
Merge 260488, r260508.
r260488:
Split rt_newaddrmsg_fib() into two different functions.
Adding/deleting interface addresses involves access to 3 different subsystems,
int different parts of code. Each call can fail, so reporting successful
operation by rtsock in the middle of the process error-prone.
Further split routing notification API and actual rtsock calls via creating
public-available rt_addrmsg() / rt_routemsg() functions with "private"
rtsock_* backend.
r260508:
Simplify inet alias handling code: if we're adding/removing alias which
has the same prefix as some other alias on the same interface, use
newly-added rt_addrmsg() instead of hand-rolled in_addralias_rtmsg().
This eliminates the following rtsock messages:
Pinned RTM_ADD for prefix (for alias addition).
Pinned RTM_DELETE for prefix (for alias withdrawal).
Example (got 10.0.0.1/24 on vlan4, playing with 10.0.0.2/24):
before commit, addition:
got message of size 116 on Fri Jan 10 14:13:15 2014
RTM_NEWADDR: address being added to iface: len 116, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
255.255.255.0 vlan4:8.0.27.c5.29.d4 10.0.0.2 10.0.0.255
got message of size 192 on Fri Jan 10 14:13:15 2014
RTM_ADD: Add Route: len 192, pid: 0, seq 0, errno 0, flags:<UP,PINNED>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>
10.0.0.0 10.0.0.2 (255) ffff ffff ff
after commit, addition:
got message of size 116 on Fri Jan 10 13:56:26 2014
RTM_NEWADDR: address being added to iface: len 116, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
255.255.255.0 vlan4:8.0.27.c5.29.d4 14.0.0.2 14.0.0.255
before commit, wihdrawal:
got message of size 192 on Fri Jan 10 13:58:59 2014
RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, flags:<UP,PINNED>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>
10.0.0.0 10.0.0.2 (255) ffff ffff ff
got message of size 116 on Fri Jan 10 13:58:59 2014
RTM_DELADDR: address being removed from iface: len 116, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
255.255.255.0 vlan4:8.0.27.c5.29.d4 10.0.0.2 10.0.0.255
adter commit, withdrawal:
got message of size 116 on Fri Jan 10 14:14:11 2014
RTM_DELADDR: address being removed from iface: len 116, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
255.255.255.0 vlan4:8.0.27.c5.29.d4 10.0.0.2 10.0.0.255
Sending both RTM_ADD/RTM_DELETE messages to rtsock is completely wrong
(and requires some hacks to keep prefix in route table on RTM_DELETE).
I've tested this change with quagga (no change) and bird (*).
bird alias handling is already broken in *BSD sysdep code, so nothing
changes here, too.
I'm going to MFC this change if there will be no complains about behavior
change.
While here, fix some style(9) bugs introduced by r260488
(pointed by glebius and bde).
rmacklem [Thu, 8 May 2014 20:52:25 +0000 (20:52 +0000)]
MFC: r265252
The new draft specification for NFSv4.0 specifies that a server
should either accept owner and owner_group strings that are just
the digits of the uid/gid or return NFS4ERR_BADOWNER.
This patch adds a sysctl vfs.nfsd.enable_stringtouid, which can
be set to enable the server w.r.t. accepting numeric string. It
also ensures that NFS4ERR_BADOWNER is returned if numeric uid/gid
strings are not enabled. This fixes the server for recent Linux
nfs4 clients that use numeric uid/gid strings by default.
melifaro [Thu, 8 May 2014 20:27:06 +0000 (20:27 +0000)]
Merge r259528, r259528, r260295.
r259528:
Simplify contiguous mask checking.
Suggested by: glebius
r260228:
Remove useless register variable modifiers.
Do some more style(9).
r260295:
Change semantics for rnh_lookup() function: now
it performs exact match search, regardless of netmask existance.
This simplifies most of rnh_lookup() consumers.
Fix panic triggered by deleting non-existent host route.
PR: kern/185092
Submitted by: Nikolay Denev <ndenev at gmail.com>
melifaro [Thu, 8 May 2014 19:11:41 +0000 (19:11 +0000)]
Merge r258708, r258711, r260247, r261117.
r258708:
Check ipfw table numbers in both user and kernel space before rule addition.
Found by: Saychik Pavel <umka@localka.net>
r258711:
Simplify O_NAT opcode handling.
r260247:
Use rnh_matchaddr instead of rnh_lookup for longest-prefix match.
rnh_lookup is effectively the same as rnh_matchaddr if called with
empy network mask.
r261117:
Reorder struct ip_fw_chain:
* move rarely-used fields down
* move uh_lock to different cacheline
* remove some usused fields
melifaro [Thu, 8 May 2014 18:09:32 +0000 (18:09 +0000)]
Merge r258677.
Fix key lookup in ipfw(8) broken since r232865.
Print warning for IPv4 address strings which are valid in
inet_aton() but not valid in inet_pton(). (1)
Found by: Özkan KIRIK <ozkan.kirik@gmail.com>
Submitted by: Ian Smith <smithi@nimnet.asn.au> (1)
mav [Thu, 8 May 2014 13:12:24 +0000 (13:12 +0000)]
MFC r264145:
Add property and sysctl to control how ZVOLs are exposed to OS.
New ZFS property volmode and sysctl vfs.zfs.vol.mode allow switching ZVOL
between three modes:
geom -- existing fully functional behavior (default);
dev -- exposing volumes only as raw disk device file in devfs;
none -- not exposing volumes outside ZFS.
The "dev" mode is less functional (can't be partitioned, mounted, etc),
but it is faster, and in some scenarios with untrusted consumers safer.
It can be useful for NAS, VM block storages, etc.
The "none" mode may be convenient for backup servers, etc. that don't
need direct data access.
Due to the way ZVOL is integrated with main ZFS code, those property
and sysctl are checked only during pool import and volume creation.
mav [Thu, 8 May 2014 12:07:40 +0000 (12:07 +0000)]
MFC r265054:
Reduce number of opens by REOM RAID during provider taste.
Instead opening/closing provider by each of metadata classes, do it only
once in core code. Since for SCSI disks open/close means sending some
SCSI commands to the device, this change reduces taste time.
rmacklem [Thu, 8 May 2014 11:59:23 +0000 (11:59 +0000)]
MFC: r264888
The PR reported that the old NFS server did not set uio_td == NULL
for the VOP_READ() call. This patch fixes both the old and new
server for this case.
mav [Thu, 8 May 2014 07:12:06 +0000 (07:12 +0000)]
MFC r265150:
Do not reread SCSI disk VPD pages on every device open.
Instead of rereading VPD pages on every device open, do it only on initial
device probe, and in cases when device reported via UNIT ATTENTIONs that
something has changed. Capacity is still rereaded on every open because
it is more critical for operation and more probable to change in run time.
On my tests with Intel 530 SSDs on mps(4) HBA this change reduces time
GEOM needs to retaste the device (that includes few open/close cycles)
from ~150ms to ~30ms.
mav [Thu, 8 May 2014 07:10:38 +0000 (07:10 +0000)]
MFC r264886:
Remove limits on size of READ/WRITE operations.
Instead of allocating up to 16MB or RAM at once to handle whole I/O,
allocate up to 1MB at a time, but do multiple ctl_datamove() and storage
I/Os if needed.
mav [Thu, 8 May 2014 07:00:45 +0000 (07:00 +0000)]
MFC r264274, r264279, r264283, r264296, r264297:
Add support for SCSI UNMAP commands to CTL.
This patch adds support for three new SCSI commands: UNMAP, WRITE SAME(10)
and WRITE SAME(16). WRITE SAME commands support both normal write mode
and UNMAP flag. To properly report UNMAP capabilities this patch also adds
support for reporting two new VPD pages: Block limits and Logical Block
Provisioning.
UNMAP support can be enabled per-LUN by adding "-o unmap=on" to `ctladm
create` command line or "option unmap on" to lun sections of /etc/ctl.conf.
At this moment UNMAP supported for ramdisks and device-backed block LUNs.
It was tested to work great with ZFS ZVOLs. For file-backed LUNs UNMAP
support is unfortunately missing due to absence of respective VFS KPI.
rmacklem [Wed, 7 May 2014 22:33:36 +0000 (22:33 +0000)]
MFC: r264845
Remove an unnecessary level of indirection for an argument.
This simplifies the code and should avoid the clang sparc
port from generating an abort() call.
rmacklem [Wed, 7 May 2014 22:27:03 +0000 (22:27 +0000)]
MFC: r264842
Modify the NFSv4 client's Pathconf RPC (actually a Getattr Op.)
so that it only does the RPC for names that are answered by the RPC.
Doing the RPC for other names is harmless, but unnecessary.
gavin [Wed, 7 May 2014 21:38:33 +0000 (21:38 +0000)]
Merge r259393 from head:
Fix several panics when initialization of an ISA or PC-CARD device fails:
o Assign sc->an_dev in an_probe() (which isn't really a probe function in
the standard newbus sense) as we may need it for printing errors.
o Use device_printf() rather than if_printf() in an_reset() - this is
called from an_probe() long before the ifp structure is initialised
in an_attach().
o Initialize the ifp structure early in an_attach() as we use if_printf()
in cases where allocation of descriptors etc fails.
scottl [Wed, 7 May 2014 20:28:27 +0000 (20:28 +0000)]
Merge r264984
Retire smp_active. It was racey and caused demonstrated problems with
the cpufreq code. Replace its use with smp_started. There's at least
one userland tool that still looks at the kern.smp.active sysctl, so
preserve it but point it to smp_started as well.
asomers [Wed, 7 May 2014 18:49:25 +0000 (18:49 +0000)]
MFC r263445 and r265385. Note that the change to ObsoleteFiles.inc in
r265385 does not need to be MFCed, because the obsolete files in question
were never MFCed to any stable branch.
r265385
Remove the ifconfig test added in rev 263445. After discussion with
melifaro, we agreed that ifconfig's behavior was not a bug. The main
motivation for bin/187551 was to partially resolve kern/187549, but we
resolved kern/187549 in a different way instead.
r263445
Add several ATF tests that deal with multiple fibs. They're described in
several different PRs, but the tests share some common code, so I'm
committing them together.
sbin/ifconfig/tests
sbin/ifconfig/tests/fibs_test.sh
sbin/ifconfig/tests/Makefile
sbin/ifconfig/Makefile
Add fibs_test.sh, which regresses bin/187551
tests/sys/netinet
tests/sys/netinet/fibs_test.sh
tests/sys/netinet/udp_dontroute.c
tests/sys/netinet/Makefile
tests/sys/Makefile
Add fibs_test.sh, which regresses kern/167947, kern/187552
kern/187549, kern/187550, and kern/187553
etc/mtree/BSD.tests.dist
Add newly created directories
jimharris [Wed, 7 May 2014 17:00:39 +0000 (17:00 +0000)]
MFC r263277:
nvme: Remove the software progress marker SET_FEATURE command during
controller initialization.
The spec says OS drivers should send this command after controller
initialization completes successfully, but other NVMe OS drivers are
not sending this command. This change will therefore reduce differences
between the FreeBSD and other OS drivers.
jimharris [Wed, 7 May 2014 16:55:08 +0000 (16:55 +0000)]
MFC r260382:
For IDENTIFY passthrough commands to Chatham prototype controllers, copy
the spoofed identify data into the user buffer rather than issuing the
command to the controller, since Chatham IDENTIFY data is always spoofed.
While here, fix a bug in the spoofed data for Chatham submission and
completion queue entry sizes.
jimharris [Wed, 7 May 2014 16:53:42 +0000 (16:53 +0000)]
MFC r260381:
For "nvmecontrol devlist", show namespace sizes in terms of MB instead of
GB to improve granularity of the reporting - especially for namespaces
that are on the order of 1 or 2 GB.
jimharris [Wed, 7 May 2014 16:52:29 +0000 (16:52 +0000)]
MFC r258071:
Check for special status code from FIRMWARE_ACTIVATE command
signifying that a reboot is required to complete activation
of the requested firmware image.
trasz [Wed, 7 May 2014 07:56:36 +0000 (07:56 +0000)]
MFC r264549:
Make it possible for the initiator side to operate in both proxy
and normal mode; this makes it possible to compile with the former
by default, but use it only when neccessary. That's especially
important for the userland part.
trasz [Wed, 7 May 2014 07:35:21 +0000 (07:35 +0000)]
MFC r264528:
Rework the way we enable CTL iSCSI port. Previously conf_apply()
needed it to be already enabled, because listening in proxy mode
requires it; however, it's conf_apply() that opens pidfiles,
so it resulted in port being enabled before pidfile was opened.
This was not so bad, but it was also disabled when pidfile couldn't
be opened due to ctld already running; this means that starting
second ctld instance screwed up the first.
trasz [Wed, 7 May 2014 07:29:39 +0000 (07:29 +0000)]
MFC r264524:
Make it possible for the iSCSI target side to operate in both normal
and ICL_KERNEL_PROXY mode, and fix some bit rot so the latter actually
works again.
trasz [Wed, 7 May 2014 06:38:19 +0000 (06:38 +0000)]
MFC r264025:
Get rid of the "autoscaling", instead just set socket buffer sizes
in the usual way. The only thing the old code did was making things
less predictable.
trasz [Wed, 7 May 2014 06:29:01 +0000 (06:29 +0000)]
MFC r264022:
Get rid of ICL lock; use upper-layer (initiator or target) lock instead.
This avoids extra locking in icl_pdu_queue(); the upper layer needs to call
it while holding its own lock anyway, to avoid sending PDUs out of order.
trasz [Wed, 7 May 2014 06:24:46 +0000 (06:24 +0000)]
MFC r263979:
Hide CTL messages about SCSI error responses. Too many users take
them for actual target errors. They can be enabled back by setting
kern.cam.ctl.verbose=1, or booting with bootverbose.
alc [Wed, 7 May 2014 00:32:49 +0000 (00:32 +0000)]
MFC r262338
When the kernel is running in a virtual machine, it cannot rely upon the
processor family to determine if the workaround for AMD Family 10h Erratum
383 should be enabled. To enable virtual machine migration among a
heterogeneous collection of physical machines, the hypervisor may have
been configured to report an older processor family with a reduced feature
set. Effectively, the reported processor family and its features are like
a "least common denominator" for the collection of machines.
Therefore, when the kernel is running in a virtual machine, instead of
relying upon the processor family, we now test for features that prove
that the underlying processor is not affected by the erratum. (The
features that we test for are unlikely to ever be emulated in software
on an affected physical processor.)
projects / FreeBSD / stable / 10.git / log