Re: [PATCH 1/3] IMA: move read/write counters into struct inode

[Eric Paris <eparis@redhat.com>]

On Mon, 2010-10-18 at 21:30 -0400, Christoph Hellwig wrote:
> I do not like this at all.   It bloats the inode with three unsigned
> long values for a feature no sane person would ever use.  And given
> that distros are sweet-talked by IBM to enable it the world will pay
> a huge penality for those 0.5% of the userbase that use IMA.
> 
> Please reorder your series to have patch to disable IMA unless
> explicitly enabled on the kernel command line first, and then second
> use the rbtree from your last patch.

More cryptic command line options and complexity is not the solution.  I
have no plans to send (a fixed/"working" version of) Kyle's patch which
would cause a userspace regression since working machines would
magically stop working.

The right solution is to provide features without unreasonably impacting
those who do not want those features.  At the moment my patch series
reduces memory usage by a factor of at least 40 and eliminates the
locking contention and serialization of bringing inodes into and out of
core.  It does so without introducing ANY additional overhead or
complexity.

If there is a general consensus that 24 bytes per inode is too large we
can move forward from here and drop the 'opencount' and save 8 bytes
(while eliminating the debugging and verification this code has helped
to provide in the past)

If there is a general consensus that 16 bytes per inode is too large we
can travel down the much more complex route of attempting to collect
this information dynamically by freezing userspace, scanning every open
file, and calculating the information.  We would then have a 2 stage
integrity structure, the first with just counters and the second would
contain integrity information if needed.

I'm willing to add those next 2 steps to my todo list if there is a
consensus that the situation at hand is untenable, but those cannot be
my highest priority.  We are talking about a feature which has been
enabled without massive complaint (aside from having bugs fixed in the
kernel, in IMA, and in out of tree modules) in Fedora kernels for over a
year.  Obviously I think Dave's report is a big deal.  Things were
really really wrong, and I'm willing to fix it when things are wrong,
but eventually I hit the point of diminishing returns.

-Eric