From: Luca Barbieri <ldb@ldb.ods.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: trond.myklebust@fys.uio.no,
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 21:38:51 +0200 [thread overview]
Message-ID: <1030822731.1458.127.camel@ldb> (raw)
In-Reply-To: <Pine.LNX.4.44.0208311235110.1255-100000@home.transmeta.com>
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
On Sat, 2002-08-31 at 21:36, Linus Torvalds wrote:
>
> On 31 Aug 2002, Luca Barbieri wrote:
> >
> > 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?
>
> But that makes us copy them every time, even though they practically never
> change.. Much better to only copy them in the extremely rare cases when
> they do change.
Sorry, I have explained myself incorrectly.
When credentials are changed, the changing task walks the list of tasks
sharing credentials with him and sets the propagate_cred flag in their
thread_info's.
The assembly code at entry checks this.
It's just two instructions, one memory read:
cmpl $0, propagate_cred(%ebx)
jnz do_propagate_cred
We could use the flags field, but we need atomic and/or and we still
don't have them for all architectures.
We could even merge this with the syscall trace check (but that brings
more complexity to avoid races).
Then the rest of the code doesn't need to know at all that credentials
are shared and is simpler and faster.
We have however a larger penalty on credential change but, as you say,
that's extremely rare (well, perhaps not necessarily extremely, but
still rare).
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2002-08-31 19:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1030820234.4408.119.camel@ldb>
2002-08-31 19:36 ` [PATCH] Initial support for struct vfs_cred [0/1] Linus Torvalds
2002-08-31 19:38 ` Luca Barbieri [this message]
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:20 ` Luca Barbieri
[not found] ` <1030890022.2145.52.camel@ldb>
2002-09-01 16:40 ` Trond Myklebust
[not found] ` <15730.17171.162970.367575@charged.uio.no>
2002-09-01 18:54 ` Luca Barbieri
2002-09-01 19:40 ` Trond Myklebust
[not found] ` <15730.27952.29723.552617@charged.uio.no>
2002-09-01 21:34 ` Luca Barbieri
[not found] ` <1030916061.2145.344.camel@ldb>
2002-09-01 21:56 ` Trond Myklebust
[not found] ` <15730.36080.987645.452664@charged.uio.no>
2002-09-01 22:50 ` Luca Barbieri
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 15:15 ` Daniel Phillips
2002-09-01 15:35 ` Luca Barbieri
[not found] <15728.61345.184030.293634@charged.uio.no>
2002-08-31 18:57 ` Luca Barbieri
2002-08-31 19:51 ` Luca Barbieri
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=1030822731.1458.127.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).