> > Jan, > > > > What are your thoughts about this optimization patch? > > > > My thoughts are that the optimization is clearly a win, but do we > > really want to waste a full long in super_block for counting access > > event watchers that may never exist? > > Meh, not too excited about it. Couldn't you use a flag in s_fsnotify_mask? > Maybe that's what you mean below. > Yes, for my v2 I will use a "taint" flag in s_fsnotify_mask instead of keeping count of content monitors. > > > > Should we perhaps instead use a flag to say that "access watchers > > existed"? > > > > We could put s_fsnotify_access_watchers inside a struct > > fsnotify_sb_mark_connector and special case alloc/free of > > FSNOTIFY_OBJ_TYPE_SB connector. > > Would it make sense without incurring performance impact to move > atomic_long_t s_fsnotify_connectors and your new atomic_long_t into a > struct fsnotify_data that gets allocated when an sb is created? Then we > don't waste space in struct super_block. This is basically a copy-paste > of the LSM sb->s_security approach. Not as trivial to move s_fsnotify_connectors, but I think it should be possible, because basically, I don't think we need to ever detach an sb connector once it is attached. I did already look at this when writing the above suggestion, but it was not straightforward so left it for later. This change would be relevant for another feature that I need for HSM called "default event mask" (sort of like the default iptables rule), so I will look into making those changes when I get to this feature. Thanks, Amir.
