From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, akpm@osdl.org,
Michael A Halcrow <mahalcro@us.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] Keys: Use RCU to manage session keyring pointer
Date: Mon, 11 Apr 2005 15:45:00 -0700 [thread overview]
Message-ID: <20050411224500.GB1304@us.ibm.com> (raw)
In-Reply-To: <29827.1111611346@redhat.com>
On Wed, Mar 23, 2005 at 08:55:46PM +0000, David Howells wrote:
>
> The attached patch uses RCU to manage the session keyring pointer in struct
> signal_struct. This means that searching need not disable interrupts and get a
> the sighand spinlock to access this pointer. Furthermore, by judicious use of
> rcu_read_(un)lock(), this patch also avoids the need to take and put refcounts
> on the session keyring itself, thus saving on even more atomic ops.
>
> Signed-Off-By: David Howells <dhowells@redhat.com>
This looks quite good! A few questions interspersed below.
Thanx, Paul
PS. Sorry to be so slow in getting to this one!
> ---
> warthog>diffstat -p1 keys-rcu-session-2612rc1mm1.diff
> security/keys/process_keys.c | 42 +++++++++++++++++++++---------------------
> security/keys/request_key.c | 7 +++----
> 2 files changed, 24 insertions(+), 25 deletions(-)
>
> diff -uNrp linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/process_keys.c linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/process_keys.c
> --- linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/process_keys.c 2005-03-23 17:22:46.000000000 +0000
> +++ linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/process_keys.c 2005-03-23 18:27:12.055768099 +0000
> @@ -1,6 +1,6 @@
> /* process_keys.c: management of a process's keyrings
> *
> - * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
> + * Copyright (C) 2004-5 Red Hat, Inc. All Rights Reserved.
> * Written by David Howells (dhowells@redhat.com)
> *
> * This program is free software; you can redistribute it and/or
> @@ -181,7 +181,7 @@ static int install_process_keyring(struc
> goto error;
> }
>
> - /* attach or swap keyrings */
> + /* attach keyring */
> spin_lock_irqsave(&tsk->sighand->siglock, flags);
> if (!tsk->signal->process_keyring) {
> tsk->signal->process_keyring = keyring;
> @@ -227,12 +227,14 @@ static int install_session_keyring(struc
>
> /* install the keyring */
> spin_lock_irqsave(&tsk->sighand->siglock, flags);
> - old = tsk->signal->session_keyring;
> - tsk->signal->session_keyring = keyring;
> + old = rcu_dereference(tsk->signal->session_keyring);
I don't understand why rcu_dereference() is needed in this case.
Since we are holding the lock, it should not be possible for
this to change, right? Or am I missing something? (Quite possible,
am not all that familiar with this code.)
> + rcu_assign_pointer(tsk->signal->session_keyring, keyring);
> spin_unlock_irqrestore(&tsk->sighand->siglock, flags);
>
> ret = 0;
>
> + /* we're using RCU on the pointer */
> + synchronize_kernel();
This would want to become synchronize_rcu().
> key_put(old);
> error:
> return ret;
> @@ -245,8 +247,6 @@ static int install_session_keyring(struc
> */
> int copy_thread_group_keys(struct task_struct *tsk)
> {
> - unsigned long flags;
> -
> key_check(current->thread_group->session_keyring);
> key_check(current->thread_group->process_keyring);
>
> @@ -254,10 +254,10 @@ int copy_thread_group_keys(struct task_s
> tsk->signal->process_keyring = NULL;
>
> /* same session keyring */
> - spin_lock_irqsave(¤t->sighand->siglock, flags);
> + rcu_read_lock();
> tsk->signal->session_keyring =
> - key_get(current->signal->session_keyring);
> - spin_unlock_irqrestore(¤t->sighand->siglock, flags);
> + key_get(rcu_dereference(current->signal->session_keyring));
> + rcu_read_unlock();
>
> return 0;
>
> @@ -381,8 +381,7 @@ struct key *search_process_keyrings_aux(
> key_match_func_t match)
> {
> struct task_struct *tsk = current;
> - unsigned long flags;
> - struct key *key, *ret, *err, *tmp;
> + struct key *key, *ret, *err;
>
> /* we want to return -EAGAIN or -ENOKEY if any of the keyrings were
> * searchable, but we failed to find a key or we found a negative key;
> @@ -436,17 +435,18 @@ struct key *search_process_keyrings_aux(
> }
>
> /* search the session keyring last */
> - spin_lock_irqsave(&tsk->sighand->siglock, flags);
> -
> - tmp = tsk->signal->session_keyring;
> - if (!tmp)
> - tmp = tsk->user->session_keyring;
> - atomic_inc(&tmp->usage);
> -
> - spin_unlock_irqrestore(&tsk->sighand->siglock, flags);
> + if (tsk->signal->session_keyring) {
> + rcu_read_lock();
> + key = keyring_search_aux(
> + rcu_dereference(tsk->signal->session_keyring),
> + type, description, match);
> + rcu_read_unlock();
> + }
> + else {
> + key = keyring_search_aux(tsk->user->session_keyring,
> + type, description, match);
This one is constant, right? If not, I don't understand the locking design.
> + }
>
> - key = keyring_search_aux(tmp, type, description, match);
> - key_put(tmp);
> if (!IS_ERR(key))
> goto found;
>
> diff -uNrp linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/request_key.c linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/request_key.c
> --- linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/request_key.c 2005-03-23 17:35:16.000000000 +0000
> +++ linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/request_key.c 2005-03-23 18:14:13.908029567 +0000
> @@ -175,13 +175,12 @@ static struct key *__request_key_constru
> key->expiry = now.tv_sec + key_negative_timeout;
>
> if (current->signal->session_keyring) {
> - unsigned long flags;
> struct key *keyring;
>
> - spin_lock_irqsave(¤t->sighand->siglock, flags);
> - keyring = current->signal->session_keyring;
> + rcu_read_lock();
> + keyring = rcu_dereference(current->signal->session_keyring);
> atomic_inc(&keyring->usage);
> - spin_unlock_irqrestore(¤t->sighand->siglock, flags);
> + rcu_read_unlock();
>
> key_link(keyring, key);
> key_put(keyring);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2005-04-11 22:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-23 20:14 [PATCH 1/3] Keys: Pass session keyring to call_usermodehelper() David Howells
2005-03-23 20:19 ` [PATCH 2/3] Keys: Use RCU to manage session keyring pointer David Howells
2005-03-23 21:07 ` Andrew Morton
2005-03-23 21:28 ` David Howells
2005-03-23 20:52 ` [PATCH 3/3] Keys: Make request-key create an authorisation key David Howells
2005-03-24 11:41 ` [PATCH 3/3] Keys: Make request-key create an authorisation key [try #2] David Howells
2005-03-31 19:50 ` [PATCH 3/3] Keys: Make request-key create an authorisation key Benoit Boissinot
2005-04-01 15:30 ` [PATCH] Keys: Fix request_key default keyring handling David Howells
2005-03-23 20:55 ` [PATCH 2/3] Keys: Use RCU to manage session keyring pointer David Howells
2005-04-11 22:45 ` Paul E. McKenney [this message]
2005-04-12 9:11 ` David Howells
2005-04-12 14:50 ` Paul E. McKenney
2005-03-23 21:06 ` [PATCH 1/3] Keys: Pass session keyring to call_usermodehelper() Andrew Morton
2005-03-23 21:26 ` David Howells
2005-03-23 22:34 ` Andrew Morton
2005-03-23 22:49 ` David Howells
2005-03-24 0:58 ` Kyle Moffett
2005-03-23 22:25 ` Mike Waychison
2005-03-24 11:38 ` [PATCH 1/3] Keys: Pass session keyring to call_usermodehelper() [try #2] David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050411224500.GB1304@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=akpm@osdl.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mahalcro@us.ibm.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox