On Fri, May 3, 2019 at 2:48 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
> > > [1] f02a9ad1f15d ("fs: handle inode->i_version more efficiently")
> >
> > Thank you. I wasn't aware of this and it makes sense,
>
> The question is whether this impacts your current set of patches? We
> really need to take this discussion back to the mailing list. I've
> responded to my original post with this info.
Hmm, if we add the iversion query as you suggested the function can be
added as a polling point just about anywhere. I added it in there now.
I sent the current state of the upstream port as a new patch with a
proper topic. The mm page scanning code is so rough that it is still
omitted, let's continue the discussion from the core plumbing first. I
did not adopt to your function naming changes yet as the scope of the
work is now much wider, plain 'ima_file_sync' may be misleading as we
also follow the data as it's being written.
Before you ask, the reason why it now does the periodic measurements
of the files as they are written instead of doing 'mod_delayed_work'
timer kicking is that the 'mod_delayed_work' seems quite heavy. Now
there is almost no added latency to the 'write()' loop, just random
measurements with freely definable intervals.
--
Janne
