From: Mimi Zohar <zohar@linux.ibm.com>
To: Janne Karhunen <janne.karhunen@gmail.com>
Cc: linux-integrity@vger.kernel.org
Subject: Re: [PATCH] integrity: make 'sync' update the inode integrity state
Date: Thu, 25 Apr 2019 08:14:07 -0400 [thread overview]
Message-ID: <1556194447.3894.105.camel@linux.ibm.com> (raw)
In-Reply-To: <CAE=NcraD_VD=ZmNTiCb4AWzwiaOYp5S0cE4uC64b0kHLQ=7PEA@mail.gmail.com>
On Thu, 2019-04-25 at 13:05 +0300, Janne Karhunen wrote:
> Hi,
> Finally. Now I think I'm almost happy with the overall construction
> and my gut feeling is telling me I can make the hashes reflect the
> filesystem state pretty well, maybe even over 99.9% of the time given
> the workload stock android is generating.
>
> The pieces that we did:
> - initialize hashes correctly on open()
> - hook 'sync'
> - hook 'msync'
> - hook 'truncate'
> - introduce a per-cpu workqueue that gets work items from write and
> dirty page flush. Long-running write is allowed to go as is (no
> performance penalty from re-measurements), but once the the write goes
> silent workqueue item is flushed and the file is hashed.
What type of workqueue (eg. fifo)? Are all of the writes needed, as
they might be re-written later.
>
> Before I uplift this construction against the mainline, any thoughts
> about this? All I can say so far is that it runs and it seems to keep
> the system relatively crash tolerant. 'Don't let the perfect be the
> enemy of the better' I guess...
As long as the iint cache info isn't affected by these changes, the
change is limited to writing out the xattr more frequently. If the
iint cache info is affected, then you need to be careful that multiple
readers/writers continue to work.
Mimi
next prev parent reply other threads:[~2019-04-25 12:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 14:56 [PATCH] integrity: make 'sync' update the inode integrity state Janne Karhunen
2019-04-11 13:03 ` Mimi Zohar
2019-04-11 14:10 ` Janne Karhunen
[not found] ` <CAE=NcraxAJum=Uk77BoPXVkBDk3rwmXh80mLxy6pxrtUW_hpQg@mail.gmail.com>
[not found] ` <1556805843.4134.15.camel@linux.ibm.com>
[not found] ` <CAE=Ncrb4unTxeU=2jLb-KTqKXpK98vGFbrOxdcnjdfD_Ddk8ug@mail.gmail.com>
[not found] ` <1556884105.4754.18.camel@linux.ibm.com>
2019-05-06 13:17 ` Janne Karhunen
2019-05-07 12:42 ` Janne Karhunen
2019-04-12 12:40 ` Janne Karhunen
2019-04-25 10:05 ` Janne Karhunen
2019-04-25 12:14 ` Mimi Zohar [this message]
2019-04-25 12:46 ` Janne Karhunen
2019-05-03 11:48 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1556194447.3894.105.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=janne.karhunen@gmail.com \
--cc=linux-integrity@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).