Fix a resource allocation bug (explained by jhb on -acpi)
Thanks for Mike Tancsa for testing and helping track down the bug.
Approved by: re (kensmith)
MFC after: 3 weeks
detailed status on each of the backing subdisks. This allows userland
to see which subdisks are online, failed, missing, or a hot spare.
MFC after: 1 week
Approved by: re (bmah)
Reviewed by: sos
in *all* less_is_more cases, On the other hand, quit_if_one_screen
should apply iff less_is_more *and* -e.
This change revises the previous change further, which tried
to make less(1) not to send @ti:@te before and after view of
one file in more(1) mode, but affected less -e behavior by
accident.
This is essentially the same patch desichen@ has posted on
-current@. I have adjusted it a bit in order to minimize
difference between our version and the vendor branch.
Approved by: re (bmah, earlier logically equivalent version)
message and then dumps core because the subsequent code assumes that
mmap() succeeded. Since rpc.statd does not have fallback code to
implement the functionality needed to operate on the status file if
it is not memory mapped, rpc.statd should use err() to force the process
to exit if the mmap() call fails.
PR: bin/115430 (mmap() failure previously fixed in statd.c 1.15)
Approved by: re (kensmith)
MFC after: 1 week
differ in their details with calls to a new function, ehci_hcreset(),
that performs the reset.
The original sequences either had no delay or a 1ms delay between
telling the controller to stop and asserting the controller reset
bit. One instance of the original reset sequence waited for the
controller to indicate that its reset was complete before continuing,
but the other two immediately let the subsequent code execute. The
latter is a problem on some hardware, because a read of the HCCPARAMS
register returns an incorrect value while the reset is in progress,
which triggers an infinite loop in ehci_pci_givecontroller(), which
hangs the system on shutdown.
The reset sequence in ehci_hcreset() starts with the most complete
instance from the original code, which contains a loop to wait for
the controller to indicate that its reset is complete. This appears
to be the correct thing to do according to "Enhanced Host Controller
Interface Specification for Universal Serial Bus" revision 1.0,
section 2.3.1. Add another loop to wait for the controller to
indicate that it has stopped before setting the HCRESET bit. This
is required by the section 2.3.1 in the specification, which says
that setting HCRESET before the controller has halted "will result
in undefined behaviour".
Reviewed by: imp (previous patch version without the extra wait loop)
Tested by: se (previous patch version without the extra wait loop)
Approved by: re (bmah)
MFC after: 1 week
owner restore is not requested. If you ask
for permissions to be restored but not owner,
you will now get no error if suid/sgid bits
cannot be set. (It's a security hole to restore
suid/sgid bits if the owner/group aren't restored.)
This fixes an obscure problem where a simple
"tar -xf" with no other options will sometimes
fail gratuitously because of suid/sgid bits.
This is causing occasional problems for people
using bsdtar as a drop-in replacement for
"that other tar program." ;-)
Note: If you do ask for owner restore, then suid/sgid
restore failures still issue an error. This
only suppresses the error in the case where an
suid/sgid bit restore fails because of an owner
mismatch and owner restore was not requested.
Approved by: re (bmah)
MFC after: 7 days
In particular:
* Include a second entry in all of the test archives (to catch errors
with intermediate padding)
* Test the GNU tar 1.17 version of "posix sparse format 1.0"
instead of the GNU tar 1.16 version (the latter is no longer
supported by GNU tar).
Right now, libarchive fails this test because I originally
implemented the GNU tar 1.16 version of "posix sparse format 1.0".
I'll fix libarchive shortly.
Approved by: re (blanket, libarchive testing)
o Revamp the PIC I/F to only abstract the PIC hardware. The
resource handling has been moved to nexus, where it belongs.
o Include EOI and MASK+EOI methods to the PIC I/F in support of
INTR_FILTER.
o With the allocation of interrupt resources and setup of
interrupt handlers in the common platform code we can delay
talking to the PIC hardware after enumeration of all devices.
Introduce a call to powerpc_intr_enable() in configure_final()
to achieve that and have powerpc_setup_intr() only program the
PIC when !cold.
o As a consequence of the above, remove all early_attach() glue
from the OpenPIC and Heathrow PIC drivers and have them
register themselves when they're found during enumeration.
o Decouple the interrupt vector from the interrupt request line.
Allocate vectors increasingly so that they can be used for
the intrcnt index as well. Extend the Heathrow PIC driver to
translate between IRQ and vector. The OpenPIC driver already
has the support for vectors in hardware.
Approved by: re (blanket)
- LK_RETRY prohibits vget() and vn_lock() to return error.
Remove associated code. [1]
- Properly use vhold() and vdrop() instead of their unlocked
versions, we are guaranteed to have the vnode's interlock
unheld. [1]
- Fix a pseudo-infinite loop caused by 64/32-bit arithmetic
with the same way used in modern NetBSD versions. [2]
- Reorganize tmpfs_readdir to reduce duplicated code.
Submitted by: kib [1]
Obtained from: NetBSD [2]
Approved by: re (tmpfs blanket)
read-only, so we can't simply exit right after calling gjournal_check(),
instead we need to ask about super block reload.
Submitted by: Niki Denev <niki@totalterror.net>
PR: misc/113889
Approved by: re (kensmith)
- Respect cnflag and don't lock vnode always as LK_EXCLUSIVE [1]
- Properly lock around tn_vnode to avoid NULL deference
- Be more careful handling vnodes (*)
(*) This is a WIP
[1] by pjd via howardsu
Thanks kib@ for his valuable VFS related comments.
Tested with: fsx, fstest, tmpfs regression test set
Found by: pho's stress2 suite
Approved by: re (tmpfs blanket)
cr0-4, etc. Support should be added for other platforms that have a
different set of registers for system use.
Loosely based on: OpenBSD
Approved by: re
a test that assumes that char is signed by default and causes a
warning with GCC 4.2 on PowerPC.
A patch has been sent to the maintainer that addresses this.
Approved by: re (blanket)
object to control the value of the new 'PRIVATE' bridge members' flag.
While here, remove stale '__unused' compiler directives.
Reviewed by: bz
Approved by: re (bmah), bz (mentor)
patching and for rolling back updates, don't copy a file if it has already
been stored. This provides a significant speedup to the "Preparing to
download files" stage of "freebsd-update fetch" if many updates have already
been applied or if a file being updated is linked many times (such as
/rescue/*).
Reported by: Paul Dekkers
MFC after: 1 week
Approved by: re (bmah)
of device pager in the pagers list by handle is now synchronized with
its removal from the list, and dev_pager_mtx is put before vm object
lock in lock order. Dispose the dev_pager_sx lock, since dev_pager_mtx
now covers the same block.
Noted by: kensmith
Reviewed by: alc
Approved by: re (kensmith)
(uio_offset < 0) since this can't happen. If this happens, then the
general code handles the problem safely (better than before for reading,
returning 0 (EOF) instead of the bogus errno EINVAL, and the same as
before for writing, returning EFBIG).
In msdosfs_read(), don't check for (uio_resid < 0). msdosfs_write()
already didn't check.
In msdosfs_read(), document in a comment our assumptions that the caller
passed a valid uio_offset and uio_resid. ffs checks using KASSERT(),
and that is enough sanity checking. In the same comment, partly document
there is no need to check for the EOVERFLOW case, unlike in ffs where this
case can happen at least in theory.
In msdosfs_write(), add a comment about why the checking of
(uio_resid == 0) is explicit, unlike in ffs.
In msdosfs_write(), check for impossibly large final offsets before
checking if the file size rlimit would be exceeded, so that we don't
have an overflow bug in the rlimit check and are consistent with ffs.
We now return EFBIG instead of EFBIG plus a SIGXFSZ signal if the final
offset would be impossibly large but not so large as to cause overflow.
Overflow normally gave the benign behaviour of no signal.
Approved by: re (kensmith) (blanket)
remove some parentheses; fix some whitespace errors; fix only one case of
a boolean comparison of a non-boolean).
Improve an error message by quoting ".", and by not printing large positive
values as negative ones.
Approved by: re (kensmith) (blanket)
