Messages in this thread | | | Date | Fri, 31 Oct 2008 11:22:25 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM) |
| |
Quoting Christoph Hellwig (hch@infradead.org): > > /* > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 32477e8..349d548 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -683,6 +683,9 @@ struct inode { > > #ifdef CONFIG_SECURITY > > void *i_security; > > #endif > > +#ifdef CONFIG_INTEGRITY > > + void *i_integrity; > > +#endif > > Sorry, but as said before bloating the inode for this is not an option. > Please use something like the MRU approach I suggested in the last > review round.
Hi Christoph, Mimi is looking into uinsg a tree but is still trying to get the locking right. So in the meantime I just have to ask again - for something which will always be either compiled out, or filled in for every inode, why have the overhead of having an external cache? Either the i_integrity won't be compiled in, or you'll have to go through the external cache for every inode operation anyway. It doesn't make sense to me... Is there a case I'm missing that risks getting hard-hit here (performance-wise), or is this mainly a style thing?
thanks, -serge
| |