so that both parent and child processes ignore this signal.
PR: bin/97768
Submitted by: Gea-Suan Lin <gslin at csie dot nctu dot edu dot tw>
MFC after: 3 days
We already check for write() failures and handle EPIPE.
Failure to handle SIGPIPE was resulting in rpc.lockd terminating.
PR: bin/97768
Reported by: Gea-Suan Lin <gslin at csie dot nctu dot edu dot tw>
MFC after: 1 day
result in abort() beeing called. This is because there is a limit of
the number of groups in the RPC which is 16. When the actual number of
groups is too large it results in xdr_array() returning an error which,
in turn, authunix_create() handles by just calling abort().
Fix this by passing only the first 16 groups to authunix_create().
xt_rtaddr member of SVCXPRT structure. This allows to use IPv6
address stored in "struct sockaddr_storage" in "struct netbuf".
- Output the reason of getnameinfo() error.
Reviewed by: alfred
apply the patch of bin/61718 (which should include/elimatate kern/61122 also).
It seems to fix a few annoying bugs.
PR: bin/61718, kern/61122
Submitted by: bg@sics.seohartman@mail.physik.uni-mainz.de
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>
print out the correct transport it failed on rather than always
spitting out 'udp', also call nc_sperror() to give a more verbose
error message detailing the problem.
rpcgen can't really make those fields const because the remote side might
want to munge them, so we need to pass non-const in. Hackish, but should
work.
Alfred, I took a look at retry_blockingfilelocklist() and the
solution seemed simple enough. Please correct me if I am wrong.
It seems said routine doesn't take into account boundary conditions
when putting back file_lock entries into the blocked lock-list.
Specifically, it fails when the file_lock being put back is the
last element in the list, and when it is the only element in the
list. I've included a patch below.
Basically, it introduces another variable: pfl, which keeps track
of the list item before ifl. That way if nfl is NULL, ifl gets
inserted after pfl. If pfl is also NULL, then it gets inserted
at the head of the list (since it was the only element in the
list).
Submitted by: Mike Makonnen <mike_makonnen@yahoo.com>
Tested by: Thomas Quinot <thomas@cuivre.fr.eu.org>
Fix the WARNS 1 warnings except unused variables.
Add prototype for log_netobj().
Don't compare signed/unsigned.
Cast u_int64_t to 'unsigned long long' and print using %llu.
Fix constness of string arrays.
Use a cast to avoid an unused parameter in a signal handler.
alarm(2) can't fail, so don't check for it.
ANSI'ify some functions.
src/sys/fs/fifofs/fifo_vnops.c) to serve locks better, my previous
workaround for lack of decent fifo system wasn't cutting it,
particularly the kernel would send a message down the fifo and
immediately close it, this would lead to delayed unlock requests
being seen by the lockd causing all sorts of badness.
Basically, don't reopen the fifo, just select(2) on it.
