> > Some notable implementation details are as follows: > > * struct inode is _not_ extended to associate audit data with the > inode. A hash table is used in which the inode is hashed to > retrieve its audit data. We know if an inode has audit data > if I_AUDIT has been turned on in inode->i_state.
why is this? It would be a very logical thing to store this stuff inside the inode. It sounds like a bad design to keep per inode data out of the inode. (if you're concerned about taking a lot of space, put a pointer to a kmalloc()'d piece of memory into the inode instead). A hash is just, well, odd for this. > * Inodes with audit data are implicitly pinned in memory when > I_AUDIT is turned on in inode->i_state. This prevents an > auditable incore inode from being pushed out of the icache, > preserving auditability even under memory pressures. sounds like inotify then... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
