All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Barbieri <ldb@ldb.ods.org>
To: trond.myklebust@fys.uio.no
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Linux FSdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Initial support for struct vfs_cred   [0/1]
Date: 31 Aug 2002 20:57:14 +0200	[thread overview]
Message-ID: <1030820234.4408.119.camel@ldb> (raw)
In-Reply-To: <15728.61345.184030.293634@charged.uio.no>

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

But aren't credential changes supposed to be infrequent?

If so, isn't it faster to put the fields directly in task_struct, keep a
separate shared structure and copy them on kernel entry?

Here is some pseudocode to better illustrate the idea.

vfs_shared_cred::lock can be removed if it's not necessary to do atomic
modifications of multiple cred fields (otherwise you could copy and then
exchange a pointer).

vfs_shared_cred::tasklist_lock can be replaced with RCU.

struct vfs_cred_groups
{
	int ngroups;
	gid_t groups[];
};

struct vfs_cred
{
	uid_t uid, gid;
	struct vfs_cred_groups* groups;
};

struct vfs_shared_cred
{
	atomic_t count;
	spinlock_t lock;
	spinlock_t tasklist_lock;
	vfs_cred cred;
};

struct task_struct
{
	struct vfs_cred cred;
	struct vfs_cred* shared_cred;
	list_t shared_cred_list;
};

struct thread_info
{
	unsigned propagate_cred;
};

propagate_cred()
{
	current_thread_info()->propagate_cred = 0;

	spin_lock(&current->shared_cred->lock);
	current->cred = current->shared_cred->cred;
	spin_unlock(&current->shared_cred->lock);
}

kernel_entry() /* asm for every architecture :( */
{
	if(unlikely(current_thread_info()->propagate_cred))
		propagate_cred();
}

change_credentials()
{
	list_t list;

	spin_lock(&current->shared_cred->lock);
	frob(current->shared_cred);
	spin_unlock(&current->shared_cred->lock);

	wmb();

	spin_lock(&current->shared_cred->tasklist_lock);
	list_for_each(list, &current->shared_cred_list)
	{
		struct task_struct* task = list_entry(list, struct task_struct, shared_cred_list);
		task->thread_info->propagate_cred = 1;
	}
	spin_unlock(&current->shared_cred->tasklist_lock);
}

clone()
{
	spin_lock(&current->shared_cred->lock);
	new->cred = current->shared_cred->cred); /* not current->cred! */
	spin_unlock(&current->shared_cred->lock);

	if(flags & CLONE_CRED)
	{
		new->shared_cred = get_shared_cred(current->shared_cred);
		spin_lock(&current->shared_cred->tasklist_lock);
		list_add(new, &current->shared_cred_list);
		spin_unlock(&current->shared_cred->tasklist_lock);
	}
}

static void release_task(struct task_struct * p)
{
	spin_lock(&current->shared_cred->tasklist_lock);
	__list_del(current->shared_cred_list);
	spin_unlock(&current->shared_cred->tasklist_lock);

	put_shared_cred(current->shared_cred);
}


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2002-08-31 18:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-31 16:32 [PATCH] Initial support for struct vfs_cred [0/1] Trond Myklebust
2002-08-31 18:57 ` Luca Barbieri
2002-08-31 18:57 ` Luca Barbieri [this message]
2002-08-31 19:36   ` Linus Torvalds
2002-08-31 19:38     ` Luca Barbieri
2002-08-31 22:30       ` Trond Myklebust
2002-08-31 23:13         ` Luca Barbieri
2002-09-01 13:03           ` Trond Myklebust
2002-09-01 14:10             ` Trond Myklebust
2002-09-01 14:10               ` Trond Myklebust
2002-09-01 14:20               ` Luca Barbieri
2002-09-01 14:20               ` Luca Barbieri
2002-09-01 16:40                 ` Trond Myklebust
2002-09-01 16:40                 ` Trond Myklebust
2002-09-01 18:54                   ` Luca Barbieri
2002-09-01 19:40                     ` Trond Myklebust
2002-09-01 21:34                       ` Luca Barbieri
2002-09-01 21:56                         ` Trond Myklebust
2002-09-01 22:50                           ` Luca Barbieri
     [not found]                             ` <20020903034607.GF29452@ravel.coda.cs.cmu.edu>
2002-09-08 22:04                               ` Luca Barbieri
2002-09-09  6:22                                 ` Jan Harkes
2002-09-09 11:17                                   ` Luca Barbieri
2002-09-01 21:56                         ` Trond Myklebust
2002-09-01 21:34                       ` Luca Barbieri
2002-09-01 19:40                     ` Trond Myklebust
2002-09-01 14:33             ` Luca Barbieri
2002-09-01 16:38               ` Trond Myklebust
2002-09-01 18:42                 ` Luca Barbieri
2002-09-01 19:25                   ` Trond Myklebust
2002-09-01 21:36                     ` Luca Barbieri
2002-09-01 21:36                     ` Luca Barbieri
2002-09-01 15:15           ` Daniel Phillips
2002-09-01 15:35             ` Luca Barbieri
2002-08-31 19:51 ` Luca Barbieri
  -- strict thread matches above, loose matches on Subject: below --
2002-08-31 16:32 Trond Myklebust

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=1030820234.4408.119.camel@ldb \
    --to=ldb@ldb.ods.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=trond.myklebust@fys.uio.no \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.