[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19654.56165.616805.136152@quad.stoffel.home>
Date: Tue, 26 Oct 2010 09:45:09 -0400
From: "John Stoffel" <john@...ffel.org>
To: Eric Paris <eparis@...hat.com>
Cc: John Stoffel <john@...ffel.org>, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, hch@...radead.org, zohar@...ibm.com,
warthog9@...nel.org, david@...morbit.com, jmorris@...ei.org,
kyle@...artin.ca, hpa@...or.com, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, mingo@...e.hu,
viro@...iv.linux.org.uk
Subject: Re: [PATCH 01/11] IMA: use rbtree instead of radix tree for inode
information cache
>>>>> "Eric" == Eric Paris <eparis@...hat.com> writes:
Eric> On Mon, 2010-10-25 at 15:21 -0400, John Stoffel wrote:
>> >>>>> "Eric" == Eric Paris <eparis@...hat.com> writes:
>> Which seems to fly in the face of your claim that it needs to be able
>> to re-enable itself by tracking open inodes even when disabled.
Eric> You're confusing multiple completely unrelated things. Your
Eric> confusing loading an IMA measurement policy vs IMA indicating
Eric> that it's measurements may be unreliable.
So educate me (and the rest of LKML) about these differences and what
they mean. Can you please add in a patch to this series which puts in
some documentation on how and why to use this stuff?
And can you also change the Kconfig to default to 'N' for this feature
too! The help text says to say 'N' by default, so that should be the
default, right?
>> As the number of inodes goes up (say during a backup which reads
>> them...) won't the size of this cache go up as well, even when IMA is
>> disabled? Why is this overhead even needed?
Eric> At the end of this patch the number of integrity structures
Eric> still has a 1-1 mapping with the number of inodes. If you look
Eric> at the entire series you will see that is not the case.
Eric> This patch by itself will cut the memory usage per inode by
Eric> almost 600 bytes.
That's a good thing then.
John
--
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/
Powered by blists - more mailing lists