On 14/08/12 10:31, Florian Westphal wrote:
Douglas Leeder <douglas.leeder@xxxxxxxxxx> wrote:
So as, I sent later, making fanotify only return one file event per fanotify read(), So that suggests that the request is getting stuck in a cycle or adding a request.
Florian has also been looking at this problem, and has pointed out that FMODE_NONOTIFY should prevent the loop seen in the backtrace, so I'm wondering if it's getting lost somewhere in ecryptfs. Or perhaps it needs to be explicitly propagated to the open request for the lower file?
Douglas, can you reproduce the problem with this patch applied?
diff --git a/fs/ecryptfs/kthread.c b/fs/ecryptfs/kthread.c
index 809e67d..1d8a53b 100644
--- a/fs/ecryptfs/kthread.c
+++ b/fs/ecryptfs/kthread.c
@@ -74,7 +74,7 @@ static int ecryptfs_threadfn(void *ignored)
kthread_ctl_list);
list_del(&req->kthread_ctl_list);
*req->lower_file = dentry_open(&req->path,
- (O_RDWR | O_LARGEFILE), current_cred());
+ (O_RDWR | O_LARGEFILE | FMODE_NONOTIFY), current_cred());
complete(&req->done);
}
mutex_unlock(&ecryptfs_kthread_ctl.mux);
@@ -133,7 +133,7 @@ int ecryptfs_privileged_open(struct file **lower_file,
const struct cred *cred)
{
struct ecryptfs_open_req req;
- int flags = O_LARGEFILE;
+ int flags = O_LARGEFILE|FMODE_NONOTIFY;
int rc = 0;
init_completion(&req.done);
That patch also seems to fix the problem - at least for AV scanning:
1) The encrypted files don't show up in the user-space test program.
2) Using the FanotifyMultiThreadScanner (old) from the git tree doesn't
lock up. (With the single event read() patch removed for the moment).
However I don't think this is a sufficient solution for general fanotify.
For example an HSM may need to get the fanotify event to restore the
encrypted file to disk.
Or a file-access recorder (e.g. http://www.piware.de/tag/fanotify/ )
will want all the accesses, including those 'generated' by the
fanotify_read() call itself.
Talpa, in this case, has it easier, since it is only used for AV, it can
ignore any accesses that it's caused.
What we might be able to do is set FMODE_NONOTIFY for the lower access
if the upper access had it set? Since HSM and fatrace don't want to
access the contents when they intercept.
I guess HSM and fatrace might not intercept ecryptfs mounts anyway,
since they don't directly access the disk?
--
Douglas Leeder, Senior Software Engineer
________________________________
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
