From: Dave Chinner <david@fromorbit.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, hch@infradead.org,
zohar@us.ibm.com, warthog9@kernel.org, jmorris@namei.org,
kyle@mcmartin.ca, hpa@zytor.com, akpm@linux-foundation.org,
torvalds@linux-foundation.org, mingo@elte.hu,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH 01/11] IMA: use rbtree instead of radix tree for inode information cache
Date: Tue, 26 Oct 2010 10:22:30 +1100 [thread overview]
Message-ID: <20101025232230.GW32255@dastard> (raw)
In-Reply-To: <20101025184118.20504.24290.stgit@paris.rdu.redhat.com>
On Mon, Oct 25, 2010 at 02:41:18PM -0400, Eric Paris wrote:
> The IMA code needs to store the number of tasks which have an open fd
> granting permission to write a file even when IMA is not in use. It needs
> this information in order to be enabled at a later point in time without
> losing it's integrity garantees. At the moment that means we store a
> little bit of data about every inode in a cache. We use a radix tree key'd
> on the inode's memory address. Dave Chinner pointed out that a radix tree
> is a terrible data structure for such a sparse key space. This patch
> switches to using an rbtree which should be more efficient.
I'm not sure this is the right fix, though.
Realistically, there is a 1:1 relationship between the inode and the
IMA information. I fail to see why an external index is needed here
at all - just use a separate structure to store the IMA information
that the inode points to. That makes the need for a new global index
and global lock go away completely.
You're already adding 8 bytes to the inode, so why not make it a
pointer. We've got 4 conditions:
1. not configured - no overhead
2. configured, boot time disabled - 8 bytes per inode
3. configured, boot time enabled, runtime disabled - 8 bytes per
inode + small IMA structure
4. configured, boot time enabled, runtime enabled - 8 bytes per
inode + large IMA structure
Anyone who wants the option of runtime enablement can take the extra
allocation overhead, but otherwise nobody is affected apart from 8
bytes of additional memory per inode. I doubt that will change
anything unless it increases the size of the inode enough to push it
over slab boundaries. And if LSM stacking is introduced, then that 8
bytes per inode overhead will go away, anyway.
This approach doesn't introduce new global lock and lookup overhead
into the main VFS paths, allows you to remove a bunch of code and
has a path forward for removing the 8 byte per inode overhead as
well. Seems like the best compromise to me....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-10-25 23:23 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-25 18:41 [PATCH 01/11] IMA: use rbtree instead of radix tree for inode information cache Eric Paris
2010-10-25 18:41 ` Eric Paris
2010-10-25 18:41 ` [PATCH 02/11] IMA: drop the inode opencount since it isn't needed for operation Eric Paris
2010-10-25 18:41 ` [PATCH 03/11] IMA: use unsigned int instead of long for counters Eric Paris
2010-10-25 18:41 ` [PATCH 04/11] IMA: convert internal flags from long to char Eric Paris
2010-10-25 18:41 ` [PATCH 05/11] IMA: use inode->i_lock to protect read and write counters Eric Paris
2010-10-25 18:41 ` [PATCH 06/11] IMA: use i_writecount rather than a private counter Eric Paris
2010-10-25 19:27 ` John Stoffel
2010-10-25 21:52 ` Eric Paris
2010-10-25 22:25 ` H. Peter Anvin
2010-10-25 22:29 ` Eric Paris
2010-10-26 13:57 ` John Stoffel
2010-10-26 13:53 ` John Stoffel
2010-10-26 22:08 ` H. Peter Anvin
2010-10-25 18:41 ` [PATCH 07/11] IMA: move read counter into struct inode Eric Paris
2010-10-25 18:42 ` [PATCH 08/11] IMA: only allocate iint when needed Eric Paris
2010-10-25 18:42 ` [PATCH 09/11] IMA: drop refcnt from ima_iint_cache since it isn't needed Eric Paris
2010-10-25 18:42 ` [PATCH 10/11] IMA: explicit IMA i_flag to remove global lock on inode_delete Eric Paris
2010-10-25 18:42 ` [PATCH 11/11] IMA: fix the ToMToU logic Eric Paris
2010-10-25 19:21 ` [PATCH 01/11] IMA: use rbtree instead of radix tree for inode information cache John Stoffel
2010-10-25 19:38 ` J.H.
2010-10-25 20:55 ` Linus Torvalds
2010-10-25 20:55 ` Linus Torvalds
2010-10-25 20:57 ` Christoph Hellwig
2010-10-25 21:11 ` Linus Torvalds
2010-10-26 14:01 ` John Stoffel
2010-10-26 15:22 ` Linus Torvalds
2010-10-26 15:30 ` Eric Paris
2010-10-26 15:53 ` John Stoffel
2010-10-26 18:13 ` Al Viro
2010-10-27 13:35 ` James Morris
2010-10-26 14:07 ` John Stoffel
2010-10-26 14:07 ` John Stoffel
2010-10-25 21:34 ` Eric Paris
2010-10-26 13:45 ` John Stoffel
2010-10-25 23:22 ` Dave Chinner [this message]
2010-10-26 0:12 ` Eric Paris
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=20101025232230.GW32255@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=kyle@mcmartin.ca \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=warthog9@kernel.org \
--cc=zohar@us.ibm.com \
/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.