Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes
Jan Kara : > On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: >> As for "who (user/process/...) did what", the fanotify API is flawed >> in that we don't have a CLOSE_WRITE_PERM event. The hit-and-run >> process is long gone by the time we receive the event. That's more of >> a rule than an exception. > > Adding CLOSE_WRITE_PERM would not be that difficult I assume. What do you > need it for? Mainly to hold the process hostage until I have verified the content change. If I disqualify the content change, I will need to report on the process. CLOSE_WRITE only gives me a pid that is often stale as it doesn't block the process. (Another possibility would be to keep the process around as a zombie as long as the CLOSE_WRITE event's file descriptor is open. That sounds more complicated and questionable, though.) Marko -- +358 44 990 4795 Skype: marko.rauhamaa_f-secure
Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes
Filip Štědronský : > there are basically two classes of uses for a fantotify-like > interface: > > (1) Keeping an up-to-date representation of the file system. For this, > superblock watches are clearly what you want. > > [...] > > All those factors speak greatly in favour of superblock > watches. > > (2) Tracking filesystem *activity*. Now you are not building > an image of current filesystem state but rather a log of what > happened. Perhaps you are also interested in who > (user/process/...) did what. Permission events also fit mostly in > this category. > > For those it *might* make sense to have mount-scoped watches, for > example if you want to monitor only one container or a subset of > processes. > > We both concentrate on the first but we shouldn't forget about the > second, which was one of the original motivations for fanotify. My (employer's) needs are centered around (2). We definitely crave permission events with a filesystem scope. At the moment, you can avoid permission checks with a simple unshare command (https://lkml.org/lkml/2016/12/21/144>). So I must be able to see everything that is happening in my universe. It might also be useful to monitor a subuniverse of mine, but the former need is critical at the moment. As for "who (user/process/...) did what", the fanotify API is flawed in that we don't have a CLOSE_WRITE_PERM event. The hit-and-run process is long gone by the time we receive the event. That's more of a rule than an exception. Marko
Re: [RFC][PATCH 0/2] fsnotify: super block watch
Amir Goldstein : > On the Oct 10 posting you asked me about the use case and it was hard > to explain the use case with only part of the work done. > > The issue, which this work sets to solve, is the poor scalability of > recursive inotify watches. On my [employer's] part, the fanotify API suffers from leakage through namespaces. If you need to monitor files in a filesystem, the current fanotify FAN_MARK_MOUNT flag does not give you a notification if you execute a command like unshare -m touch xyz inside the file system. Amir's patch addresses this increasingly critical issue. Marko
fanotify and namespaces/bind mounts
If I call fanotify_mark(... FAN_MARK_ADD | FAN_MARK_MOUNT ...), I get notifications on all files on the file system. Except I don't. If a process has mounted directories on the file system in a different namespace, the global namespace experiences file system events but no fanotify events are generated. A similar limitation applies to bind mounts. You can easily see this behavior in action. Do "man fanotify", and copy the example program to, say, example.c. Then, cc -o example example.c mkdir -p /mnt/xyz mount -o bind /root /mnt/xyz ./example /root The last command prints out fanotify events. It will display events for touch /root/xyzzy but nothing for touch /mnt/xyz/zyxxy or unshare -m touch /root/yxyyx Should the current situation be considered a bug in fanotify? Or is there another recommended way to monitor file system events categorigally? Marko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is the clockevent resolution fine-grained enough?
Thomas Gleixner <[EMAIL PROTECTED]>:
> 100khz on a stock kernel with real world hardware:
>
> ROTFL, You made my day.
I don't know why you find that rate unbelievable.
> Sorry man. Did you actually read what I wrote ?
>
> > The clockevent subsystem operates on absolute time, so there is no
> > cummulative error
You are right. I misunderstood what you meant by "absolute time".
> timer_function()
> {
> do_whatever_you_need_to_do();
>
> next_event += interval;
> set_next_event(yokto_seconds_to_nsec(next_event), ABSOLUTE);
> }
>
> Please read _AND_ understand the clockevents code. Your uber_clockevents
> patch is solving PEBKAC.
I tried to quickly reconstruct the API from a recent clockevent patch I
found with google (http://www.mail-archive.com/mm-commits@vger.kernel.org/msg09566.html>).
I saw the enum "CLOCK_EVT_MODE_PERIODIC" and automatically thought of
using that since my application is periodic. I imagined you wouldn't
have to keep on ordering the notification again in every callback. It's
also difficult to estimate how expensive an operation the explicit
rearming would be in the clock event device (the periodic notifications
can probably be optimized effectively).
You are right. By calling set_next_event() in every callback I can
implement what I want (provided that the API guarantees that the
absolute time can be in the past).
Marko
--
Marko Rauhamaa mailto:[EMAIL PROTECTED] http://pacujo.net/marko/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is the clockevent resolution fine-grained enough?
Thomas Gleixner <[EMAIL PROTECTED]>: > On Thu, 2007-03-01 at 18:34 -0800, Marko Rauhamaa wrote: > > It would appear the new clockevent API has a one-nanosecond > > resolution. It certainly looks sufficiently fine-grained, but I'm > > afraid it's too coarse for some applications. > > That's an academic exercise, or are you talking about some real world > hardware which runs Linux ? Real hardware running linux. > > In our application, we need periodic clock interrupts at about 100 > > kHz. > > With a stock kernel ? Well, with a "clockevent" patch of our own. We'd like to use a stock kernel, though. > > If the (programmable) frequency must be rounded to the nearest > > nanosecond, we have a cumulative error of > > > >100,000 * 0.5 ns/s = 50 µs/s > > clockevents is based on the monotonic system clock and depends on the > accuracy of that and the device which deliveres the interrupts. > [...] > There is nothing to nugde. The clockevent subsystem operates on > absolute time, so there is no cummulative error, except you setup your > timers relative per event. I'm afraid you didn't quite understand what I was getting at. Say the user programs the frequency to be 109,000 Hz. That means a nominal clock interval of ~9174.3119 ns. Now the clockevent interface forces me to round it down to 9174 ns. That means the clock interrupts fall behind with respect to the other parts in the system that implement 109,000 Hz much more to the letter. The error grows by 34 µs every second so that after 8 hours, we are lagging by a whole second. Marko -- Marko Rauhamaa mailto:[EMAIL PROTECTED] http://pacujo.net/marko/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is the clockevent resolution fine-grained enough?
It would appear the new clockevent API has a one-nanosecond resolution. It certainly looks sufficiently fine-grained, but I'm afraid it's too coarse for some applications. In our application, we need periodic clock interrupts at about 100 kHz. If the (programmable) frequency must be rounded to the nearest nanosecond, we have a cumulative error of 100,000 * 0.5 ns/s = 50 µs/s We need to maintain the cumulative error within, say, 1 ms/day, or 11 ns/s. (The error is not measured against real time, but between different parts of our hardware that are run off of the same clock.) For our needs, we have built our own "clockevent" system that has a nominal one-femtosecond precision. The nanosecond resolution would be sufficient if there was a way to "nudge" the next interrupt by a nanosecond from the interrupt handler. Marko -- Marko Rauhamaa mailto:[EMAIL PROTECTED] http://pacujo.net/marko/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
