linux-fsdevel.vger.kernel.org archive mirror
 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: 01 Sep 2002 20:42:57 +0200	[thread overview]
Message-ID: <1030905777.2145.91.camel@ldb> (raw)
In-Reply-To: <15730.17012.61365.788871@charged.uio.no>

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

On Sun, 2002-09-01 at 18:38, Trond Myklebust wrote:
> >>>>> " " == Luca Barbieri <ldb@ldb.ods.org> writes:
> 
>      > That's what the code did, unless I misunderstood it.  Anyway if
>      > you want to give a different fsuid to a filesystem function,
>      > you either pass credentials as a parameter (that means that you
>      > change all the functions in the call chain to do that) or you
> 
> If you read through the beginning of the thread, you will see that
> this is *exactly* what I'm proposing to do. Just not in this one
> already very large patch.
But you'll need to modify the declaration of the various function
pointers whose implementations might need credentials and modify all
functions that call them and deal with permissions.
Instead with my proposal the credentials are automatically immutable
across the syscall without needing to worry at all about locks, counts
and sharing.

And remember that passing parameters has a cost since you need to push
them and the stack will be larger, occupy more cachelines, and thus
cause more cache misses.
All this without any particular reason to do since normally the
credentials are always the same.

Of course, if you have reason to think that we'll need to call VFS
functions with a lot of differential credential then you are right, but
otherwise you would add just a lot of useless overhead and code
modifications.


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

  reply	other threads:[~2002-09-01 18:42 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
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 [this message]
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=1030905777.2145.91.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).