linux-kernel - Re: [RFC PATCH] fs: xattr-based FS_IOC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1389132525.23310.22.camel@ret.masoncoding.com>
Date:	Tue, 7 Jan 2014 22:08:16 +0000
From:	Chris Mason <clm@...com>
To:	"darrick.wong@...cle.com" <darrick.wong@...cle.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hch@...radead.org" <hch@...radead.org>,
	"miklos@...redi.hu" <miklos@...redi.hu>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"rlb@...aultvalue.org" <rlb@...aultvalue.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"aurelien@...el32.net" <aurelien@...el32.net>,
	"tytso@....edu" <tytso@....edu>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"david@...morbit.com" <david@...morbit.com>,
	"jack@...e.cz" <jack@...e.cz>
Subject: Re: [RFC PATCH] fs: xattr-based FS_IOC_[GS]ETFLAGS interface

On Tue, 2014-01-07 at 14:02 -0800, Darrick J. Wong wrote:
> On Tue, Jan 07, 2014 at 07:59:15PM +0000, Chris Mason wrote:
> > On Tue, 2014-01-07 at 11:43 -0800, Darrick J. Wong wrote:
> > > On Tue, Jan 07, 2014 at 12:04:30PM -0500, Theodore Ts'o wrote:
> > > > On Tue, Jan 07, 2014 at 07:49:35AM -0800, Christoph Hellwig wrote:
> > > > > On Tue, Jan 07, 2014 at 01:48:31PM +0100, Jan Kara wrote:
> > > > > >   I have to say I'm not thrilled by the idea of juggling strings in
> > > > > > userspace and in kernel to set a flag for an inode...
> > > > > 
> > > > > Nevermind the massive amounts of code that sit in the filesystem.
> > > > 
> > > > The reason for this patch was to address what Dave Chinner has called
> > > > "a shitty interface"[1].  Using bitfields that need to be coordinated
> > > > across file systems, when sometimes a bit assignment is validly a fs
> > > > specific thing, and then later becomes something that gets shared
> > > > across file systems.
> > > > 
> > > > [1] http://thread.gmane.org/gmane.linux.file-systems/80164/focus=80396
> > > > 
> > > > If we don't go about it this way, there are alternatives: we could
> > > > create new ioctls (or a new syscall) as we start running out of bits
> > > > used by FS_IOC_[GS]ETFLAGS.  We can create new ioctls for bits which
> > > > are intended for fs-specific flags, which then later get promoted to
> > > > the new syscall when some functionality starts to get shared accross
> > > > other file systems (probably with a different bit assignment).  This
> > > > is certainly less code, but it does mean more complexity outside of
> > > > the code when we try to coordinate new functionality across file
> > > > systems.
> > > 
> > > I had thought of indexed inode flags as an alternative to the xattr/string
> > > parsing thing.  Feature flags make their first appearance as part of a per-FS
> > > flag-space and are migrated to the common flag-space when there is demand.
> > > It would also avoid the need for each fs to create its own flag ioctl.
> > > 
> > > On the other hand, someone suggested I try remaking IOC_[GS]ETFLAG as an xattr,
> > > so off I went. :)
> > > 
> > 
> > At least in btrfs xattrs are more expensive than something right in the
> > inode.  We can cache it when we load the inode (it'll be right next to
> > the inode most of the time) but for performance critical things I do
> > like the good old fashioned flags.
> 
> Just to clarify -- I wasn't proposing any on-disk changes for any filesystems,
> merely creating virtual xattrs that wrap the inode flags.

Ah, sorry I missed that part.  I was assuming that as we run out of
flags we'll want to use real xattrs instead.

> 
> > It's also possible to turn xattrs off, so we have to deal with
> > filesystems that are mounted with them off and then back on again.  I
> > can't think of huge problems from that right now, just something to be
> > aware of.
> 
> Just to satisfy my curiosity: are xattrs always separate objects in btrfs?

Strictly speaking, yes.  They aren't in the inode struct.  But most of
the time they will be in the same btree block.  For anything performance
critical we can order the keys to push them to the front.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/