public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steve French <sfrench@us.ibm.com>
Subject: Re: [PATCH][2/7] xattr consolidation - LSM hook changes
Date: Tue, 24 Aug 2004 21:27:32 +0200	[thread overview]
Message-ID: <1093375652.20259.73.camel@winden.suse.de> (raw)
In-Reply-To: <20040824025259.GC21964@parcelfarce.linux.theplanet.co.uk>

On Tue, 2004-08-24 at 04:52, viro@parcelfarce.linux.theplanet.co.uk
wrote:
> On Mon, Aug 23, 2004 at 08:54:14PM -0400, James Morris wrote:
> > On Mon, 23 Aug 2004, Stephen Smalley wrote:
> > 
> > > On Mon, 2004-08-23 at 15:03, Christoph Hellwig wrote:
> > 
> > > > Given that the actual methods take a dentry this sounds like a bad design.
> > > > Can;t you just pass down the dentry through all of the ext2 interfaces?
> > > 
> > > Changing the methods to take an inode would be even better, IMHO, as the
> > > dentry is unnecessary.  That would simplify SELinux as well.
> > 
> > This could work for all in-tree filesystems with xattrs, except CIFS,
> > which passes the dentry to it's own build_path_from_dentry() function.  
> > 
> > (In this case, they probably want to use d_path() and have a vfsmnt added 
> > to the methods?).
> 
> No.  Think for a second and you'll see why - we are doing an operation that
> by definition should not depend on where we have mounted the filesystem in
> question.

Hm. I seem to recall that Al didn't want to change this within the 2.6
series -- is this still the case? I would favor switching from dentries
to inodes in the xattr iops. Steve, can you live with inodes?

Cheers,
-- 
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX AG



  reply	other threads:[~2004-08-24 19:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-23 18:14 [PATCH][0/7] xattr consolidation and support for ramfs & tmpfs James Morris
2004-08-23 18:15 ` [PATCH][1/7] xattr consolidation - libfs James Morris
2004-08-23 18:16   ` [PATCH][2/7] xattr consolidation - LSM hook changes James Morris
2004-08-23 18:17     ` [PATCH][3/7] xattr consolidation - ext3 James Morris
2004-08-23 18:18       ` [PATCH][4/7] xattr consolidation - ext2 James Morris
2004-08-23 18:19         ` [5/7] xattr consolidation - devpts James Morris
2004-08-23 18:20           ` [PATCH][6/7] add xattr support to tmpfs James Morris
2004-08-23 18:22             ` [PATCH][7/7] add xattr support to ramfs James Morris
2004-08-23 20:26               ` Christoph Hellwig
2004-08-23 20:26                 ` Stephen Smalley
2004-08-23 20:46                   ` Christoph Hellwig
2004-08-23 20:59                   ` Greg KH
2004-08-23 21:27                     ` [PATCH][7/7] add xattr support to ramfs [u] Martin Schlemmer [c]
2004-08-24  0:52                     ` [PATCH][7/7] add xattr support to ramfs Valdis.Kletnieks
2004-08-24 11:27                     ` Stephen Smalley
2004-08-25  7:03                       ` Miles Bader
2004-08-25 13:14                         ` James Morris
2004-08-23 19:06             ` [PATCH][6/7] add xattr support to tmpfs Christoph Hellwig
2004-08-23 19:03     ` [PATCH][2/7] xattr consolidation - LSM hook changes Christoph Hellwig
2004-08-23 19:06       ` James Morris
2004-08-23 19:13       ` Stephen Smalley
2004-08-24  0:54         ` James Morris
2004-08-24  2:52           ` viro
2004-08-24 19:27             ` Andreas Gruenbacher [this message]
2004-08-23 23:28       ` Andreas Dilger
2004-08-23 18:49   ` [PATCH][1/7] xattr consolidation - libfs Christoph Hellwig
2004-08-24  4:32     ` James Morris
2004-08-24 10:05       ` Christoph Hellwig
2004-08-24 19:42         ` Andreas Gruenbacher
2004-08-24 20:19           ` James Morris
2004-08-24 19:41 ` [PATCH][0/7] xattr consolidation and support for ramfs & tmpfs Andreas Gruenbacher

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=1093375652.20259.73.camel@winden.suse.de \
    --to=agruen@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfrench@us.ibm.com \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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