lock against themselves, causing infinite spinning. Brian Feldman
found this problem when testing with Mozilla and supplied the fix,
which I have revised slightly.
Here is the failure scenario. A thread calls dlopen() and acquires
the writer lock. While the thread still holds the lock, a signal
is delivered and caught. The signal handler tries to call a function
which hasn't been bound yet. It thus enters the dynamic linker
and tries to acquire the reader lock. Since the writer lock is
already held, it will spin forever in the signal handler. The
thread holding the lock won't be able to progress and release the
lock.
The solution is to block almost all signals while holding the
exclusive lock.
A similar problem could conceivably occur in the opposite order.
Namely, a thread is holding the reader lock and then a signal
handler calls dlopen() or dlclose() and spins waiting for the writer
lock. We deal with this administratively by proclaiming that signal
handlers aren't allowed to call dlopen() or dlclose(). Actually
we don't have to proclaim a thing, since signal handlers aren't
allowed to call any system functions except those which are explicitly
permitted.
Submitted by: Brian Fundakowski Feldman <green>
Linux kernel image, and is designed to be dropped into a Linux system
and booted via LILO. Once booted, the user is greeted by the FreeBSD
loader. This still isn't quite complete, as the the root= specification
from LILO isn't currently passed to the loader yet.
time, and this is used to reseed the random number generator at
boot time.
NOTE - this has no hope of working if you halt(); you need to
execute rc.shutdown to get the entropy stash.
entropy estimation, but causes an immediate reseed after the input
(read in sizeof(u_int64_t) chunks) is "harvested".
This will be used in the reboot "reseeder", coming in another
commit. This can be used very effectively at any time you think
your randomness is compromised; something like
# (ps -gauxwww; netstat -an; dmesg; vmstat -c10 1) > /dev/random
will give the attacker something to think about.
* Re-order the list of options in teh DESCRIPTION as per
the SYNOPSIS.
* Move the description of exit conditions from the
DESCRIPTION section to a new DIAGNOSTICS section.
* Typo fix: "effect" -> "affect" when used as a verb.
* Clear the Nm macro as appropriate.
* Typo fix: "consider" -> "considers" for a singular subject.
* Use Nx instead of NetBSD.
CAM_TAG_ACTION_VALID and CAM_DIR_MASK). Remove redundant
CAM_DEBUG line. Spiff up CAM_DEBUG printout for commands
and move the printout up to the top where we can see it,
even for the pending_ua/pending_ca cass. Add missing
newline in a CAM_DEBUG.
non-disconnecting command. Interestingly enough, of the other flavors
of the 7.65 f/w (the dual-id and multi-id flavor)- the dual-id doesn't
hang (they're also supposed to be the same except for supporting dual
or multi-id capture!), but other things are questionable as well.
PR: 19894
Submitted by: Tony Finch <dot@dotat.at>
2. "brackets" -> "angle brackets" when referring to < and >.
3. Clean up the bit about creating the usage() message. After clarifying a
couple of points the sentence became rather long, and rather poor English, so
it was converted to a enumerated list instead.
parts 1, 2, 3:
Reviewed by: sheldonh
- Remove unit numbers in config lines.
- Remove all of logger lines and add logstr lines for some cards. This
changes reduced file size from 84k to 45k.
- Use '/sbin/ifconfig $device delete' instead of /etc/pccard_ether_remove
which haven't merge from PAO yet.
- Cosmetic changes.
strlen.
This one only occurs if there is exactly one element on the line without any
whitespace. This is however never a valid line, so not a big chance that
this would ever cause any problems.
compatible with other *BSD camp. Add -L option to follow symlinks, so remove
-P option which is now default. The next step will be to add -L to building
process.
Asked-by: bde
over flowing its britches. So remove all ppbus bits except those for PLIP
(untested), and all USB bits as SRM does not know what USB is. Also remove
/dev/random as I don't think we need it just for whacking bits onto a disk.
Approved by: JKH
