- Don't claim that the mutex is atomically reacquired when a cv_wait
routine returns. There's nothing atomic or magical about the lock
reacquire. The only magic is that we atomically drop the lock by
placing the thread on the sleep queue before dropping the lock.
- Markup sx_unlock() as a function rather than saying it is a macro.
The macro part is an implementation detail, and all the other sx_*lock()
functions are actually macros, too.
- Use the same style as rwlock(9) and mutex(9) to markup sx_assert() and
SX_SYSINIT() with respect to headers and kernel options.
- Add a missing MLINK.
These functions are intended to be used to drop a lock and then reacquire
it when doing an sleep such as msleep(9). Both functions accept a
'struct lock_object *' as their first parameter. The 'lc_unlock' function
returns an integer that is then passed as the second paramter to the
subsequent 'lc_lock' function. This can be used to communicate state.
For example, sx locks and rwlocks use this to indicate if the lock was
share/read locked vs exclusive/write locked.
Currently, spin mutexes and lockmgr locks do not provide working lc_lock
and lc_unlock functions.
caused fstat to produce duplicated output for threaded processes. Instead
use KERN_PROC_PROC to get just one kinfo_proc per process.
MFC After: 2 weeks
- first line is $FreeBSD$
- Reorder special variables: DPADD, LPADD, CFLAGS
- Use = instead of += for variables that are initially empty
- Use space instead of tab after :
- Use one tab after =
- Use .SUFFIXES for section 3 manual page which simplifies Makefile a lot
- Use SHAREDIR instead of /usr/share
- Remove SRCDIR in INCS since we set .PATH properly
- Use plural in variable name when it stands for more that one source file
Reviewed by: ru
Approved by: delphij (mentor)
excessive interrupt clock timer reset, screwing interrupt generation
for already active channels. Track moving DMA pointer and call buffer
interrupt on each blocksize boundary.
PR: kern/109791
MFC after: 3 days
GETATTRs being generated - one from lookup()/namei() and the other
from nfs_open() (for cto consistency). This change eliminates the
GETATTR in nfs_open() if an otw GETATTR was done from the namei()
path. Instead of extending the vop interface, we timestamp each attr
load, and use this to detect whether a GETATTR was done from namei()
for this syscall. Introduces a thread-local variable that counts the
syscalls made by the thread and uses <pid, tid, thread syscalls> as
the attrload timestamp. Thanks to jhb@ and peter@ for a discussion on
thread state that could be used as the timestamp with minimal overhead.
* To use this option with a UDP socket, it must be bound to a local port,
and INADDR_ANY, to disallow possible collisions with existing udp inpcbs
bound to the same port on other interfaces at send time.
* If the socket is bound to INADDR_ANY, specifying IP_SENDSRCADDR with
INADDR_ANY will be rejected as it is ambiguous.
* If the socket is bound to an address other than INADDR_ANY, specifying
IP_SENDSRCADDR with INADDR_ANY will be disallowed by in_pcbbind_setup().
Reviewed by: silence on -net
Tested with: src/tools/regression/netinet/ipbroadcast
MFC after: 4 days
After reading Makefile and all the files that are included using .include
or .sinclude directives (source Makefiles) make considers each source
Makefile as a target and tries to rebuild it. Both explicit and implicit
rules are checked and all source Makefiles are updated if necessary. If
any of the source Makefiles were rebuilt, make restarts from clean state.
To prevent infinite loops the following source Makefile targets are
ignored:
- :: targets that have no prerequisites but have commands
- ! targets
- targets that have .PHONY or .EXEC attributes
- targets without prerequisites and without commands
When remaking a source Makefile options -t (touch target), -q (query
mode), and -n (no exec) do not take effect, unless source Makefile is
specified explicitly as a target in make command line.
Additionally, system makefiles and .depend are not considered as a
Makefiles that can be rebuilt.
Reviewed by: harti
error return from open(2), leading to an erroneous value of maxJobs and
a hung make when -f is standard input and -j is used.
PR: bin/101232
Submitted by: Nate Eldredge <nge@cs.hmc.edu>
as crontab(5) states it can be. This is supported by all vixie-cron derived
implementations; not sure why FreeBSD was any different.
PR: bin/106442
MFC after: 2 weeks
a thread is an idle thread, just see if it has the IDLETD
flag set. That flag will probably move to the pflags word
as it's permenent and never chenges for the life of the
system so it doesn't need locking.
These tests verify that archive_entry objects can store and return
ACL data and that pax format archives can read and write ACL
information. These do not (yet) test that ACL data is read or
written to disk correctly. (And hence would not have caught the
recent snafu about ACL read-from-disk being turned off.)
ACL data from the archive entry. This doesn't impact
archive_read_extract or archive_write_disk since they only
check for != ARCHIVE_OK when calling this function. (Though
they should be more careful.)
as part of an old configuration shuffle. As a result, although
ACL restore has been working, ACLs haven't been written into archives
for some time. <sigh>
Pointy hat: You know.
MFC after: 3 days
- Remove some excessive parentheses around shift operators.
- Use macro instead of magic number where it is applicable.
- Change lower-case hexdecimals to upper cases to match wpaul's style.
- Revert some unnecessary line wraps and changes from the previous commit.
Pointed out by: bde
in the field. In one situation, one end of the TCP connection sends
a back-to-back RST packet, with delayed ack, the last_ack_sent variable
has not been update yet. When tcp_insecure_rst is turned off, the code
treats the RST as invalid because last_ack_sent instead of rcv_nxt is
compared against th_seq. Apparently there is some kind of firewall that
sits in between the two ends and that RST packet is the only RST
packet received. With short lived HTTP connections, the symptom is
a large accumulation of connections over a short period of time .
The +/-(1) factor is to take care of implementations out there that
generate RST packets with these types of sequence numbers. This
behavior has also been observed in live environments.
Reviewed by: silby, Mike Karels
MFC after: 1 week
