extensions. This seems to be unnecessary and prevents less(1) from being
able to detect file changes, so remove the part.
Submitted by: Eric Huss <e-huss netmeridian com>
PR: bin/102624
Discussed with: des
MFC After: 3 days
INVARIANT_SUPPORT is defined so you can build a kernel with
INVARIANT_SUPPORT, but build a module with just INVARIANTS on.
MFC after: 3 days
Reported by: kuriyama
the build. The openbsm folks are free to fix it in any other way they
see fit once they resurface.
Basically, make everything always be const char **, even though const
char ** usually should be 'const char * const *' in most cases. This
makes the three different definitions consistant and allows world to
build.
Add "-C <column>" and "-d <delims>" options to chop up input lines.
Make '#' a comment character, rest of line is ignored.
Submitted by: Dmitry Morozovsky <marck@rinet.ru>
ignoring errors when sourcing rc.conf* files. The most common error
occurs when users put a command of some sort into those files.
(ifconfig is a popular choice)
2. Make the file rotation logic simpler by starting one down from
the "top" of the list, rather than at the top.
3. Try to make file rotation more secure by calling unlink(1) on all
new file names before rotating an old file to the new name, rather than
merely calling 'rm -f' on any files that exceed the number of files
to save.
into pthread structure to keep track of locked PTHREAD_PRIO_PROTECT mutex,
no real mutex code is changed, the mutex locking and unlocking code should
has same performance as before.
mutex structure is added as following:
struct umutex {
__lwpid_t m_owner;
uint32_t m_flags;
uint32_t m_ceilings[2];
uint32_t m_spare[4];
};
The m_owner represents owner thread, it is a thread id, in non-contested
case, userland can simply use atomic_cmpset_int to lock the mutex, if the
mutex is contested, high order bit will be set, and userland should do locking
and unlocking via kernel syscall. Flag UMUTEX_PRIO_INHERIT represents
pthread's PTHREAD_PRIO_INHERIT mutex, which when contention happens, kernel
should do priority propagating. Flag UMUTEX_PRIO_PROTECT indicates it is
pthread's PTHREAD_PRIO_PROTECT mutex, userland should initialize m_owner
to contested state UMUTEX_CONTESTED, then atomic_cmpset_int will be failure
and kernel syscall should be invoked to do locking, this becauses
for such a mutex, kernel should always boost the thread's priority before
it can lock the mutex, m_ceilings is used by PTHREAD_PRIO_PROTECT mutex,
the first element is used to boost thread's priority when it locked the mutex,
second element is used when the mutex is unlocked, the PTHREAD_PRIO_PROTECT
mutex's link list is kept in userland, the m_ceiling[1] is managed by thread
library so kernel needn't allocate memory to keep the link list, when such
a mutex is unlocked, kernel reset m_owner to UMUTEX_CONTESTED.
Flag USYNC_PROCESS_SHARED indicate if the synchronization object is process
shared, if the flag is not set, it saves a vm_map_lookup() call.
The umtx chain is still used as a sleep queue, when a thread is blocked on
PTHREAD_PRIO_INHERIT mutex, a umtx_pi is allocated to support priority
propagating, it is dynamically allocated and reference count is used,
it is not optimized but works well in my tests, while the umtx chain has
its own locking protocol, the priority propagating protocol are all protected
by sched_lock because priority propagating function is called with sched_lock
held from scheduler.
No visible performance degradation is found which these changes. Some parameter
names in _umtx_op syscall are renamed.
inlined and a procedure call is made in the rare case, i.e., when it is
necessary to sleep. In this case, inlining the test actually makes the
kernel smaller.
other stuff) in the osrelease=2.6.16 case:
- implement CLONE_PARENT semantic
- fix TLS loading in clone CLONE_SETTLS
- lock proc in the currently disabled part of CLONE_THREAD
I suggest to not unload the linux module after testing this, there are
some "<defunct>" processes hanging around after exiting (they aren't
with osrelease=2.4.2) and they may panic your kernel when unloading the
linux module. They are in state Z and some of them consume CPU according
to ps. But I don't trust the CPU part, the idle threads gets too much CPU
that this may be possible (accumulating idle, X and 2 defunct processes
results in 104.7%, this looks to much to be a rounding error).
Noticed by: Intron <mag@intron.ac>
Submitted by: rdivacky (in collaboration with Intron)
Tested by: Intron, netchild
Reviewed by: jhb (previous version)
