summaryrefslogtreecommitdiff
path: root/Documentation/security
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2019-06-19 18:10:16 +0300
committerDavid Howells <dhowells@redhat.com>2019-06-26 22:58:13 +0300
commit3b8c4a08a471d56ecaaca939c972fdf5b8255629 (patch)
tree43ed0238e6fe5b09b6654310b6e71f051e55e1bc /Documentation/security
parent7743c48e54ee9be9c799cbf3b8e3e9f2b8d19e72 (diff)
downloadlinux-3b8c4a08a471d56ecaaca939c972fdf5b8255629.tar.xz
keys: Kill off request_key_async{,_with_auxdata}
Kill off request_key_async{,_with_auxdata}() as they're not currently used. Signed-off-by: David Howells <dhowells@redhat.com>
Diffstat (limited to 'Documentation/security')
-rw-r--r--Documentation/security/keys/core.rst32
-rw-r--r--Documentation/security/keys/request-key.rst23
2 files changed, 2 insertions, 53 deletions
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 003f1452a5b7..a0e245f9576f 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -1115,38 +1115,6 @@ payload contents" for more information.
is a blob of length callout_len, if given (the length may be 0).
- * A key can be requested asynchronously by calling one of::
-
- struct key *request_key_async(const struct key_type *type,
- const char *description,
- const void *callout_info,
- size_t callout_len);
-
- or::
-
- struct key *request_key_async_with_auxdata(const struct key_type *type,
- const char *description,
- const char *callout_info,
- size_t callout_len,
- void *aux);
-
- which are asynchronous equivalents of request_key() and
- request_key_with_auxdata() respectively.
-
- These two functions return with the key potentially still under
- construction. To wait for construction completion, the following should be
- called::
-
- int wait_for_key_construction(struct key *key, bool intr);
-
- The function will wait for the key to finish being constructed and then
- invokes key_validate() to return an appropriate value to indicate the state
- of the key (0 indicates the key is usable).
-
- If intr is true, then the wait can be interrupted by a signal, in which
- case error ERESTARTSYS will be returned.
-
-
* To search for a key under RCU conditions, call::
struct key *request_key_rcu(const struct key_type *type,
diff --git a/Documentation/security/keys/request-key.rst b/Documentation/security/keys/request-key.rst
index 45049abdf290..5a210baa583a 100644
--- a/Documentation/security/keys/request-key.rst
+++ b/Documentation/security/keys/request-key.rst
@@ -23,21 +23,6 @@ or::
or::
- struct key *request_key_async(const struct key_type *type,
- const char *description,
- const char *callout_info,
- size_t callout_len);
-
-or::
-
- struct key *request_key_async_with_auxdata(const struct key_type *type,
- const char *description,
- const char *callout_info,
- size_t callout_len,
- void *aux);
-
-or::
-
struct key *request_key_rcu(const struct key_type *type,
const char *description);
@@ -53,15 +38,11 @@ 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() calls are like the in-kernel request_key*()
-calls, except that they permit auxiliary data to be passed to the upcaller (the
+The request_key_with_auxdata() calls is like the in-kernel request_key() call,
+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 request_key_rcu() call is like the in-kernel request_key() call, except
that it doesn't check for keys that are under construction and doesn't attempt
to construct missing keys.