These are defined in the latest POSIX
Also make related updates to documentation, mostly from FreeBSD,
though I cleaned a few other things up along the way.
Bump shlib_version.
We are still missing strcoll_l, strerror_l, strsignal, strxfrm_l to be
POSIX conformant.
ifa_data member of every AF_LINK struct ifaddrs points at the
corresponding struct if_data. In ifconfig(8), do not try to suppress
duplicate AF_LINK ifaddrs by checking for a NULL ifa_data.
Don't copy out two AF_LINK struct ifaddrs for each active link-layer
address. getifaddrs(3) used to copy out one ifaddrs for the kernel's
RTM_IFINFO message, and one more for the kernel's RTM_NEWADDR message.
I suppress the first duplicate with a highly conservative change that
wastes a little bit of ifaddrs storage. The storage is not leaked.
There was no room to allocate 16 bytes for _rnd in the struct in the _LP64
case, so we dynamically allocate now. Also put the _rnd field last, so that
we are bitwise compatible too. Now of course we've run out of space, so
next time will need to perform more evil tricks to fit.
Due to limitations in the current pthread implementation, makecontext(3)
and sigaltstack(2) should not be used in programs which link against
libpthread (whether threads are used or not).
Wording from drochner@ and ad@
Bump date for man pages.
Add note in libpthread/README so it's not forgotten to update the man
pages when the problem is fixed.
implementation:
-don't return a difference, this can overflow
-don't try to substract typed pointers which don't belong to the
same object, this gives undefined results
This fixes instabilities of programs which use more than a handful
of threads, eg spuriously failing pthread_join().
XXX This must not be enabled by default because the LWP private mechanism
is reserved for TLS. It is provided only as a test/demo.
XXX Since ucontext_t does not contain the thread private variable, for a
short time after threads are created their thread specific data is unset.
If a signal arrives during that time we are screwed.
- No longer need pthread__osrev.
- Rearrange _lwp_ctl() calls slightly.
address space available to processes. this limit exists in most other
modern unix variants, and like most of them, our defaults are unlimited.
remove the old mmap / rlimit.datasize hack.
- adds the VMCMD_STACK flag to all the stack-creation vmcmd callers.
it is currently unused, but was added a few years ago.
- add a pair of new process size values to kinfo_proc2{}. one is the
total size of the process memory map, and the other is the total size
adjusted for unused stack space (since most processes have a lot of
this...)
- patch sh, and csh to notice RLIMIT_AS. (in some cases, the alias
RLIMIT_VMEM was already present and used if availble.)
- patch ps, top and systat to notice the new k_vm_vsize member of
kinfo_proc2{}.
- update irix, svr4, svr4_32, linux and osf1 emulations to support
this information. (freebsd could be done, but that it's best left
as part of the full-update of compat/freebsd.)
this addresses PR 7897. it also gives correct memory usage values,
which have never been entirely correct (since mmap), and have been
very incorrect since jemalloc() was enabled.
tested on i386 and sparc64, build tested on several other platforms.
thanks to many folks for feedback and testing but most espcially
chuq and yamt for critical suggestions that lead to this patch not
having a special ugliness i wasn't happy with anyway :-)
piece of historical behavior, not a current bug. Also, while here, add a
bit about disk write-back caches and point to dkctl/scsictl.
Bump date. (first time since 1993!)
which apparently don't exist as instructions, with a sequence of
std / ld instructions.
Also remove the attempted include of ldstm.S which we don't have.
these files use __weak_alias causes build failures under OpenBSD,
because the OpenBSD __weak_alias macro expects the caller to supply a
semicolon, but the NetBSD __weak_alias macro supplies its own semicolon.
Attempt to fix this by avoiding the use of __weak_alias during a tools
build.
bytes.
This fixes the problem that enabling the titeInhibit Xresource of xterm has
no effect, because xterm exports a TERMCAP string without ti/te sequences
but doesn't remove the ZZ capability because it doesn't know about it and
termcap(3) ignores the stringe because of the ZZ.
Discussed with and OK'ed by blymn@.
Received from OpenBSD via US-CERT as VU #590371.
Original OpenBSD commit log:
> revision 1.42
> date: 2009/02/11 13:24:05; author: otto; state: Exp; lines: +9 -1
> Avoid level going negative on deep (i mean really deep) dirs. Reported
> by Maksymilian Arciemowicz. ok kettenis@ millert@
PR kern/16942 panic with softdep and quotas
PR kern/19565 panic: softdep_write_inodeblock: indirect pointer #1 mismatch
PR kern/26274 softdep panic: allocdirect_merge: ...
PR kern/26374 Long delay before non-root users can write to softdep partitions
PR kern/28621 1.6.x "vp != NULL" panic in ffs_softdep.c:4653 while unmounting a softdep (+quota) filesystem
PR kern/29513 FFS+Softdep panic with unfsck-able file-corruption
PR kern/31544 The ffs softdep code appears to fail to write dirty bits to disk
PR kern/31981 stopping scsi disk can cause panic (softdep)
PR kern/32116 kernel panic in softdep (assertion failure)
PR kern/32532 softdep_trackbufs deadlock
PR kern/37191 softdep: locking against myself
PR kern/40474 Kernel panic after remounting raid root with softdep
Retire softdep, pass 2. As discussed and later formally announced on the
mailing lists.
wiz