On Fri, Dec 23, 2016 at 8:27 AM, Jan Kara <jack@xxxxxxx> wrote: > On Thu 22-12-16 18:27:40, Paul Moore wrote: >> On Thu, Dec 22, 2016 at 4:15 AM, Jan Kara <jack@xxxxxxx> wrote: >> > Audit tree currently uses inode pointer as a key into the hash table. >> > Getting that from notification mark will be somewhat more difficult with >> > coming fsnotify changes and there's no reason we really have to use the >> > inode pointer. So abstract getting of hash key from the audit chunk and >> > inode so that we can switch to a different key easily later. >> > >> > CC: Paul Moore <paul@xxxxxxxxxxxxxx> >> > Signed-off-by: Jan Kara <jack@xxxxxxx> >> > --- >> > kernel/audit_tree.c | 39 ++++++++++++++++++++++++++++----------- >> > 1 file changed, 28 insertions(+), 11 deletions(-) >> >> I have no objections with this patch in particular, but in patch 8, >> are you certain that inode_to_key() and chunk_to_key() will continue >> to return the same key value? > > Yes, that's the intention. Or better in that patch the key will no longer > be inode pointer but instead the fsnotify_list pointer. But still it would > match for chunks attached to an inode and inode itself so comparison > results should stay the same. My apologies, I probably should have been more clear. Yes, I think we are all in agreement that the *_to_key() functions need to return a consistent value for the same object. My concern is that in patch 8 these functions are using different variables (granted they may contain the same value, and therefore evaluate to the same key) and I worry that there is a possibility of the two variables taking on different values and breaking the hash. What guarantees exist that these values will be the same? Are there any safeguards to prevent future patches from accidentally sidestepping these guarantees? -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
