public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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(&current->sighand->siglock, flags);
> +	rcu_read_lock();
>  	tsk->signal->session_keyring =
> -		key_get(current->signal->session_keyring);
> -	spin_unlock_irqrestore(&current->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(&current->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(&current->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/
> 
> 

  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