Remove kdump Remove the obsolete kdump debugging tool from the tree. Remove and clean up the preprocessor tests associated with KDUMP, KDUMP_RX_LOCK and KDUMP_KERNEL. Clean up the autoconf and Makefiles to remove kdump and the associated autoconf and Makefile vars XLIBELFA and XLIBKVM. The kdump utility has not been well maintained; for some platforms it fails to build (e.g. Solaris 11). For Linux, the makefile does not even try to compile the kdump source but instead creates the kdump file via touch. The intended functionality of kdump has been replaced by various kernel debugging tools, such as dtrace or systemtap. Change-Id: I23fd82f2b96ba58d1b431af76fdf0afe7d7274b9 Reviewed-on: https://gerrit.openafs.org/14623 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
rx: Rely on remote startWait idleness for idleDead This commit removes the functionality introduced in c26dc0e6aaefedc55ed5c35a5744b5c01ba39ea1 (which is also modified by a few later commits), as well as 05f3a0d1e0359f604cc6162708f3f381eabcd1d7. Instead we modify the startWait check in rxi_CheckCall to apply to both "reading" and "writing" to enforce "idle dead" timeouts. Why do this? First, let's start out with the following: If an Rx call gets permanently "stuck", what happens? What should happen? Here, "stuck" means that either the server or client hangs while processing the call. The server or client is waiting for something to complete before it issues the next rx_Read() or rx_Write() call. In various situations over the years, this has happened because the server or client is waiting for a lock, waiting for local disk I/O to complete, or waiting for some other arbitrary event to occur. Currently, what happens with such a "hanging" call is a little complex, and has several different results in different situations. The behavior of a call in this "stuck" situation is handled by the "idle dead" timeout of an Rx call/connection. This timeout is enforced in rxi_CheckCall, in two different conditionals (if an "idle dead" timeout is configured): if (call->startWait && ((call->startWait + idleDeadTime) < now) && (call->flags & RX_CALL_READER_WAIT)) { if (call->state == RX_STATE_ACTIVE) { cerror = RX_CALL_TIMEOUT; goto mtuout; } } and if (call->lastSendData && ((call->lastSendData + idleDeadTime) < now)) { if (call->state == RX_STATE_ACTIVE) { cerror = conn->service ? conn->service->idleDeadErr : RX_CALL_IDLE; idle_timeout = 1; goto mtuout; } } The first of these handles the case where we are waiting to rx_Read() from a call for too long (the other side of the call needs to give us more data). The second handles the case where we are waiting to rx_Write() for too long (the other side of the call needs to read some of the data we sent previously). This second case was added by commit c26dc0e6aaefedc55ed5c35a5744b5c01ba39ea1, but it has the general problem that this check does not check if anyone is actually trying to write to the call, and just tries to keep track of the last time we wrote to the call. So, we may have written some data to the call successfully, and then we went off to do something else. We can then kill the call later for taking too long to write to, even though nobody is trying to write to it. This results in a few problems: (1) When the fileserver is writing to the client, it may need to wait for various locks and it may need to wait for local disk I/O to complete. If this takes too long for any reason, the fileserver will kill the call (currently with VNOSERVICE), but the thread for servicing the call will still keep running until whatever the fileserver was waiting for finishes. (2) lastSendData is set whenever we send any ACK besides an RX_ACK_PING_RESPONSE (as of commit 658d2f47281306dfd46c5eddcecaeadc3e3e7fa9). If we are the server, and we send any such ACK (in particular, RX_ACK_REQUESTED is common), the "idle dead" timer starts. This means the server can easily kill a call for idleness even if the server has never sent the client anything, and even if the server is still actively reading from the client. (3) When a client tries to issue an RPC for the server, the "idle dead" timeout effectively becomes a hard dead timeout, since we will write the RPC arguments to the Rx stream, and then wait for the server to respond with the output arguments. During this time, our 'lastSendData' is the last time we sent our arguments to the server, and so the call must finish before 'call->lastSendData + idleDeadTime' is in the past. In addition to this "idle dead" processing, commit 05f3a0d1e0359f604cc6162708f3f381eabcd1d7 appears to attempt to provide "idle dead"-like behavior by disabling Rx keepalives at certain points (when we're waiting for disk I/O), controlled by the application process (currently only the fileserver). The idea is that if keepalives are disabled, the server will just appear unreachable to the client, and so if disk I/O takes too long, the client will just kill the call because it looks like the server is gone. However, this also has some problems: (A) Clients send their own keepalives, and the server will still respond to them. So, the server will not appear to be inaccessible anyway. But even if it did work: (B) This approach only accounts for delays in disk I/O, and not anywhere else (we could hang for a wide variety of reasons). It also requires the fileserver to decide when it's okay for a call to be killed due to "idle dead" and when it's not, which currently seems to be decided somewhat arbitrarily. (C) This doesn't really let the client dictate its own "idle dead" timeout for idleness specifically; it just looks like the server went away. (D) The fileserver would appear to be unreachable in this situation, but it's not actually unreachable. This can be confusing to clients, since distinguishing between a server that is completely down vs just taking too long is an important distinction. (E) As noted in (1) above, the fileserver thread will still keep waiting for whatever it has been waiting for, even though the call has been killed and is thus useless. So instead of all of this stuff, just modify the rxi_CheckCall "idle dead" check to depend on the call->startWait parameter instead. This parameter will be set whenever anyone is waiting for something to proceed in the call, whether that is waiting to read data or write data. This should make "idle dead" processing much simpler, as it is reduced to effectively: if we've been waiting for longer than N seconds, kill the call. This involves ripping out much of the code related to lastSendData and rx_KeepAlive*. This means removing the call->lastSendData field and the rx_SetServerIdleDeadErr function, since those were only used for the behavior in c26dc0e6aaefedc55ed5c35a5744b5c01ba39ea1. This also means removing rx_KeepAliveOn and rx_KeepAliveOff, since those were only used for the behavior in 05f3a0d1e0359f604cc6162708f3f381eabcd1d7. This commit also removes the only known use of the VNOSERVICE error code, so add some comments saying what this code was used for (especially since it is quite different from other V* error codes). Note that the behavior in (1) could actually be desirable in some situations. In environments that have clients without "idle dead" functionality, and those clients cannot be upgraded or reconfigured, this commit means those clients may hang forever if the server hangs forever. Some sites may want the fileserver to be able to kill such hanging calls, so the client will not hang (even if it doesn't free up the fileserver thread). However, such behavior should really be a special case for such sites, and not be the default behavior (or only behavior) for all sites. The fileserver should just be concerned with maintaining its own threads and availability, and clients should manage their own timeouts and handle hanging servers. Thanks to Markus Koeberl, who originally brought attention to some of the problematic behavior here, and helped investigate what was going on in the fileserver. Change-Id: Ie0497d24f1bf4ad7d30ab59061f96c3298f47d17 Reviewed-on: http://gerrit.openafs.org/10773 Reviewed-by: Daria Brashear <shadow@your-file-system.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
Correct comment typos in a couple files Correct typos in a couple files. These were noticed while researching code paths. Comment changes only. No code change. afs/afs_stats.h has source file names updated on several lines. Many source file name comments are wrong in this file. I didn't attempt to correct them all, just the ones I bumped into. If I bump into others in the future I'll fix them then. rx/rx_call.h has source of enumerated types corrected. Change-Id: Ie78b7f20b5c9c2261ec8a73701e77bdfbabd8465 Reviewed-on: http://gerrit.openafs.org/11172 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
rx: Remove unused timeoutEvent The timeoutEvent pointer in the rx_call structure is unused. Remove it to reduce confusion about which events can hold call reference counts. Change-Id: Ide625fe0af608cc434c33188e642750979a8db21 Reviewed-on: http://gerrit.openafs.org/8536 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
rx: Move bytesSent + bytesRcvd into app only data The call->bytesSent and call->bytesRcvd counters are only manipulated by the application thread in running calls. Move them into the app-only section of the call structure so this is clear. Change-Id: Ib7929a8e34bcb70c8cb9c1f89544adce0d627299 Reviewed-on: http://gerrit.openafs.org/8288 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
rx: Make lock-free call data explicit For speed, the application thread accesses a number of elements of the call structure without holding the call lock. This is safe, as long as the application thread is the only place in which these items of data are accessed. Make this distinction explicit by creating a new structure to hold all of these fields, and include this structure within the rx_call. This turns up one place in the code (SendXmitList) which accesses an application private piece of data in the listener and event threads. A forthcoming patch will fix this. Change-Id: I7b5ffb8b5ce68a2186e37ae64461fe356a40603e Reviewed-on: http://gerrit.openafs.org/8285 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
rx: Use opr queues Modify RX so that it uses opr queues throughout, rather than the older, non-type-safe rx_queue structure and macros. Attempt to clarify which items in a structure are queue headers, and which are linkage pointers. This has the knock on effect that including an RX header doesn't automatically give you rx_queue.h in your application's namespace. Change-Id: I1b3fbcd8c03f8153a557bd4532710bcebfe45818 Reviewed-on: http://gerrit.openafs.org/8232 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
rx: Process ICMP unreachable errors When a machine receives ICMP errors, we can detect them in AFS_RXERRQ_ENV environments. Many of these errors indicate that a machine is not reachable, so we are guaranteed to not get a response from them. When we get such an error for a particular peer, mark all relevant calls with an RX_CALL_DEAD error, since we know we won't get a response from them. This allows some calls to dead/unreachable hosts to fail much more quickly. Do not immediately kill new calls, since obviously the host may have come back up since then (or the routing/firewall/etc was fixed), but only calls that were started before the current error was received. Note that a call doesn't actually notice until the next rxi_CheckCall, since directly killing each of the relevant calls would be rather slow. So, we don't notice a dead peer immediately, though we notice much more quickly than we used to. Reorganize the error queue processing a little bit to make this easier to do. Change-Id: I403540e0677fe2d432901e4ecc19f7f385610b7f Reviewed-on: http://gerrit.openafs.org/7929 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@dementix.org>
rx: Use native 64bit data counters Modify the peer, call and rpc_stats structures to use native 64 bit types for the bytesSent and bytesRcvd data counters. All of our platforms support native 64bit quantities now, so there's absolutely no value in rolling our own. Change-Id: I7c51de73be17821c6472eea535c8476fe0d7a23e Reviewed-on: http://gerrit.openafs.org/7205 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@dementix.org>
rx: rxi_AckAll isn't an event handler rxi_AckAll is coded as if it is an event handler, yet the only call site is a direct call from rx.c. So, rework the function to remove all of the event handling code, change its arguments to match, and make it static. Change-Id: I947c02bf91bf5a3f42d2a389f9393e68f3ccee4b Reviewed-on: http://gerrit.openafs.org/6999 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com> Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Rx: give grow mtu its own call ref count type Change-Id: Ibf62408203d615ff87454a9ecb50c38b6db6d45a Reviewed-on: http://gerrit.openafs.org/6543 Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com> Reviewed-by: Derrick Brashear <shadow@dementix.org> Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com> Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com> Tested-by: BuildBot <buildbot@rampaginggeek.com>
rx: Make CALL_RELE and CALL_HOLD lock refcnt mutex The reference count mutex must always be held when calling CALL_RELE or CALL_HOLD. Instead of requiring that the caller obtain, and release the mutex, do so within the HOLD and RELE macros, greatly simplifying calling code. Provide CALL_RELE_R and CALL_HOLD_R as versions of these macros which can be used by callers who already hold the reference count mutex for other purposes. Change-Id: Ie3e9df8b9d2a79476f1707bd65e588f43271c636 Reviewed-on: http://gerrit.openafs.org/6219 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@dementix.org> Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com> Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
rx: Make the rx_call structure private Hide the rx_call structure for public view. Provide accessors for those elements which are currently accessed by applications. Note that this change as it currently stands removes the visibility of the last sent time, and sequence number information, from the VolMonitor function. Change-Id: Ib25ab5635126f893ae43acb684d92a78278d6ca6 Reviewed-on: http://gerrit.openafs.org/6181 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com> Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>