machines which can clearly afford the memory.
This is a somewhat conservative version of the patch - more fine tuning may be
necessary.
Idea from: Thread on hackers@
Discussed with: alc
a separate inline function. This further reduces duplicate code that didn't
have a good reason to stay as it was.
- Reorder the malloc of a pkt_node struct in the hook functions such that it
only occurs if we managed to find a usable tcpcb associated with the packet.
- Make the inp_locally_locked variable's type consistent with the prototype of
siftr_siftdata().
Sponsored by: FreeBSD Foundation
systems with PnP/ACPI not reporting i8254 timer. In some cases it can be
fatal, as i8254 can be the only available time counter hardware. From other
side we are now heavily depend on i8254 timer and till the last time it's
init/usage was completely hardcoded. So this change just restores previous
behavior in more regular fashion.
count on nfsv4rootfs_lock when dumping state, since these functions
are not called by nfsd threads. Without this reference count, it
is possible for an nfsd thread to acquire an exclusive lock on
nfsv4rootfs_lock while the dump is in progress and then change the
lists, potentially causing a crash.
Reported by: zack.kirsch at isilon.com
MFC after: 2 weeks
implementation in 8.0 and later as its flags field does not hold dynamic
state such as waiters flags, but is only modified in lockinit() aside
from VN_LOCK_*().
Discussed with: attilio
changed to defer the setting of VN_LOCK_ASHARE() (which clears LK_NOSHARE
in the vnode lock's flags) until after they had determined if the vnode was
a FIFO. This occurs after the vnode has been inserted a VFS hash or some
similar table, so it is possible for another thread to find this vnode via
vget() on an i-node number and block on the vnode lock. If the lockmgr
interlock (vnode interlock for vnode locks) is not held when clearing the
LK_NOSHARE flag, then the lk_flags field can be clobbered. As a result
the thread blocked on the vnode lock may never get woken up. Fix this by
holding the vnode interlock while modifying the lock flags in this case.
MFC after: 3 days
filename issues when checking out the source on other operating systems.
I've verified the generated paper.ascii is identical before and after the
change.
AcpiOsMapMemory()/AcpiOsUnmapMemory() (-> pmap_mapbios()/pmap_unmapbios())
for AcpiOsReadMemory() and AcpiOsWriteMemory(). Although they do not sound
too obvious, these functions are exclusively used to access memory mapped
IO in ACPICA.
MACHINE_CPUARCH isn't defined. I believe that this will cover all
options.
I didn't define it in kern.mk because $M is set to MACHINE_CPUARCH and
then is expanded for the genassym.o rule in kern.post.mk and kern.mk
is included after this, so the expansion isn't quite right. I think
this is a bug in make, but don't have the time to track it to ground
(and even if I did, fixing it would require a MFC of the change to the
very old systems we're targetting with this fix).
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 64-bit return value even if the bit width of
the location is less than 64.
- Return error when 64-bit access is requested as we do not support 64-bit
PCI register access (yet). XXX We may have to split it up into two 32-bit
accesses if it is really required.
to avoid sending multiple ACCESS/GETATTR RPCs during a single open()
between VOP_LOOKUP() and VOP_OPEN(). Now we always send the RPC in
VOP_LOOKUP() and not VOP_OPEN() in the cases that multiple RPCs could be
sent.
MFC after: 2 weeks
Move attribute cache flushes from VOP_OPEN() to VOP_LOOKUP() to provide
more graceful recovery for stale filehandles and eliminate the need for
conditionally clearing the attribute cache in the !NMODIFIED case in
VOP_OPEN().
Reviewed by: rmacklem
MFC after: 2 weeks
Remove the internal jailparam_vlist, in favor of using variants of its
logic separately in jail_setv and jail_getv.
Free the temporary parameter list and exported values in jail_setv
and jail_getv.
Noted by: Stanislav Uzunchev
MFC after: 3 days
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 32-bit return value even if the bit width of
the port is less than 32.
- Remove 64-bit read/write from AcpiOsReadMemory() and AcpiOsWriteMemory().
These functions do not support 64-bit access (yet). Clean up style nits
and unnecessary bit masking while I am here.
Reported by: Liu, Jinsong (jinsong dot liu at intel dot com) via
Lin Ming (ming dot m dot lin at intel dot com) [1]
