Unfortunately, the QUEUE FULL event only tells you Bus && Target.
It doesn't tell you lun. In order for the XPT_REL_SIMQ action to
work, we have to have a real lun. But which one? For now, just
iterate over MPT_MAX_LUNS.
Practically speaking, this is only going to be happening for lower
quality SAS or SATA drives behind the SAS controller, which means
only lun 0, so it's not so bad.
Helpful Reminder Nagging from: John Baldwin, Fred Whiteside
MFC after: 5 days
of directory reading system calls.
Respell a mis-spelled event name.
Clean up white space/line wraps in a couple of places.
Assign event numbers to some new system call entries that have turned
up in the list since audit support was added.
Obtained from: TrustedBSD Project
returns the previous value that the "add" effected (In
this case we are adding -1), afterwhich we compare it
to '0'... to see if we free the mbuf... we should
be comparing it to '1'... Note that this only effects
when there is contention since there is a first part
to the comparison that checks to see if its '1'. So
this bug would only crop up if two CPU's are trying
to free the same mbuf refcount at the same time. This
will happen in SCTP but I doubt can happen in TCP or
UDP.
PR: N/A
Submitted by: rrs
Reviewed by: gnn,sam
Approved by: gnn,sam
of the chip to let ASF/IPMI firmware to respond to IPMI after attaching
and when the chip is down. David looked at it but could really say
what they right minimal config. stuff would be. It's not documented.
I figured this out via trial and error.
Reviewed by: davidch
behaves. This fixes a lot of test which failed before. For amd64 there
are still some problems, but without any testers which apply patches
and run some predefines tests we can't do more ATM.
Submitted by: Marcin Cieslak <saper@SYSTEM.PL> (minor fixups by myself)
Tested with: LTP
appears to be serving a useful purpose, as it was used during initial
development of MAC support for System V IPC.
MFC after: 1 month
Obtained from: TrustedBSD Project
Suggested by: Christopher dot Vance at SPARTA dot com
other problems while labels were first being added to various kernel
objects. They have outlived their usefulness.
MFC after: 1 month
Suggested by: Christopher dot Vance at SPARTA dot com
Obtained from: TrustedBSD Project
when allocating the record in the first place, allocate the final buffer
when closing the BSM record. At that point, more size information is
available, so a sufficiently large buffer can be allocated.
This allows the kernel to generate audit records in excess of
MAXAUDITDATA bytes, but is consistent with Solaris's behavior. This only
comes up when auditing command line arguments, in which case we presume
the administrator really does want the data as they have specified the
policy flag to gather them.
Obtained from: TrustedBSD Project
MFC after: 3 days
is incorrect, and causes endianness bugs on 64-bit big-endian
machines (sparc64), it's the best choice for now, as many of
these IOCTLs are used inside the kernel, and bogusly pass an
argument as "int *" which results in unaligned access panics
on sparc64 when attempting to dereference them via *(intptr_t *).
(Several of us are working on a real fix, which is uneasy.)
switch by worklist type contains two for() loops, for D_INDIRDEP and
D_PAGEDEP. On error, these loops are exited by break, where the switch
actually shall be leaved. Use goto instead of break to reach the error
handling code.
Reported by: Peter Holm
Reviewed by: tegge
Approved by: pjd (mentor)
MFC after: 2 weeks
code is still under giant lock, but the session/pgrp release code just used
proctree_locks. This explains why moving the proctree_lock in sys/kern/tty.c
rev. 1.258 did fix the panics in our SMP systems.
This should also fix some race panics with revoked ttys.
Reviewed by: jhb
MFC after: 1 week
and drop_dm_lock is true, no unlocking shall be attempted. The lock is
already dropped and memory is freed.
Found with: Coverity Prevent(tm)
CID: 1536
Approved by: pjd (mentor)
