gjb [Wed, 23 Nov 2011 12:24:29 +0000 (12:24 +0000)]
MFC r227769, 227770, 227771:
- Add a note to src/Makefile that explains that 'rm' runs twice because
thesecond invocation only needs to operate on files with the immutable
flag set.
- Fix the note in r227769 to be less specific to the immutable flag.
- Replace 'chflags' with 'file flags' in a comment, since 'chflags'is a
command, not a flag itself.
marius [Sat, 19 Nov 2011 13:29:55 +0000 (13:29 +0000)]
MFC: r227539
Define curthread as an inline function that loads the thread pointer
directly from g7, the pcpu pointer. This guarantees correct behavior
when the thread migrates to a different CPU.
Commit message stolen from r205431. Additional testing by Peter Jeremy.
marius [Sat, 19 Nov 2011 13:03:14 +0000 (13:03 +0000)]
MFC: r227537
As it turns out, r186347 actually is insufficient to avoid the use of the
curthread-accessing part of mtx_{,un}lock(9) when using a r210623-style
curthread implementation on sparc64, crashing the kernel in its early
cycles as PCPU isn't set up, yet (and can't be set up as OFW is one of the
things we need for that, which leads to a chicken-and-egg problem). What
happens is that due to the fact that the idea of r210623 actually is to
allow the compiler to cache invocations of curthread, it factors out
obtaining curthread needed for both mtx_lock(9) and mtx_unlock(9) to
before the branch based on kobj_mutex_inited when compiling the kernel
without the debugging options. So change kobj_class_compile_static(9)
to just never acquire kobj_mtx, effectively restricting it to its
documented use, and add a kobj_init_static(9) for initializing objects
using a class compiled with the former and that also avoids using mutex(9)
(and malloc(9)). Also assert in both of these functions that they are
used in their intended way only.
While at it, inline kobj_register_method() and kobj_unregister_method()
as there wasn't much point for factoring them out in the first place
and so that a reader of the code has to figure out the locking for
fewer functions missing a KOBJ_ASSERT.
Tested on powerpc{,64} by andreast.
dougb [Fri, 18 Nov 2011 21:04:59 +0000 (21:04 +0000)]
MFC r213077:
Simplify how we find the kernel source.
MFC r222218:
expr -> sh arithmetic expansion
MFC r226863:
Fix svnversion for svn 1.7.x by not looking for .svn in ${SYSDIR}
(since it no longer exists). Instead, run svnversion if we can find
the binary and test that the output looks like a version string.
rmacklem [Thu, 17 Nov 2011 01:02:45 +0000 (01:02 +0000)]
MFC: r227059
Both a crash reported on freebsd-current on Oct. 18 under the
subject heading "mtx_lock() of destroyed mutex on NFS" and
PR# 156168 appear to be caused by clnt_dg_destroy() closing
down the socket prematurely. When to close down the socket
is controlled by a reference count (cs_refs), but clnt_dg_create()
checks for sb_upcall being non-NULL to decide if a new socket
is needed. I believe the crashes were caused by the following race:
clnt_dg_destroy() finds cs_refs == 0 and decides to delete socket
clnt_dg_destroy() then loses race with clnt_dg_create() for
acquisition of the SOCKBUF_LOCK()
clnt_dg_create() finds sb_upcall != NULL and increments cs_refs to 1
clnt_dg_destroy() then acquires SOCKBUF_LOCK(), sets sb_upcall to
NULL and destroys socket
This patch fixes the above race by changing clnt_dg_destroy() so
that it acquires SOCKBUF_LOCK() before testing cs_refs.
dougb [Thu, 17 Nov 2011 00:36:10 +0000 (00:36 +0000)]
Upgrade to BIND 9.6-ESV-R5-P1 to address the following DDOS bug:
Recursive name servers are failing with an assertion:
INSIST(! dns_rdataset_isassociated(sigrdataset))
At this time it is not thought that authoritative-only servers
are affected, but information about this bug is evolving rapidly.
Because it may be possible to trigger this bug even on networks
that do not allow untrusted users to access the recursive name
servers (perhaps via specially crafted e-mail messages, and/or
malicious web sites) it is recommended that ALL operators of
recursive name servers upgrade immediately.
For more information see:
https://www.isc.org/software/bind/advisories/cve-2011-tbd
which will be updated as more information becomes available.
jhb [Wed, 16 Nov 2011 18:33:17 +0000 (18:33 +0000)]
MFC 220791,220793,220846,221836,226364:
Add the posix_fallocate(2) syscall. The default implementation in
vop_stdallocate() is filesystem agnostic and will run as slow as a
read/write loop in userspace; however, it serves to correctly
implement the functionality for filesystems that do not implement a
VOP_ALLOCATE.
Allow VOP_ALLOCATE to be iterative, and have kern_posix_fallocate(9)
drive looping and potentially yielding.
jhb [Wed, 16 Nov 2011 17:48:05 +0000 (17:48 +0000)]
Partially MFC 218195, 218424, and 221829:
- Put the general logic for being a CPU hog into a new function
should_yield().
- Encapsulate the common case of check-and-yield into a new function
maybe_yield().
- Add kern_yield() as a more generic version of uio_yield() and reimplement
uio_yield() in terms of kern_yield().
To preserve the ABI of struct thread, should_yield() in 8 continues to
use PCPU_GET(switchticks) rather than the td_swvolticks added in 9. Also,
existing users of uio_yield() are left unchanged. Instead, the routines
are merely added for use by new code.
ae [Wed, 16 Nov 2011 16:42:23 +0000 (16:42 +0000)]
MFC r227272:
Add reference to gpart(8).
MFC r227292:
Improve error reporting when MBR can not be written.
Remove obsolete code which uses DIOCSMBR ioctl.
When writing MBR first check that GEOM_MBR is available, if it is not
available, then try write MBR directly to provider. If both are failed,
then recommend to use gpart(8).
ae [Wed, 16 Nov 2011 16:24:36 +0000 (16:24 +0000)]
MFC r227231:
To be in sync with GEOM_PART_BSD limit the maximum number of supported
partitions to 20.
MFC r227248:
bsdlabel(8) could automatically fill many of disklabel's deprecated
fields, but user could specify some of those fields when edits disklabel
with `bsdlabel -e`. But without -A flag these fields might be
overwritten with default values from the virgin disklabel.
So, don't overwrite such fields if they are not zero. Also add checks
to prevent creating disklabel with less than DEFPARTITIONS and more
than MAXPARTITIONS partitions.
PR: bin/162332
Tested by: Eugene Grosbein
MFC r227262:
Remove unneeded checks.
MFC r227270:
Add recommendation to use gpart(8) when user tries write disklabel
or bootcode to already opened provider.
fabient [Wed, 16 Nov 2011 15:25:12 +0000 (15:25 +0000)]
MFC r226514,r226526,r226986:
Add a flush of the current PMC log buffer before displaying the next top.
As the underlying block is 4KB if the PMC throughput is low the measurement
will be reported on the next tick. pmcstat(8) use the modified flush API to
reclaim current buffer before displaying next top.
rstone [Fri, 11 Nov 2011 02:15:44 +0000 (02:15 +0000)]
MFC 224156:
Fix a LOR between hwpmc and the kernel linker. When a system-wide
sampling mode PMC is allocated, hwpmc calls linker_hwpmc_list_objects()
while already holding an exclusive lock on pmc-sx lock. list_objects()
tries to acquire an exclusive lock on the kld_sx lock. When a KLD module
is loaded or unloaded successfully, kern_kld(un)load calls into the pmc
hook while already holding an exclusive lock on the kld_sx lock. Calling
the pmc hook requires acquiring a shared lock on the pmc-sx lock.
Fix this by only acquiring a shared lock on the kld_sx lock in
linker_hwpmc_list_objects(), and also downgrading to a shared lock on the
kld_sx lock in kern_kld(un)load before calling into the pmc hook. In
kern_kldload this required moving some modifications of the linker_file_t
to happen before calling into the pmc hook.
This fixes the deadlock by ensuring that the hwpmc -> list_objects() case
is always able to proceed. Without this patch, I was able to deadlock a
multicore system within minutes by constantly loading and unloading an KLD
module while I simultaneously started a sampling mode PMC in a loop.
rstone [Fri, 11 Nov 2011 02:13:35 +0000 (02:13 +0000)]
MFC 221081:
If the 4BSD scheduler tries to schedule a thread that has been pinned or
bound to an AP before SMP has started, the system will panic when we try
to touch per-CPU state for that AP because that state has not been
initialized yet. Fix this in the same way as ULE: place all threads in
the global run queue before SMP has started.
rstone [Fri, 11 Nov 2011 02:10:24 +0000 (02:10 +0000)]
MFC 220888
r179417 introduced a bug into pthread_once(). Previously pthread_once()
used a global pthread_mutex_t for synchronization. r179417 replaced that
with an implementation that directly used atomic instructions and thr_*
syscalls to synchronize callers to pthread_once. However, calling
pthread_mutex_lock on the global mutex implicitly ensured that
_thr_check_init() had been called but with r179417 this was no longer
guaranteed. This meant that if you were unlucky enough to have your first
call into libthr be a call to pthread_once(), you would segfault when
trying to access the pointer returned by _get_curthread().
The fix is to explicitly call _thr_check_init() from pthread_once().
rstone [Fri, 11 Nov 2011 02:02:55 +0000 (02:02 +0000)]
MFC 220227:
GNU awk does not output escaped newlines in multi-line printc statements.
This leads to compile errors when trying to compile firmware(9) stubs
created with gawk, as multiple #include statements end up on the same
line. Replace the multi-line printc statement that outputs all of the
#includes with one printc per #include. This allows modules compatible
with firmware(9) to be cross-built from a Linux machine without requiring
the one true awk to be installed.
I've intentionally done the minimal set of changes necessary to make gawk
produce valid (but not pretty) C code, to reduce the churn and keep
fw_stubs.awk as readable as possible.
rstone [Fri, 11 Nov 2011 01:37:48 +0000 (01:37 +0000)]
MFC 215507:
When doing a camcontrol rescan all or a camcontrol reset all, use the wildcard
path id for enumerating the available busses. Previously camcontrol was
implicitly passing 0 as the first path id, which meant that if bus 0 was not
present camcontrol would fail with EINVAL instead of rescanning/resetting any
busses that were present.
marius [Mon, 7 Nov 2011 13:45:18 +0000 (13:45 +0000)]
MFC: r227006, r227281, r227282
Add a PCI front-end to esp(4) allowing it to support AMD Am53C974 and
replace amd(4) with the former in the amd64, i386 and pc98 GENERIC kernel
configuration files. Besides duplicating functionality, amd(4), which
previously also supported the AMD Am53C974, unlike esp(4) is no longer
maintained and has accumulated enough bit rot over time to always cause
a panic during boot as long as at least one target is attached to it
(see PR 124667).
marius [Mon, 7 Nov 2011 13:17:40 +0000 (13:17 +0000)]
MFC: r226947, r226949, r227284
- Use device_t rather than the NetBSDish struct device.
- Move esp_devclass to ncr53c9x.c in order to allow different bus front-ends
to use it.
- Use KOBJMETHOD_END.
- Remove the gl_clear_latched_intr hook as it's not needed for any of the
chips nor the front-ends supported in FreeBSD and likely never will be.
- Correct the DMA constraints and only limit the tag used for the transfer
buffers to 32-bit DMA as that address is written into a 32-bit register.
- The ESP200 also only supports up to 64k transfers.
- Don't let the DMA and SBus front-end supply a maximum transfer size larger
than MAXPHYS as that's the maximum the upper layers use and we otherwise
just waste resources unnecessarily.
- Initialize the ECB callout and don't zero the handle when returning ECBs
to the free list so that ncr53c9x_callout() actually is called with the
driver lock held.
- On detach the driver lock should be held across cam_sim_free() according
to isp(4) and a panic received.
- Check the return value of NCRDMA_SETUP(), i.e. bus_dmamap_load(9), and try
to handle failures gracefully.
- In ncr53c9x_action() replace N calls to xpt_done() in a switch with just
one at the end.
- On XPT_PATH_INQ report "NCR" rather than "Sun" as the vendor as the former
is somewhat more correct as well as the maximum supported transfer size via
maxio in order to take advantage of controllers that that can handle more
than DFLTPHYS.
- Freeze the device queue if a request didn't complete without error and
isn't already frozen.
- Print the number of MESSAGE (EXTENDED) rejected.
- Fix the path encoded in the multiple inclusion protection of ncr53c9xvar.h.
- Correct the DMA constraints used in the LSI64854 core to not exceed the
maximum supported transfer size and include the boundary so we don't need
to check on every setup of a DMA transfer.
- Let the bus DMA map callbacks do nothing in case of an error.
- Correctly handle > 64k transfers for FAS366 in the LSI64854. A new feature
flag NCR_F_LARGEXFER was introduced so we just need to check for this one
and not for individual controllers supporting large transfers in several
places.
- Let the LSI64854 core load transfer buffers using BUS_DMA_NOWAIT as the
NCR53C9x core can't handle EINPROGRESS. Due to lack of bounce buffers
support, sparc64 doesn't actually use EINPROGRESS and likely never will,
as an example for writing additional front-ends for the NCR53C9x core it
makes sense to set BUS_DMA_NOWAIT anyway though.
- Some minor cleanup.
marius [Mon, 7 Nov 2011 11:31:14 +0000 (11:31 +0000)]
Automatically compile in mii_bitbang.c if one of the drivers depending on
it since r227278 is compiled into the kernel. This restores POLA for people
that don't use "options miibus" but "options mii" and individual PHY drivers
instead.
This is a direct commit to stable/8.
marius [Sun, 6 Nov 2011 21:09:23 +0000 (21:09 +0000)]
MFC: r226995, r227042
- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.
Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).
Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
marius [Sun, 6 Nov 2011 19:57:14 +0000 (19:57 +0000)]
MFC: r227001
Increase the IOC port initialization timeouts by ten times to what the
corresponding Linux driver uses. This allows mpt(4) to still recognize
all good SATA devices in presence of a defective one, which takes about
45 seconds.
In the long term we probably should implement the logic used by mpt2sas(4)
allowing IOC port initialization to complete at a later time.
mav [Sun, 6 Nov 2011 16:58:17 +0000 (16:58 +0000)]
MFC r226985:
Workaround the problem introduced by combination of r162200 and r215687.
r162200 delays provider orphanization until all running requests complete,
to workaround broken orphan() method implementation in some classes.
r215687 removes persistent periodic (10Hz) event thread wake ups.
Together these changes can indefinitely delay orphanization until some
other event wake up the event thread. One consequence of this is inability
of CAM to destroy device disconnected when busy and, as consequence, create
new one after reconnection.
While the best solution would be to revert r162200, it is not easy, as
some classes still broken in that way. Instead conditionally wake up event
thread if there are some providers waiting for orphanization.
dougb [Sun, 6 Nov 2011 07:59:34 +0000 (07:59 +0000)]
MFC r227013:
1. Add a new option, --run-updates, to always or never run the newalises,
pwd_mkdb, etc. updates at the end of the comparison.
2. Add an update to the end to handle /etc/localtime, if it exists.
If /var/db/zoneinfo exists, automatically update /etc/localtime,
which should (hopefully) be safe to do. If not, prompt the user
to run tzsetup.
3. Update run_it_now(), the function that handles input for the updates,
to make sure that we got a valid answer, and to handle the --run-updates
option if supplied.
dougb [Sun, 6 Nov 2011 07:43:57 +0000 (07:43 +0000)]
MFC 227011:
If the user is moving from any other time zone to UTC we need
to delete any old /var/db/zoneinfo file that may exist so that
tzsetup -r does the right thing.
dougb [Sun, 6 Nov 2011 07:07:02 +0000 (07:07 +0000)]
MFC r226898:
Fix the text and attribution of the poem "Youth" by Samuel Ullman.
Our copy was a bastardization of the "older" (probably original?) and
shorter version of the poem; and the "newer" version that is better
known, and arguably more popular. Standardize on the latter.
sbruno [Fri, 4 Nov 2011 15:57:38 +0000 (15:57 +0000)]
MFC r224536:
Confirmed behavior of a Cisco 6509 in production.
In the old TFTP server, there was an undocumented behavior where
the block counter would rollover to 0 if a file larger
than 65535 blocks was transferred. With the default block size
of 512 octets per block, this is a file size of approximately 32 megabytes.
The new TFTP server code would report an error and stop transferring
the file if a file was larger than 65535 blocks.
This patch restores the old TFTP server's behavior to the new
TFTP server code. If a TFTP client transfers a file larger
than 65535 blocks, and does *not* specify the "rollover" option,
then automatically rollover the block counter to 0 every time
we reach 65535 blocks.
This restores interoperability with the FreeBSD 6 TFTP client.
Without this change, if a FreeBSD 6 TFTP client tried to
retrieve a file larger than 65535 blocks from a FreeBSD 9 TFTP server,
the transfer would fail. The same file could be retrieved successfully
if the same FreeBSD 6 TFTP client was used against a FreeBSD 6 TFTP server.
qingli [Tue, 1 Nov 2011 19:29:03 +0000 (19:29 +0000)]
MFC 226710
The host-id/interface-id can have a specific value and is properly
masked out when adding a prefix route through the "route" command.
However, when deleting the route, simply changing the command keyword
from "add" to "delete" does not work. The failoure is observed in
both IPv4 and IPv6 route insertion. The patch makes the route command
behavior consistent between the "add" and the "delete" operation.
kib [Tue, 1 Nov 2011 15:56:15 +0000 (15:56 +0000)]
MFC r226688:
The use of VOP_ISLOCKED() without a check for the return values can cause
false positives. Replace the #ifdef block with the proper
ASSERT_VOP_UNLOCKED() assert.
kib [Tue, 1 Nov 2011 15:53:44 +0000 (15:53 +0000)]
MFC r226687:
The only possible error return from null_nodeget() is due to insmntque1
failure (the getnewvnode cannot return an error). In this case, the
null_insmntque_dtr() already unlocked the reclaimed vnode, so VOP_UNLOCK()
in the nullfs_mount() after null_nodeget() failure is wrong.
kib [Tue, 1 Nov 2011 15:51:09 +0000 (15:51 +0000)]
MFC r226686:
The covered vnode must be reloced if it was unlocked. Remove VOP_ISLOCKED
test because of this and also because it can lead to false positives.
mm [Sun, 30 Oct 2011 21:02:01 +0000 (21:02 +0000)]
MFC r226724, r226732:
MFC r226724:
Update copyright information in several ZFS files, as the clause 3.3
of the CDDL licence explicitly requires every Contributor to add
a copyright notice.
This also reflects the copyright notices for the changes recently
added by Illumos.
MFC r226732: [1]
Fix typo in copyright notice introduced in r226724
(missing character in e-mail adress)
rmacklem [Sun, 30 Oct 2011 02:36:49 +0000 (02:36 +0000)]
MFC: r225537
Modify vfs_register() to use a hash calculation
on vfc_name to set vfc_typenum, so that vfc_typenum doesn't
change when file systems are loaded in different orders. This
keeps NFS file handles from changing, for file systems that
use vfc_typenum in their fsid. This change is controlled via
a loader.conf variable called vfs.typenumhash, since vfc_typenum
will change once when this is enabled. It defaults to 1 for
9.0, but will default to 0 when MFC'd to stable/8.
marius [Sun, 30 Oct 2011 01:24:53 +0000 (01:24 +0000)]
MFC: r199560
- Hook into the existing stat timer to drive the transmit watchdog instead
of using if_watchdog and if_timer.
- Reorder detach to call ether_ifdetach() before anything else in tl(4)
and wb(4).
marius [Sun, 30 Oct 2011 01:13:47 +0000 (01:13 +0000)]
MFC: r199559
- Add a private timer to drive the transmit watchdog instead of using
if_watchdog and if_timer.
- Fix some issues in detach for sn(4), ste(4), and ti(4). Primarily this
means calling ether_ifdetach() before anything else.
qingli [Fri, 28 Oct 2011 04:04:21 +0000 (04:04 +0000)]
MFC 226451
The IPv6 code was influx at the time of r196865 due to the L2/L3
separation rewrite changes. r196865 was committed to fix a scope
violation problem in the following test scenario:
qingli [Fri, 28 Oct 2011 03:58:33 +0000 (03:58 +0000)]
MFC 226713
Exclude host routes when checking for prefix coverage on multiple
interfaces. A host route has a NULL mask so check for that condition.
I have also been told by developers who customize the packet output
path with direct manipulation of the route entry (or the outgoing
interface to be specific). This patch checks for the route mask
explicitly to make sure custom code will not panic.
edwin [Tue, 25 Oct 2011 21:58:29 +0000 (21:58 +0000)]
MFC of 226752, tzdata2011m
Europe:
- Pridnestrovian Moldavian Republic (PMR, also known as
"Pridnestrovie") has abolished seasonal clock change (no transition
to the Winter Time).
- The recent change to the Ukranian time zone (Europe/Kiev) to
introduce permanent daylight saving time (similar to Russia) was
reverted.
South America:
- Bahia: The President signed a decree that includes Bahia in summer
time.
adrian [Sat, 22 Oct 2011 01:29:35 +0000 (01:29 +0000)]
Merge r226465 (below message) and r226467 (subsequent compile fixes).
Fix an issue with 11g beacon frames which looks to be a limitation
on the largest multi-write size.
From the submitter:
==
I looked further into the magic 88-byte threshold after which the bug
occurs. It turns out that figure included the 24-byte tx_desc, and up
to 64 bytes of beacon frame (header+data).
rum_write_multi doesn't seem happy with writing >64 bytes at a time to
the MAC register. If I break it up into separate calls (e.g. bytes
0-63, then bytes 64-65, written at the appropriate offset) I see the
proper beacon frames being transmitted now.
==
Submitted by: Steven Chamberlain <steven@pyro.eu.org>
trociny [Fri, 21 Oct 2011 05:40:30 +0000 (05:40 +0000)]
MFC r226403:
In r225809 the intention was to send VEOF only once if STDIN was not a
terminal. Unfortunately the fix was incorrect and for flushtime > 0 it
keept sending VEOF.
Sent VEOF generates ^D\b\b echoed by the terminal, which was reported
in bin/161526. Note, we still send VEOF at least once. Otherwise
commands like below would hang forever:
echo 1 |script /tmp/script.out cat
PR: bin/161526
Reported by: Adrian Wontroba <aw1@stade.co.uk>, Stefan Bethke <stb@lassitu.de>
Tested by: Stefan Bethke <stb@lassitu.de>
delphij [Thu, 20 Oct 2011 21:48:09 +0000 (21:48 +0000)]
MFC r226483:
Fix a bug in sa_find_sizes() which could lead to panic:
When calculating space needed for SA_BONUS buffers,
hdrsize is always rounded up to next 8-aligned boundary.
However, in two places the round up was done against
sum of 'total' plus hdrsize. On the other hand,
hdrsize increments by 4 each time, which means in
certain conditions, we would end up returning with
will_spill == 0 and (total + hdrsize) larger than
full_space, leading to a failed assertion because
it's invalid for dmu_set_bonus.
qingli [Tue, 18 Oct 2011 01:56:43 +0000 (01:56 +0000)]
MFC 226453
The code change made in r226040 was incomplete and resulted in
routes such as fe80::1%lo0 no being installed. This patch completes
the original intended fix.
projects / FreeBSD / stable / 8.git / log