On Thu, 2009-08-06 at 13:58 +0100, Alan Cox wrote: > > > We are taking about the kind of fanotify client that says: No you cannot > > > open/read/write/mmap/etc.. this file until I say you can, right? > > > > Yes and no, it would be more accurate to say "this open takes long while we do > > something else in the background". > > There are two or three ways to handle this > > 1. Block the open until the daemon dies or responds > 2. Have a timeout (which would need to be connection configurable) > 3. Require the daemon responds with "in progress" now and then. I've taken option #3. I don't see options #2 as viable, although off list discussion from clamav people has said they believe they are interested in #2 rather than #3. > For a superuser managed service its no different to an NFS mount which > can go wonky so the only real question is what should fanotify allow non > privileged users to do. The answer would appear anyway to be: not use > this aspect of such a facility. That's the approach taken thus far. Although non-blocking/access notification will be opened up to normal users (currently even notification is root only) > For the superuser case the fact the daemon can be killed thus releasing > anything stuff is analogous to umount -f of a stuck NFS mount which seems > perfectly good for NFS. It does work for NFS (which I would call case #1.) I claim that it doesn't work for this case since a global listener stuck would stop you from running kill() since it owuldn't be able to get permission to open it.... -- 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
