using the somewhat more hackish variant on extattr_get_*() to retrieve
the attribute list on an object.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
'use entire disk'. Neither for ia64 while I'm here - it needs a MBR if
its going to use fdisk+disklabel. The ia64 case is mostly academic though
because you'd be creating two partitions (dos + freebsd) rather than
a single freebsd-only partition.
either COMMENT or DESCR from the command line. When a port is
installed, one gets both +COMMENT and +DESCR files with a trailing
'\n' character. However, +COMMENT does not contain a trailing '\n'
when it is installed from a package due to this behavior of pkg_create.
Therefore, make sure it behaves exactly the same regardless of
where got its information; either command line or files. The modified
functions are used by pkg_create.
PR: 52097
Reviewed by: bento, kris,
portmgr, re,
Michael Nottebrock <michaelnottebrock@gmx.net>,
Martin Horcicka <horcicka@FreeBSD.cz>
Approved by: re (scottl)
MFC after: 1 week
error) on amd64 when doing pointer subtraction. This bug is already
fixed in gcc-3.3 (waiting for after the branch), and the hack will be
backed out at the first opportunity. This is in the ipv6 code path.
Approved by: re (scottl)
server, map it to EAGAIN locally rather than EACCES. The NLM spec
indicates the DENIED corresponds to lock contention, not a permission
failure. This fixes O_EXLOCK/O_SHLOCK with O_NONBLOCK, which would
previously give a permission error, which in turn fixes things
like mailq(8) and lockf(1) over NFS.
Approved by: scottl (re)
Reviewed by: truckman, Andrew P Lentvorski, Jr. <bsder@allcaps.org>
Idea from: truckman
has requested the lock in a non-blocking form, instead returning an
immediate failure. This appears to help reduce one of my "locks get
lost" symptoms involving lockf(1), which attempts a non-blocking lock
attempt before actually blocking on the lock. At this point the client
still gets back EACCES, which is an issue we're still working.
Approved by: re (scottl)
Submitted by: Andrew P. Lentvorski, Jr. <bsder@allcaps.org>
from the NFS server, following contention on a lock by this or another
client, immediately notify the waiting process that the lock has been
granted via a wakeup. Without this change, the client rpc.lockd will
not wakeup the waiting process until it next re-polls the lock (sometime
in the next ten seconds), which can lead to marked latency across all
potential lockers, as the lock is held by the client for the duration.
Approved by: re (scottl)
Submitted by: truckman
Reviewed by: Andrew P. Lentvorski, Jr <bsder@allcaps.org>