2.6.24

 Documentation

diff --git a/Documentation/keys-request-key.txt b/Documentation/keys-request-key.txt
index c1f64fd..266955d 100644
--- a/Documentation/keys-request-key.txt
+++ b/Documentation/keys-request-key.txt
@@ -20,6 +20,19 @@ or:
                     const char *callout_string,
                     void *aux);
 
+or:
+
+   struct key *request_key_async(const struct key_type *type,
+                  const char *description,
+                  const char *callout_string);
+
+or:
+
+   struct key *request_key_async_with_auxdata(const struct key_type *type,
+                     const char *description,
+                     const char *callout_string,
+                     void *aux);
+
 Or by userspace invoking the request_key system call:
 
    key_serial_t request_key(const char *type,
@@ -32,10 +45,14 @@ does not need to link the key to a keyring to prevent it from being immediately
 destroyed.  The kernel interface returns a pointer directly to the key, and
 it's up to the caller to destroy the key.
 
-The request_key_with_auxdata() call is like the in-kernel request_key() call,
-except that it permits auxiliary data to be passed to the upcaller (the default
-is NULL).  This is only useful for those key types that define their own upcall
-mechanism rather than using /sbin/request-key.
+The request_key*_with_auxdata() calls are like the in-kernel request_key*()
+calls, except that they permit auxiliary data to be passed to the upcaller (the
+default is NULL).  This is only useful for those key types that define their
+own upcall mechanism rather than using /sbin/request-key.
+
+The two async in-kernel calls may return keys that are still in the process of
+being constructed.  The two non-async ones will wait for construction to
+complete first.
 
 The userspace interface links the key to a keyring associated with the process
 to prevent the key from going away, and returns the serial number of the key to