Re: [patch] inotify for 2.6.11
Robert Love wrote: > Below is inotify, diffed against 2.6.11. > > I greatly reworked much of the data structures and their interactions, > to lay the groundwork for sanitizing the locking. I then, I hope, > sanitized the locking. It looks right, I am happy. Comments welcome. > I surely could of missed something. Maybe even something big. > > But, regardless, this release is a huge jump from the previous, fixing > all known issues and greatly improving the locking. > Inotify 0.22 severly destabilized my 2.6.11 system when it was in use. The system would get into a state where it was unable to spawn new processes, the desktop would hang, and the only way to shut down would be to do a hard reset. This only happened when inotify was in use after gamin started up. I was only able to get the following out of the logs(not every time though): c017b901 Modules linked in: radeon deflate zlib_deflate twofish serpent aes_i586 blowfish sha256 sha1 crypto_null af_key parport_pc lp parport 8250_pci 8250 serial_core usbhid ohci_hcd ohci1394 ieee1394 yenta_socket rsrc_nonstatic suspend_text CPU:0 EIP:0060:[inotify_ignore+49/224]Not tainted VLI EFLAGS: 00010246 (2.6.11.6-nx9005) EIP is at inotify_ignore+0x31/0xe0 eax: ebx: e88544e0 ecx: edx: esi: edi: e88544e0 ebp: e876 esp: e8761f20 ds: 007b es: 007b ss: 0068 Process gam_server (pid: 6640, threadinfo=e876 task=ed19e060) Stack: e88544e8 00f6 e88544e0 fff2 fff7 c017bace e88544e0 00f6 0004 00f6 0292 08098e54 80045102 fff7 c01685a8 e5d584c0 80045102 08098e54 c0456118 e5d584c0 c0168785 e5d584c0 Call Trace: [inotify_ioctl+286/288] inotify_ioctl+0x11e/0x120 [do_ioctl+104/128] do_ioctl+0x68/0x80 [vfs_ioctl+101/464] vfs_ioctl+0x65/0x1d0 [sys_ioctl+69/144] sys_ioctl+0x45/0x90 [syscall_call+7/11] syscall_call+0x7/0xb Code: 10 89 5c 24 08 89 74 24 0c 8b 7c 24 18 ff 4f 28 0f 88 95 03 00 00 8b 44 24 1c 89 44 24 04 8d 47 08 89 04 24 e8 11 89 0b 00 89 c6 40 10 ff 47 28 0f 8e 81 03 00 00 85 f6 b8 ea ff ff ff 74 6e Thanks. - 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: [patch] inotify for 2.6.11
Robert Love wrote: Below is inotify, diffed against 2.6.11. I greatly reworked much of the data structures and their interactions, to lay the groundwork for sanitizing the locking. I then, I hope, sanitized the locking. It looks right, I am happy. Comments welcome. I surely could of missed something. Maybe even something big. But, regardless, this release is a huge jump from the previous, fixing all known issues and greatly improving the locking. Inotify 0.22 severly destabilized my 2.6.11 system when it was in use. The system would get into a state where it was unable to spawn new processes, the desktop would hang, and the only way to shut down would be to do a hard reset. This only happened when inotify was in use after gamin started up. I was only able to get the following out of the logs(not every time though): c017b901 Modules linked in: radeon deflate zlib_deflate twofish serpent aes_i586 blowfish sha256 sha1 crypto_null af_key parport_pc lp parport 8250_pci 8250 serial_core usbhid ohci_hcd ohci1394 ieee1394 yenta_socket rsrc_nonstatic suspend_text CPU:0 EIP:0060:[inotify_ignore+49/224]Not tainted VLI EFLAGS: 00010246 (2.6.11.6-nx9005) EIP is at inotify_ignore+0x31/0xe0 eax: ebx: e88544e0 ecx: edx: esi: edi: e88544e0 ebp: e876 esp: e8761f20 ds: 007b es: 007b ss: 0068 Process gam_server (pid: 6640, threadinfo=e876 task=ed19e060) Stack: e88544e8 00f6 e88544e0 fff2 fff7 c017bace e88544e0 00f6 0004 00f6 0292 08098e54 80045102 fff7 c01685a8 e5d584c0 80045102 08098e54 c0456118 e5d584c0 c0168785 e5d584c0 Call Trace: [inotify_ioctl+286/288] inotify_ioctl+0x11e/0x120 [do_ioctl+104/128] do_ioctl+0x68/0x80 [vfs_ioctl+101/464] vfs_ioctl+0x65/0x1d0 [sys_ioctl+69/144] sys_ioctl+0x45/0x90 [syscall_call+7/11] syscall_call+0x7/0xb Code: 10 89 5c 24 08 89 74 24 0c 8b 7c 24 18 ff 4f 28 0f 88 95 03 00 00 8b 44 24 1c 89 44 24 04 8d 47 08 89 04 24 e8 11 89 0b 00 89 c6 ff 40 10 ff 47 28 0f 8e 81 03 00 00 85 f6 b8 ea ff ff ff 74 6e Thanks. - 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: [patch] inotify for 2.6.11
On Thu, 2005-04-07 at 18:37 -0700, Rusty Lynch wrote: > Looking into this a little more I realized that the lack of /proc > notifications (for processes coming and going) is a common problem anytime > a file is modified without going through the VFS. Other examples are > remote file changes on a mounted NFS partition, remote file changes on a > mounted cluster filesystem (like ocfs or gfs), and just about any virtual > file system where the kernel is adding/deleting/modifying files from below > the VFS. Indeed it is. But none of those are anything that we care about (except maybe /proc). The problem of changes on remote filesystems is solved by FAM. Robert Love - 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: [patch] inotify for 2.6.11
On Thu, 2005-04-07 at 18:37 -0700, Rusty Lynch wrote: Looking into this a little more I realized that the lack of /proc notifications (for processes coming and going) is a common problem anytime a file is modified without going through the VFS. Other examples are remote file changes on a mounted NFS partition, remote file changes on a mounted cluster filesystem (like ocfs or gfs), and just about any virtual file system where the kernel is adding/deleting/modifying files from below the VFS. Indeed it is. But none of those are anything that we care about (except maybe /proc). The problem of changes on remote filesystems is solved by FAM. Robert Love - 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: [patch] inotify for 2.6.11
I've been meaning to play with inotify for a while now and finally made
time for it tonight. I'm not much of a GUI guy, so I'm mostly interested
in exploring the command line applications of inotify --i.e., what sort of
havoc can I wreak with it in a script.
To that end I sat down tonight a threw together a simple command line
interface. Before I tell you where the code is, please note that I wrote
it while half asleep and more than a little high on cough syrup, so it's
undoubtedly chock full of buffer overflows, infinite loops, segfaults,
and other gremlins just waiting to eat your data, so PLEASE FOR THE LOVE
OF MIKE don't use it on, around, under, or in the general vicinity of,
anything important.
http://www.kroptech.com/~adk0212/watchf.c
The basic usage is...
watchf [-i] [-e] [-- ...>]
-i says stay in an infinite loop, don't exit after one event
-e gives the list of events to wait for (see the code)
is the file or directory to be watched
Everything after -- is taken as a command to run each time an
event ocurrs with any ocurrences of {} being replaced with the
name of the affected file, as returned in the inotify_event
structure.
So what's it good for? Well, besides making fun of my coding skills,
it can be used to watch a directory and run a command when something
changes. For example, a one-line auto-gzip daemon that will haul off and
gzip anything you drop into ./gzipme:
watchf -i -eWT gzipme -- gzip gzipme/{}
Where to go from here? The code is relatively half-baked at the moment,
but I imgaine this could be turned into a relatively useful generic
tool. For example, it should send the filename to stdout and return the
event mask when in single-shot mode. That would make it useful as part
of a longer pipeline. You should be able to use it to wait for a specific
file to be created --although that will be interesting if one or more
segments of the path don't exist yet. Ultimately I'd like to get rid of
the argument(s), but I can't think of any way to do it
that isn't going to end up missing events.
--Adam
-
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: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 17:53 -0700, Rusty Lynch wrote: > From just a casual look, it seems like this could be used to monitor the > comings and goings of processes by monitoring /proc. Unfortunately > inotify doesn't seem to be getting all the events on the proc filesystem > like it does on a real filesystem because I am not seeing new events every > time a new process is added or removed. The same is true if you attempt > to monitor something like /sys/bus/usb/devices/ and add/remove a usb > device. > > On a side note, it's still rather interesting to monitor /proc and watch > all the traffic. Yah, I agree. I looked into doing this awhile back, when I noticed inotify did not generate events for /proc. We just need to add calls to the fsnotify hooks to the proc_create() and proc_delete_foo() stuff. The interfaces are capable, e.g. we can add support at anytime, even after inotify is merged. I'd be for it. Robert Love - 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: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote: > BTW, what else could I use to make use of inotify? I know fam, which afaik > only uses dnotify. Here is a little sample glib application that shows the ease-yet-power of inotify. http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/ It integrates inotify watches into the glib mainloop via GIOChannel. Everything is abstracted behind simple interfaces, so this might prove a nice start for curious inotify developers. Robert Love - 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: [patch] inotify for 2.6.11
Robert Love schrieb: > On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote: > >>I am having a little trouble with inotify 0.22. Previous version worked w/o >>trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin >> >>Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of >>uptime (compiling some stuff): > > > Ah, thanks. That was not even related to the semaphore rewrite, but a > small bug fix I slipped in. But of course. > > Gamin is an interesting test case for us because it does so many > ignores. BTW, what else could I use to make use of inotify? I know fam, which afaik only uses dnotify. > Anyhow, this should fix it. Confirm? So far no problems. Interesting enough the previous patch worked w/o problem the last hours... Cheers -- Prakash Punnoor signature.asc Description: OpenPGP digital signature
Re: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote: > BTW, what else could I use to make use of inotify? I know fam, which afaik > only uses dnotify. Beagle, a desktop search infrastructure. Check out http://www.gnome.org/projects/beagle Some other little projects. If anyone else is using it, please let us know! The main problem is that dnotify sucks so bad now that no one uses it. So we don't have any existing applications to convert, besides FAM, and we did that (via Gamin). I've been meaning to write some sample GNOME code to show how easy it is to use Inotify, even directly. I'll get on that. > > Anyhow, this should fix it. Confirm? > > So far no problems. Interesting enough the previous patch worked w/o problem > the last hours... It might of been caused by a bug in Gamin, so it took some while to expose. It should only happen when the user asks to remove a watch on a wd that does not exist (I just forgot to check that error case in a bug fix I added). Keep pounding. It ought to be fixed, but please let me know if not! Robert Love - 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: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote:
> I am having a little trouble with inotify 0.22. Previous version worked w/o
> trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
>
> Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of
> uptime (compiling some stuff):
Ah, thanks. That was not even related to the semaphore rewrite, but a
small bug fix I slipped in. But of course.
Gamin is an interesting test case for us because it does so many
ignores.
Anyhow, this should fix it. Confirm?
Thanks,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
Documentation/filesystems/inotify.txt | 81 ++
fs/Kconfig| 13
fs/Makefile |1
fs/attr.c | 33 -
fs/compat.c | 12
fs/file_table.c |3
fs/inode.c|6
fs/inotify.c | 961 ++
fs/namei.c| 30 -
fs/open.c |6
fs/read_write.c | 15
include/linux/fs.h|6
include/linux/fsnotify.h | 228
include/linux/inotify.h | 111 +++
include/linux/sched.h |4
kernel/user.c |4
16 files changed, 1458 insertions(+), 56 deletions(-)
diff -urN linux-2.6.12-rc1/Documentation/filesystems/inotify.txt
linux/Documentation/filesystems/inotify.txt
--- linux-2.6.12-rc1/Documentation/filesystems/inotify.txt 1969-12-31
19:00:00.0 -0500
+++ linux/Documentation/filesystems/inotify.txt 2005-04-04 16:26:15.0
-0400
@@ -0,0 +1,81 @@
+ inotify
+a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love <[EMAIL PROTECTED]>
+
+(i) User Interface
+
+Inotify is controlled by a device node, /dev/inotify. If you do not use udev,
+this device may need to be created manually. First step, open it
+
+ int dev_fd = open ("/dev/inotify", O_RDONLY);
+
+Change events are managed by "watches". A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bitmask of one or more
+inotify events that the application wishes to receive. See
+for valid events. A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a file descriptor.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple,
+
+ /* 'wd' represents the watch on fd with mask */
+ struct inotify_request req = { fd, mask };
+ int wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+You can add a large number of files via something like
+
+ for each file to watch {
+ struct inotify_request req;
+ int file_fd;
+
+ file_fd = open (file, O_RDONLY);
+ if (fd < 0) {
+ perror ("open");
+ break;
+ }
+
+ req.fd = file_fd;
+ req.mask = mask;
+
+ wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+ close (fd);
+ }
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
+
+ ioctl (dev_fd, INOTIFY_IGNORE, wd);
+
+Events are provided in the form of an inotify_event structure that is read(2)
+from /dev/inotify. The filename is of dynamic length and follows the struct.
+It is of size len. The filename is padded with null bytes to ensure proper
+alignment. This padding is reflected in len.
+
+You can slurp multiple events by
Re: [patch] inotify for 2.6.11
Hi, I am having a little trouble with inotify 0.22. Previous version worked w/o trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of uptime (compiling some stuff): Apr 5 09:40:43 tachyon Unable to handle kernel NULL pointer dereference at virtual address 0010 Apr 5 09:40:43 tachyon printing eip: Apr 5 09:40:43 tachyon b0181d83 Apr 5 09:40:43 tachyon *pde = Apr 5 09:40:43 tachyon Oops: 0002 [#1] Apr 5 09:40:43 tachyon PREEMPT Apr 5 09:40:43 tachyon Modules linked in: nvidia nvsound Apr 5 09:40:43 tachyon CPU:0 Apr 5 09:40:43 tachyon EIP:0060:[]Tainted: P VLI Apr 5 09:40:43 tachyon EFLAGS: 00210286 (2.6.12-rc2) Apr 5 09:40:43 tachyon EIP is at inotify_ignore+0x23/0xd0 Apr 5 09:40:43 tachyon eax: ebx: b998ce60 ecx: edx: Apr 5 09:40:43 tachyon esi: edi: b998ce60 ebp: 80045102 esp: b336bf48 Apr 5 09:40:43 tachyon ds: 007b es: 007b ss: 0068 Apr 5 09:40:43 tachyon Process gam_server (pid: 4144, threadinfo=b336a000 task=ccf84aa0) Apr 5 09:40:43 tachyon Stack: b998ce60 b998ce98 08062484 b0181ebf b336bf78 b336bf74 003e b0181e30 Apr 5 09:40:43 tachyon c1168b00 08062484 80045102 b016c40b c1168b00 c1168b00 0003 Apr 5 09:40:43 tachyon b336a000 b016c640 080623d8 c1168b00 0003 fff7 b336a000 Apr 5 09:40:43 tachyon Call Trace: Apr 5 09:40:43 tachyon [] inotify_ioctl+0x8f/0xd0 Apr 5 09:40:43 tachyon [] inotify_ioctl+0x0/0xd0 Apr 5 09:40:43 tachyon [] do_ioctl+0x2b/0xa0 Apr 5 09:40:43 tachyon [] vfs_ioctl+0x60/0x210 Apr 5 09:40:43 tachyon [] sys_ioctl+0x3d/0x70 Apr 5 09:40:43 tachyon [] sysenter_past_esp+0x54/0x75 Apr 5 09:40:43 tachyon Code: 89 58 20 eb c2 8d 76 00 83 ec 0c 89 7c 24 08 89 1c 24 89 c7 89 74 24 04 ff 4f 28 0f 88 2b 03 00 00 8d 47 08 e8 ef f9 12 00 89 c6 40 10 ff 47 28 0f 8e 22 03 00 00 85 f6 ba ea ff ff ff 74 65 Cheers, Prakash signature.asc Description: OpenPGP digital signature
Re: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote: BTW, what else could I use to make use of inotify? I know fam, which afaik only uses dnotify. Beagle, a desktop search infrastructure. Check out http://www.gnome.org/projects/beagle Some other little projects. If anyone else is using it, please let us know! The main problem is that dnotify sucks so bad now that no one uses it. So we don't have any existing applications to convert, besides FAM, and we did that (via Gamin). I've been meaning to write some sample GNOME code to show how easy it is to use Inotify, even directly. I'll get on that. Anyhow, this should fix it. Confirm? So far no problems. Interesting enough the previous patch worked w/o problem the last hours... It might of been caused by a bug in Gamin, so it took some while to expose. It should only happen when the user asks to remove a watch on a wd that does not exist (I just forgot to check that error case in a bug fix I added). Keep pounding. It ought to be fixed, but please let me know if not! Robert Love - 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: [patch] inotify for 2.6.11
Robert Love schrieb: On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote: I am having a little trouble with inotify 0.22. Previous version worked w/o trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of uptime (compiling some stuff): Ah, thanks. That was not even related to the semaphore rewrite, but a small bug fix I slipped in. But of course. Gamin is an interesting test case for us because it does so many ignores. BTW, what else could I use to make use of inotify? I know fam, which afaik only uses dnotify. Anyhow, this should fix it. Confirm? So far no problems. Interesting enough the previous patch worked w/o problem the last hours... Cheers -- Prakash Punnoor signature.asc Description: OpenPGP digital signature
Re: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote: BTW, what else could I use to make use of inotify? I know fam, which afaik only uses dnotify. Here is a little sample glib application that shows the ease-yet-power of inotify. http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/ It integrates inotify watches into the glib mainloop via GIOChannel. Everything is abstracted behind simple interfaces, so this might prove a nice start for curious inotify developers. Robert Love - 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: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 17:53 -0700, Rusty Lynch wrote: From just a casual look, it seems like this could be used to monitor the comings and goings of processes by monitoring /proc. Unfortunately inotify doesn't seem to be getting all the events on the proc filesystem like it does on a real filesystem because I am not seeing new events every time a new process is added or removed. The same is true if you attempt to monitor something like /sys/bus/usb/devices/ and add/remove a usb device. On a side note, it's still rather interesting to monitor /proc and watch all the traffic. Yah, I agree. I looked into doing this awhile back, when I noticed inotify did not generate events for /proc. We just need to add calls to the fsnotify hooks to the proc_create() and proc_delete_foo() stuff. The interfaces are capable, e.g. we can add support at anytime, even after inotify is merged. I'd be for it. Robert Love - 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: [patch] inotify for 2.6.11
I've been meaning to play with inotify for a while now and finally made
time for it tonight. I'm not much of a GUI guy, so I'm mostly interested
in exploring the command line applications of inotify --i.e., what sort of
havoc can I wreak with it in a script.
To that end I sat down tonight a threw together a simple command line
interface. Before I tell you where the code is, please note that I wrote
it while half asleep and more than a little high on cough syrup, so it's
undoubtedly chock full of buffer overflows, infinite loops, segfaults,
and other gremlins just waiting to eat your data, so PLEASE FOR THE LOVE
OF MIKE don't use it on, around, under, or in the general vicinity of,
anything important.
http://www.kroptech.com/~adk0212/watchf.c
The basic usage is...
watchf [-i] [-eevents] file-to-watch [-- command-to-run...]
-i says stay in an infinite loop, don't exit after one event
-e gives the list of events to wait for (see the code)
file-to-watch is the file or directory to be watched
Everything after -- is taken as a command to run each time an
event ocurrs with any ocurrences of {} being replaced with the
name of the affected file, as returned in the inotify_event
structure.
So what's it good for? Well, besides making fun of my coding skills,
it can be used to watch a directory and run a command when something
changes. For example, a one-line auto-gzip daemon that will haul off and
gzip anything you drop into ./gzipme:
watchf -i -eWT gzipme -- gzip gzipme/{}
Where to go from here? The code is relatively half-baked at the moment,
but I imgaine this could be turned into a relatively useful generic
tool. For example, it should send the filename to stdout and return the
event mask when in single-shot mode. That would make it useful as part
of a longer pipeline. You should be able to use it to wait for a specific
file to be created --although that will be interesting if one or more
segments of the path don't exist yet. Ultimately I'd like to get rid of
the command-to-run argument(s), but I can't think of any way to do it
that isn't going to end up missing events.
--Adam
-
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: [patch] inotify for 2.6.11
Hi, I am having a little trouble with inotify 0.22. Previous version worked w/o trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of uptime (compiling some stuff): Apr 5 09:40:43 tachyon Unable to handle kernel NULL pointer dereference at virtual address 0010 Apr 5 09:40:43 tachyon printing eip: Apr 5 09:40:43 tachyon b0181d83 Apr 5 09:40:43 tachyon *pde = Apr 5 09:40:43 tachyon Oops: 0002 [#1] Apr 5 09:40:43 tachyon PREEMPT Apr 5 09:40:43 tachyon Modules linked in: nvidia nvsound Apr 5 09:40:43 tachyon CPU:0 Apr 5 09:40:43 tachyon EIP:0060:[b0181d83]Tainted: P VLI Apr 5 09:40:43 tachyon EFLAGS: 00210286 (2.6.12-rc2) Apr 5 09:40:43 tachyon EIP is at inotify_ignore+0x23/0xd0 Apr 5 09:40:43 tachyon eax: ebx: b998ce60 ecx: edx: Apr 5 09:40:43 tachyon esi: edi: b998ce60 ebp: 80045102 esp: b336bf48 Apr 5 09:40:43 tachyon ds: 007b es: 007b ss: 0068 Apr 5 09:40:43 tachyon Process gam_server (pid: 4144, threadinfo=b336a000 task=ccf84aa0) Apr 5 09:40:43 tachyon Stack: b998ce60 b998ce98 08062484 b0181ebf b336bf78 b336bf74 003e b0181e30 Apr 5 09:40:43 tachyon c1168b00 08062484 80045102 b016c40b c1168b00 c1168b00 0003 Apr 5 09:40:43 tachyon b336a000 b016c640 080623d8 c1168b00 0003 fff7 b336a000 Apr 5 09:40:43 tachyon Call Trace: Apr 5 09:40:43 tachyon [b0181ebf] inotify_ioctl+0x8f/0xd0 Apr 5 09:40:43 tachyon [b0181e30] inotify_ioctl+0x0/0xd0 Apr 5 09:40:43 tachyon [b016c40b] do_ioctl+0x2b/0xa0 Apr 5 09:40:43 tachyon [b016c640] vfs_ioctl+0x60/0x210 Apr 5 09:40:43 tachyon [b016c82d] sys_ioctl+0x3d/0x70 Apr 5 09:40:43 tachyon [b0103127] sysenter_past_esp+0x54/0x75 Apr 5 09:40:43 tachyon Code: 89 58 20 eb c2 8d 76 00 83 ec 0c 89 7c 24 08 89 1c 24 89 c7 89 74 24 04 ff 4f 28 0f 88 2b 03 00 00 8d 47 08 e8 ef f9 12 00 89 c6 ff 40 10 ff 47 28 0f 8e 22 03 00 00 85 f6 ba ea ff ff ff 74 65 Cheers, Prakash signature.asc Description: OpenPGP digital signature
Re: [patch] inotify for 2.6.11
On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote:
I am having a little trouble with inotify 0.22. Previous version worked w/o
trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of
uptime (compiling some stuff):
Ah, thanks. That was not even related to the semaphore rewrite, but a
small bug fix I slipped in. But of course.
Gamin is an interesting test case for us because it does so many
ignores.
Anyhow, this should fix it. Confirm?
Thanks,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
Documentation/filesystems/inotify.txt | 81 ++
fs/Kconfig| 13
fs/Makefile |1
fs/attr.c | 33 -
fs/compat.c | 12
fs/file_table.c |3
fs/inode.c|6
fs/inotify.c | 961 ++
fs/namei.c| 30 -
fs/open.c |6
fs/read_write.c | 15
include/linux/fs.h|6
include/linux/fsnotify.h | 228
include/linux/inotify.h | 111 +++
include/linux/sched.h |4
kernel/user.c |4
16 files changed, 1458 insertions(+), 56 deletions(-)
diff -urN linux-2.6.12-rc1/Documentation/filesystems/inotify.txt
linux/Documentation/filesystems/inotify.txt
--- linux-2.6.12-rc1/Documentation/filesystems/inotify.txt 1969-12-31
19:00:00.0 -0500
+++ linux/Documentation/filesystems/inotify.txt 2005-04-04 16:26:15.0
-0400
@@ -0,0 +1,81 @@
+ inotify
+a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love [EMAIL PROTECTED]
+
+(i) User Interface
+
+Inotify is controlled by a device node, /dev/inotify. If you do not use udev,
+this device may need to be created manually. First step, open it
+
+ int dev_fd = open (/dev/inotify, O_RDONLY);
+
+Change events are managed by watches. A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bitmask of one or more
+inotify events that the application wishes to receive. See linux/inotify.h
+for valid events. A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a file descriptor.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple,
+
+ /* 'wd' represents the watch on fd with mask */
+ struct inotify_request req = { fd, mask };
+ int wd = ioctl (dev_fd, INOTIFY_WATCH, req);
+
+You can add a large number of files via something like
+
+ for each file to watch {
+ struct inotify_request req;
+ int file_fd;
+
+ file_fd = open (file, O_RDONLY);
+ if (fd 0) {
+ perror (open);
+ break;
+ }
+
+ req.fd = file_fd;
+ req.mask = mask;
+
+ wd = ioctl (dev_fd, INOTIFY_WATCH, req);
+
+ close (fd);
+ }
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
+
+ ioctl (dev_fd, INOTIFY_IGNORE, wd);
+
+Events are provided in the form of an inotify_event structure that is read(2)
+from /dev/inotify. The filename is of dynamic length and follows the struct.
+It is of size len. The filename is padded with null bytes to ensure proper
+alignment. This padding is reflected in len.
+
+You can slurp multiple events by
Re: [patch] inotify for 2.6.11-mm1, updated
On Mon, 2005-03-07 at 23:50 -0500, Robert Love wrote:
> Yah, I just missed it. It is fixed in my tree.
Following patch, against 2.6.11-mm1, fixes the hooks in fs/compat.c.
Otherwise unchanged from the previous patch.
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
fs/Kconfig | 13
fs/Makefile |1
fs/attr.c| 33 -
fs/compat.c | 12
fs/file_table.c |3
fs/inode.c |4
fs/inotify.c | 1014 +++
fs/namei.c | 30 -
fs/open.c|6
fs/read_write.c | 15
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 236 ++
include/linux/inotify.h | 113 +
include/linux/sched.h|4
kernel/user.c|4
16 files changed, 1442 insertions(+), 56 deletions(-)
diff -urN linux-2.6.11-mm1/fs/attr.c linux/fs/attr.c
--- linux-2.6.11-mm1/fs/attr.c 2005-03-04 14:06:21.0 -0500
+++ linux/fs/attr.c 2005-03-08 12:02:28.216810448 -0500
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid & ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid & ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid & ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid & ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry->d_inode;
@@ -194,11 +171,9 @@
if (ia_valid & ATTR_SIZE)
up_write(>d_inode->i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11-mm1/fs/compat.c linux/fs/compat.c
--- linux-2.6.11-mm1/fs/compat.c2005-03-04 14:06:21.0 -0500
+++ linux/fs/compat.c 2005-03-08 12:02:30.518460544 -0500
@@ -36,7 +36,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -1233,9 +1233,13 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) > 0)
- dnotify_parent(file->f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) > 0) {
+ struct dentry *dentry = file->f_dentry;
+ if (type == READ)
+ fsnotify_access(dentry);
+ else
+ fsnotify_modify(dentry);
+ }
return ret;
}
diff -urN linux-2.6.11-mm1/fs/file_table.c linux/fs/file_table.c
--- linux-2.6.11-mm1/fs/file_table.c2005-03-04 14:06:21.0 -0500
+++ linux/fs/file_table.c 2005-03-08 12:02:28.219809992 -0500
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
/* sysctl tunables... */
struct files_stat_struct files_stat = {
@@ -123,6 +124,8 @@
struct inode *inode = dentry->d_inode;
might_sleep();
+
+ fsnotify_close(file);
/*
Re: [patch] inotify for 2.6.11-mm1, updated
On Mon, 2005-03-07 at 23:50 -0500, Robert Love wrote:
Yah, I just missed it. It is fixed in my tree.
Following patch, against 2.6.11-mm1, fixes the hooks in fs/compat.c.
Otherwise unchanged from the previous patch.
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
fs/Kconfig | 13
fs/Makefile |1
fs/attr.c| 33 -
fs/compat.c | 12
fs/file_table.c |3
fs/inode.c |4
fs/inotify.c | 1014 +++
fs/namei.c | 30 -
fs/open.c|6
fs/read_write.c | 15
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 236 ++
include/linux/inotify.h | 113 +
include/linux/sched.h|4
kernel/user.c|4
16 files changed, 1442 insertions(+), 56 deletions(-)
diff -urN linux-2.6.11-mm1/fs/attr.c linux/fs/attr.c
--- linux-2.6.11-mm1/fs/attr.c 2005-03-04 14:06:21.0 -0500
+++ linux/fs/attr.c 2005-03-08 12:02:28.216810448 -0500
@@ -10,7 +10,7 @@
#include linux/mm.h
#include linux/string.h
#include linux/smp_lock.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/fcntl.h
#include linux/quotaops.h
#include linux/security.h
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry-d_inode;
@@ -194,11 +171,9 @@
if (ia_valid ATTR_SIZE)
up_write(dentry-d_inode-i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11-mm1/fs/compat.c linux/fs/compat.c
--- linux-2.6.11-mm1/fs/compat.c2005-03-04 14:06:21.0 -0500
+++ linux/fs/compat.c 2005-03-08 12:02:30.518460544 -0500
@@ -36,7 +36,7 @@
#include linux/ctype.h
#include linux/module.h
#include linux/dirent.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/highuid.h
#include linux/sunrpc/svc.h
#include linux/nfsd/nfsd.h
@@ -1233,9 +1233,13 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) 0)
- dnotify_parent(file-f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) 0) {
+ struct dentry *dentry = file-f_dentry;
+ if (type == READ)
+ fsnotify_access(dentry);
+ else
+ fsnotify_modify(dentry);
+ }
return ret;
}
diff -urN linux-2.6.11-mm1/fs/file_table.c linux/fs/file_table.c
--- linux-2.6.11-mm1/fs/file_table.c2005-03-04 14:06:21.0 -0500
+++ linux/fs/file_table.c 2005-03-08 12:02:28.219809992 -0500
@@ -16,6 +16,7 @@
#include
Re: [patch] inotify for 2.6.11-mm1, updated
On Tue, 2005-03-08 at 04:40 +, Christoph Hellwig wrote: > Why do you need the classdevice? I'm really not too eager about adding > tons of new misdevices now that we can route directly to individual majors > with cdev_add & stuff. Especially when you're actually relying on class > device you should have your own one instead of relying on an onsolete > layer. We have sysfs knobs and /sys/class/misc/inotify makes sense. > Actually, you fixed that in read_write.c, just compat.c is still missing. > Looks like you forget to fix that one and didn't have a chance to compile-test > the 32bit compat layer? Yah, I just missed it. It is fixed in my tree. Thanks, Robert Love - 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: [patch] inotify for 2.6.11-mm1, updated
> > this one seems totally unrelated.
>
> Eh? We did not add that. ;)
Sorry, I thought I saw a + somewhere there at the beggining of the line,
my fault.
> > Should probably use the /dev/mem major.
>
> Hrm, should we?
>
> Also, the memory class stuff is all local to mem.c. For example, I
> cannot get at /sys/class/mem. The misc. device stuff is exported.
Why do you need the classdevice? I'm really not too eager about adding
tons of new misdevices now that we can route directly to individual majors
with cdev_add & stuff. Especially when you're actually relying on class
device you should have your own one instead of relying on an onsolete
layer.
> > do you really need a spinlock of your own in every inode? Inode memory
> > usage is a quite big problem.
>
> Yah, we do. For a couple of reasons. First, by introducing our own
> lock, we never need touch i_lock, and avoid that scalability mess
> altogether. Second, and most importantly, i_lock is an outermost lock.
> We need our lock to be nestable, because we walk inode -> inotify_watch
> -> inotify_device. I've tried various rewrites to not need our own
> lock. None are pretty.
>
> I can offer to the "inode memory worries me" people that they can always
> disable CONFIG_INOTIFY.
They're bound to use distro kernels unfortunaly.. These people is anyone
doing big-scale fileserving at least.
> + if ((ret + (type == READ)) > 0) {
> + struct dentry *dentry = file->f_dentry;
> + if (type == READ)
> + fsnotify_access(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + else
> + fsnotify_modify(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + }
Arguments two and three are still redudant.
Actually, you fixed that in read_write.c, just compat.c is still missing.
Looks like you forget to fix that one and didn't have a chance to compile-test
the 32bit compat layer?
-
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: [patch] inotify for 2.6.11
On Maandag 07 März 2005 04:13, Albert Cahalan wrote:
> Christoph Hellwig writes:
> > See the review I sent. Write is exactly the right interface for that kind
> > of thing. For comment vs argument either put the number first so we don't
> > have the problem of finding a delinator that isn't a valid filename, or
> > use '\0' as such.
>
> That's just putrid. You've proposed an interface that
> combines the worst of ASCII with the worst of binary.
I guess it's possible to avoid the need for passing the command at all.
The read data already has a format that mixes binary and variable-length
ascii data, so write could use a data structure similar (or even identical)
to the one used there, e.g.
struct inotify_watch_request {
__u32 mask; /* watch mask */
__u32 len; /* length (including nulls) of name */
char name[0]; /* stub for name */
};
This can replace both INOTIFY_WATCH and INOTIFY_IGNORE, if you simply
define a zero mask as a special value for ignore. FIONREAD is a
well-established interface, so I don't think it's necessary to replace
this.
> Adding plain old syscalls is rather nice actually.
> It's only a pain at first, while waiting for glibc
> to catch up.
Yes, that might be a workable interface as well, but don't mix syscalls
with a misc device then. Instead, you might build on something like
futexfs, with syscalls replacing both ioctl and read:
int inotify_open(int flags);
int inotify_watch(int fd, unsigned mask, char *name);
int inotify_ignore(int fd, int wd);
int inotify_getevents(int fd, int max_events, struct inotify_event *);
Arnd <><
-
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/
[patch] inotify for 2.6.11-mm1, updated
On Mon, 2005-03-07 at 01:19 +, Christoph Hellwig wrote:
Hi, hch.
I went ahead and implemented all of your suggestions, save for the ones
below where I have comments or disagree (see below). Most of your
comments were straightforward and I made the changes as you suggested.
See the following patch, against 2.6.11-mm1.
We will try out a write()-based interface. John is working on that.
I'd like Andrew and others to chime in on whether they really prefer
that to an ioctl?
> > might_sleep();
>
> this one seems totally unrelated.
Eh? We did not add that. ;)
> > + /* XXX: optimally, we should use GFP_KERNEL */
> > + kevent = kmem_cache_alloc(event_cachep, GFP_ATOMIC);
>
> indeed. having a new atomic memory allocation in every filesystem operation
> sounds like a really bad idea.
Obviously we know that--the FIXME is there to signify as much. Anyhow,
the allocation is not on every operation, just every event.
> > +static struct miscdevice inotify_device = {
> > + .minor = MISC_DYNAMIC_MINOR,
> > + .name = "inotify",
> > + .fops = _fops,
> > +};
>
> Should probably use the /dev/mem major.
Hrm, should we?
Also, the memory class stuff is all local to mem.c. For example, I
cannot get at /sys/class/mem. The misc. device stuff is exported.
> > + default y
>
> please don't default a new and experimental facility to y. In fact
> default is totally overused.
I'd agree when we go to mainline, but for 2.6-mm more testing is
welcome. Besides, they don't have to use inotify. This just gets the
hooks compiled in.
I will definitely remove 'default' altogether before we go to mainline.
> > +#ifdef CONFIG_INOTIFY
> > + struct list_headinotify_watches; /* watches on this inode */
> > + spinlock_t inotify_lock; /* protects the watches list */
> > +#endif
>
> do you really need a spinlock of your own in every inode? Inode memory
> usage is a quite big problem.
Yah, we do. For a couple of reasons. First, by introducing our own
lock, we never need touch i_lock, and avoid that scalability mess
altogether. Second, and most importantly, i_lock is an outermost lock.
We need our lock to be nestable, because we walk inode -> inotify_watch
-> inotify_device. I've tried various rewrites to not need our own
lock. None are pretty.
I can offer to the "inode memory worries me" people that they can always
disable CONFIG_INOTIFY.
> > +/*
> > + * fsnotify_change - notify_change event. file was modified and/or
> > metadata
> > + * was changed.
> > + */
> > +static inline void fsnotify_change(struct dentry *dentry, unsigned int
> > ia_valid)
>
> this one is far too large to be inlined.
I'd agree, but it is only called from one place. And this way everything
stays in fsnotify.h.
Best,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
fs/Kconfig | 13
fs/Makefile |1
fs/attr.c| 33 -
fs/compat.c | 14
fs/file_table.c |3
fs/inode.c |4
fs/inotify.c | 1014 +++
fs/namei.c | 30 -
fs/open.c|6
fs/read_write.c | 15
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 236 ++
include/linux/inotify.h | 113 +
include/linux/sched.h|4
kernel/user.c|4
16 files changed, 1444 insertions(+), 56 deletions(-)
diff -urN linux-2.6.11-mm1/fs/attr.c linux/fs/attr.c
--- linux-2.6.11-mm1/fs/attr.c 2005-03-04 14:06:21.0 -0500
+++ linux/fs/attr.c 2005-03-07 16:20:02.213242376 -0500
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -107,31 +107,8 @@
out:
return
[patch] inotify for 2.6.11, updated
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
> I greatly reworked much of the data structures and their interactions,
> to lay the groundwork for sanitizing the locking. I then, I hope,
> sanitized the locking. It looks right, I am happy. Comments welcome.
> I surely could of missed something. Maybe even something big.
>
> But, regardless, this release is a huge jump from the previous, fixing
> all known issues and greatly improving the locking.
Updated inotify, against 2.6.11, addressing hch's concerns (see other
thread).
Love,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
fs/Kconfig | 13
fs/Makefile |1
fs/attr.c| 33 -
fs/compat.c | 14
fs/file_table.c |3
fs/inode.c |4
fs/inotify.c | 1014 +++
fs/namei.c | 30 -
fs/open.c|6
fs/read_write.c | 15
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 236 ++
include/linux/inotify.h | 113 +
include/linux/sched.h|4
kernel/user.c|4
16 files changed, 1444 insertions(+), 56 deletions(-)
diff -urN linux-2.6.11/fs/attr.c linux/fs/attr.c
--- linux-2.6.11/fs/attr.c 2005-03-02 02:37:48.0 -0500
+++ linux/fs/attr.c 2005-03-07 16:10:46.854669712 -0500
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid & ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid & ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid & ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid & ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry->d_inode;
@@ -194,11 +171,9 @@
if (ia_valid & ATTR_SIZE)
up_write(>d_inode->i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11/fs/compat.c linux/fs/compat.c
--- linux-2.6.11/fs/compat.c2005-03-02 02:38:08.0 -0500
+++ linux/fs/compat.c 2005-03-07 16:10:14.152641176 -0500
@@ -36,7 +36,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -1233,9 +1233,15 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) > 0)
- dnotify_parent(file->f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) > 0) {
+ struct dentry *dentry = file->f_dentry;
+ if (type == READ)
+ fsnotify_access(dentry, dentry->d_inode,
+ dentry->d_name.name);
+ else
+ fsnotify_modify(dentry, dentry->d_inode,
+ dentry->d_name.name);
+ }
return ret;
}
diff
[patch] inotify for 2.6.11, updated
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of missed something. Maybe even something big.
But, regardless, this release is a huge jump from the previous, fixing
all known issues and greatly improving the locking.
Updated inotify, against 2.6.11, addressing hch's concerns (see other
thread).
Love,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
fs/Kconfig | 13
fs/Makefile |1
fs/attr.c| 33 -
fs/compat.c | 14
fs/file_table.c |3
fs/inode.c |4
fs/inotify.c | 1014 +++
fs/namei.c | 30 -
fs/open.c|6
fs/read_write.c | 15
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 236 ++
include/linux/inotify.h | 113 +
include/linux/sched.h|4
kernel/user.c|4
16 files changed, 1444 insertions(+), 56 deletions(-)
diff -urN linux-2.6.11/fs/attr.c linux/fs/attr.c
--- linux-2.6.11/fs/attr.c 2005-03-02 02:37:48.0 -0500
+++ linux/fs/attr.c 2005-03-07 16:10:46.854669712 -0500
@@ -10,7 +10,7 @@
#include linux/mm.h
#include linux/string.h
#include linux/smp_lock.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/fcntl.h
#include linux/quotaops.h
#include linux/security.h
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry-d_inode;
@@ -194,11 +171,9 @@
if (ia_valid ATTR_SIZE)
up_write(dentry-d_inode-i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11/fs/compat.c linux/fs/compat.c
--- linux-2.6.11/fs/compat.c2005-03-02 02:38:08.0 -0500
+++ linux/fs/compat.c 2005-03-07 16:10:14.152641176 -0500
@@ -36,7 +36,7 @@
#include linux/ctype.h
#include linux/module.h
#include linux/dirent.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/highuid.h
#include linux/sunrpc/svc.h
#include linux/nfsd/nfsd.h
@@ -1233,9 +1233,15 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) 0)
- dnotify_parent(file-f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) 0) {
+ struct dentry *dentry = file-f_dentry;
+ if (type == READ)
+ fsnotify_access(dentry, dentry-d_inode,
+
[patch] inotify for 2.6.11-mm1, updated
On Mon, 2005-03-07 at 01:19 +, Christoph Hellwig wrote:
Hi, hch.
I went ahead and implemented all of your suggestions, save for the ones
below where I have comments or disagree (see below). Most of your
comments were straightforward and I made the changes as you suggested.
See the following patch, against 2.6.11-mm1.
We will try out a write()-based interface. John is working on that.
I'd like Andrew and others to chime in on whether they really prefer
that to an ioctl?
might_sleep();
this one seems totally unrelated.
Eh? We did not add that. ;)
+ /* XXX: optimally, we should use GFP_KERNEL */
+ kevent = kmem_cache_alloc(event_cachep, GFP_ATOMIC);
indeed. having a new atomic memory allocation in every filesystem operation
sounds like a really bad idea.
Obviously we know that--the FIXME is there to signify as much. Anyhow,
the allocation is not on every operation, just every event.
+static struct miscdevice inotify_device = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = inotify,
+ .fops = inotify_fops,
+};
Should probably use the /dev/mem major.
Hrm, should we?
Also, the memory class stuff is all local to mem.c. For example, I
cannot get at /sys/class/mem. The misc. device stuff is exported.
+ default y
please don't default a new and experimental facility to y. In fact
default is totally overused.
I'd agree when we go to mainline, but for 2.6-mm more testing is
welcome. Besides, they don't have to use inotify. This just gets the
hooks compiled in.
I will definitely remove 'default' altogether before we go to mainline.
+#ifdef CONFIG_INOTIFY
+ struct list_headinotify_watches; /* watches on this inode */
+ spinlock_t inotify_lock; /* protects the watches list */
+#endif
do you really need a spinlock of your own in every inode? Inode memory
usage is a quite big problem.
Yah, we do. For a couple of reasons. First, by introducing our own
lock, we never need touch i_lock, and avoid that scalability mess
altogether. Second, and most importantly, i_lock is an outermost lock.
We need our lock to be nestable, because we walk inode - inotify_watch
- inotify_device. I've tried various rewrites to not need our own
lock. None are pretty.
I can offer to the inode memory worries me people that they can always
disable CONFIG_INOTIFY.
+/*
+ * fsnotify_change - notify_change event. file was modified and/or
metadata
+ * was changed.
+ */
+static inline void fsnotify_change(struct dentry *dentry, unsigned int
ia_valid)
this one is far too large to be inlined.
I'd agree, but it is only called from one place. And this way everything
stays in fsnotify.h.
Best,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
fs/Kconfig | 13
fs/Makefile |1
fs/attr.c| 33 -
fs/compat.c | 14
fs/file_table.c |3
fs/inode.c |4
fs/inotify.c | 1014 +++
fs/namei.c | 30 -
fs/open.c|6
fs/read_write.c | 15
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 236 ++
include/linux/inotify.h | 113 +
include/linux/sched.h|4
kernel/user.c|4
16 files changed, 1444 insertions(+), 56 deletions(-)
diff -urN linux-2.6.11-mm1/fs/attr.c linux/fs/attr.c
--- linux-2.6.11-mm1/fs/attr.c 2005-03-04 14:06:21.0 -0500
+++ linux/fs/attr.c 2005-03-07 16:20:02.213242376 -0500
@@ -10,7 +10,7 @@
#include linux/mm.h
#include linux/string.h
#include linux/smp_lock.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/fcntl.h
#include linux/quotaops.h
#include
Re: [patch] inotify for 2.6.11
On Maandag 07 März 2005 04:13, Albert Cahalan wrote:
Christoph Hellwig writes:
See the review I sent. Write is exactly the right interface for that kind
of thing. For comment vs argument either put the number first so we don't
have the problem of finding a delinator that isn't a valid filename, or
use '\0' as such.
That's just putrid. You've proposed an interface that
combines the worst of ASCII with the worst of binary.
I guess it's possible to avoid the need for passing the command at all.
The read data already has a format that mixes binary and variable-length
ascii data, so write could use a data structure similar (or even identical)
to the one used there, e.g.
struct inotify_watch_request {
__u32 mask; /* watch mask */
__u32 len; /* length (including nulls) of name */
char name[0]; /* stub for name */
};
This can replace both INOTIFY_WATCH and INOTIFY_IGNORE, if you simply
define a zero mask as a special value for ignore. FIONREAD is a
well-established interface, so I don't think it's necessary to replace
this.
Adding plain old syscalls is rather nice actually.
It's only a pain at first, while waiting for glibc
to catch up.
Yes, that might be a workable interface as well, but don't mix syscalls
with a misc device then. Instead, you might build on something like
futexfs, with syscalls replacing both ioctl and read:
int inotify_open(int flags);
int inotify_watch(int fd, unsigned mask, char *name);
int inotify_ignore(int fd, int wd);
int inotify_getevents(int fd, int max_events, struct inotify_event *);
Arnd
-
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: [patch] inotify for 2.6.11-mm1, updated
this one seems totally unrelated.
Eh? We did not add that. ;)
Sorry, I thought I saw a + somewhere there at the beggining of the line,
my fault.
Should probably use the /dev/mem major.
Hrm, should we?
Also, the memory class stuff is all local to mem.c. For example, I
cannot get at /sys/class/mem. The misc. device stuff is exported.
Why do you need the classdevice? I'm really not too eager about adding
tons of new misdevices now that we can route directly to individual majors
with cdev_add stuff. Especially when you're actually relying on class
device you should have your own one instead of relying on an onsolete
layer.
do you really need a spinlock of your own in every inode? Inode memory
usage is a quite big problem.
Yah, we do. For a couple of reasons. First, by introducing our own
lock, we never need touch i_lock, and avoid that scalability mess
altogether. Second, and most importantly, i_lock is an outermost lock.
We need our lock to be nestable, because we walk inode - inotify_watch
- inotify_device. I've tried various rewrites to not need our own
lock. None are pretty.
I can offer to the inode memory worries me people that they can always
disable CONFIG_INOTIFY.
They're bound to use distro kernels unfortunaly.. These people is anyone
doing big-scale fileserving at least.
+ if ((ret + (type == READ)) 0) {
+ struct dentry *dentry = file-f_dentry;
+ if (type == READ)
+ fsnotify_access(dentry, dentry-d_inode,
+ dentry-d_name.name);
+ else
+ fsnotify_modify(dentry, dentry-d_inode,
+ dentry-d_name.name);
+ }
Arguments two and three are still redudant.
Actually, you fixed that in read_write.c, just compat.c is still missing.
Looks like you forget to fix that one and didn't have a chance to compile-test
the 32bit compat layer?
-
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: [patch] inotify for 2.6.11-mm1, updated
On Tue, 2005-03-08 at 04:40 +, Christoph Hellwig wrote: Why do you need the classdevice? I'm really not too eager about adding tons of new misdevices now that we can route directly to individual majors with cdev_add stuff. Especially when you're actually relying on class device you should have your own one instead of relying on an onsolete layer. We have sysfs knobs and /sys/class/misc/inotify makes sense. Actually, you fixed that in read_write.c, just compat.c is still missing. Looks like you forget to fix that one and didn't have a chance to compile-test the 32bit compat layer? Yah, I just missed it. It is fixed in my tree. Thanks, Robert Love - 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: [patch] inotify for 2.6.11
On Mon, 2005-03-07 at 01:23 +, Christoph Hellwig wrote: > It means that every re3vision of inotify so far has been buggy in some > respect and ig got dropped from -mm again and again. It should get some > more testing there and not sent firectly for mainline. It was dropped from 2.6-mm once. Robert Love - 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: [patch] inotify for 2.6.11
Christoph Hellwig writes: > On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote: >> On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: >>> The user interface is still bogus. >> >> I presume you are talking about the ioctl. I have tried to engage you >> and others on what exactly you prefer instead. I have said that moving >> to a write interface is fine but I don't see how ut is _any_ better than >> the ioctl. Write is less typed, in fact, since we lose the command >> versus argument delineation. >> >> But if it is a anonymous decision, I'll switch it. Or take patches. ;-) >> It isn't a big deal. > > See the review I sent. Write is exactly the right interface for that kind > of thing. For comment vs argument either put the number first so we don't > have the problem of finding a delinator that isn't a valid filename, or > use '\0' as such. That's just putrid. You've proposed an interface that combines the worst of ASCII with the worst of binary. It is now well-established that ASCII interfaces are horribly slow. This one will be no exception... but with the '\0' in there, you have a binary interface. So, it's an evil hybrid. An ioctl() is a syscall with scope restricting it to a single fd. This is a fine user interface, not a bogus one. (keep 32-on-64 operation in mind to be polite) If you'd rather have a normal (global) system call though, that'll do too, likely leading to a bit more type checking in the glibc-provided headers. Adding plain old syscalls is rather nice actually. It's only a pain at first, while waiting for glibc to catch up. - 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: [patch] inotify for 2.6.11-mm1
Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > -mm has a list of inodes per superblock, which Andrew said he'd send > along to lines, you should probably use that one. That was merged a month or two ago. superblock.s_inodes, linked via inode.i_sb_list, protected by inode_lock. - 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: [patch] inotify for 2.6.11
On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote: > On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: > > > The user interface is still bogus. > > I presume you are talking about the ioctl. I have tried to engage you > and others on what exactly you prefer instead. I have said that moving > to a write interface is fine but I don't see how ut is _any_ better than > the ioctl. Write is less typed, in fact, since we lose the command > versus argument delineation. > > But if it is a anonymous decision, I'll switch it. Or take patches. ;-) > It isn't a big deal. See the review I sent. Write is exactly the right interface for that kind of thing. For comment vs argument either put the number first so we don't have the problem of finding a delinator that isn't a valid filename, or use '\0' as such. > > Also now version of it has stayed in -mm long enough because bad > > bugs pop up almost weekly. > > I don't follow this sentence. It means that every re3vision of inotify so far has been buggy in some respect and ig got dropped from -mm again and again. It should get some more testing there and not sent firectly for mainline. - 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: [patch] inotify for 2.6.11-mm1
> - if ((ret + (type == READ)) > 0)
> - dnotify_parent(file->f_dentry,
> - (type == READ) ? DN_ACCESS : DN_MODIFY);
> + if ((ret + (type == READ)) > 0) {
> + struct dentry *dentry = file->f_dentry;
> + if (type == READ)
> + fsnotify_access(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + else
> + fsnotify_modify(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + }
Both fsnotify_access and fsnotify_modify always get the second argument
as ->d_inode and third argument as ->d_name.name of the first, please fix
this blatantly stupid API.
> + fsnotify_close(dentry, inode, file->f_mode, dentry->d_name.name);
dito for thw second and last argument here.. In fact fsnotify_close
should just get a struct file *
> might_sleep();
this one seems totally unrelated.
> +/*
> + * struct inotify_device - represents an open instance of an inotify device
> + *
> + * This structure is protected by 'lock'.
> + */
> +struct inotify_device {
> + wait_queue_head_t wq; /* wait queue for i/o */
> + struct idr idr;/* idr mapping wd -> watch */
> + struct list_headevents; /* list of queued events */
> + struct list_headwatches;/* list of watches */
> + spinlock_t lock; /* protects this bad boy */
> + atomic_tcount; /* reference count */
> + struct user_struct *user; /* user who opened this dev */
> + unsigned intqueue_size; /* size of the queue (bytes) */
> + unsigned intevent_count;/* number of pending events */
> + unsigned intmax_events; /* maximum number of events */
> +};
> +/*
> + * kernel_event - create a new kernel event with the given parameters
> + */
> +static struct inotify_kernel_event * kernel_event(s32 wd, u32 mask, u32
> cookie,
> + const char *name)
> +{
> + struct inotify_kernel_event *kevent;
> +
> + /* XXX: optimally, we should use GFP_KERNEL */
> + kevent = kmem_cache_alloc(event_cachep, GFP_ATOMIC);
indeed. having a new atomic memory allocation in every filesystem operation
sounds like a really bad idea.
> + /* XXX: optimally, we should use GFP_KERNEL */
> + kevent->name = kmalloc(len, GFP_ATOMIC);
and two is even worse. A notification that fails under slight load
isn't that helpfull.
> +static inline int inotify_dev_has_events(struct inotify_device *dev)
> +{
> + return !list_empty(>events);
> +}
just remove this bit of obsfucation.
> + if (kevent->name)
> + kfree(kevent->name);
kfree(NULL) is just fine.
> +
> +repeat:
> + if (unlikely(!idr_pre_get(>idr, GFP_KERNEL)))
> + return -ENOSPC;
> + spin_lock(>lock);
> + ret = idr_get_new(>idr, watch, >wd);
> + spin_unlock(>lock);
> + if (ret == -EAGAIN) /* more memory is required, try again */
> + goto repeat;
what's the problem with a proper do { } while loop here?
> + watch->inode = inode;
> + spin_lock(_lock);
> + __iget(inode);
> + spin_unlock(_lock);
do you ever calls this when igrab() would fail? Don't think so,
and in that case I'd prefer you to use igrab instead of using these
lowlevel functions.
> +void inotify_dentry_parent_queue_event(struct dentry *dentry, u32 mask,
> +u32 cookie, const char *name)
> +{
> + struct dentry *parent;
> + struct inode *inode;
> +
> + spin_lock(>d_lock);
> + parent = dentry->d_parent;
> + inode = parent->d_inode;
> + if (!list_empty(>inotify_watches)) {
So what's protecting ->inotify_watches? There can be multiple dentries
so d_lock is not sufficient.
> +
> +/**
> + * inotify_super_block_umount - process watches on an unmounted fs
> + * @sb: the super_block of the filesystem in question
> + */
> +void inotify_super_block_umount(struct super_block *sb)
> +{
> + struct inode *inode;
> +
> + /* Walk the list of inodes and find those on this superblock */
> + spin_lock(_lock);
> + list_for_each_entry(inode, _in_use, i_list) {
> + struct inotify_watch *watch, *next;
> + struct list_head *watches;
> +
> + if (inode->i_sb != sb)
> + continue;
> +
> + /* for each watch, send IN_UNMOUNT and then remove it */
> + spin_lock(>inotify_lock);
> + watches = >inotify_watches;
> + list_for_each_entry_safe(watch, next, watches, i_list) {
> + struct inotify_device *dev = watch->dev;
> + spin_lock(>lock);
> + inotify_dev_queue_event(dev, watch, IN_UNMOUNT,0,NULL);
> +
Re: [patch] inotify for 2.6.11-mm1
- if ((ret + (type == READ)) 0)
- dnotify_parent(file-f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) 0) {
+ struct dentry *dentry = file-f_dentry;
+ if (type == READ)
+ fsnotify_access(dentry, dentry-d_inode,
+ dentry-d_name.name);
+ else
+ fsnotify_modify(dentry, dentry-d_inode,
+ dentry-d_name.name);
+ }
Both fsnotify_access and fsnotify_modify always get the second argument
as -d_inode and third argument as -d_name.name of the first, please fix
this blatantly stupid API.
+ fsnotify_close(dentry, inode, file-f_mode, dentry-d_name.name);
dito for thw second and last argument here.. In fact fsnotify_close
should just get a struct file *
might_sleep();
this one seems totally unrelated.
+/*
+ * struct inotify_device - represents an open instance of an inotify device
+ *
+ * This structure is protected by 'lock'.
+ */
+struct inotify_device {
+ wait_queue_head_t wq; /* wait queue for i/o */
+ struct idr idr;/* idr mapping wd - watch */
+ struct list_headevents; /* list of queued events */
+ struct list_headwatches;/* list of watches */
+ spinlock_t lock; /* protects this bad boy */
+ atomic_tcount; /* reference count */
+ struct user_struct *user; /* user who opened this dev */
+ unsigned intqueue_size; /* size of the queue (bytes) */
+ unsigned intevent_count;/* number of pending events */
+ unsigned intmax_events; /* maximum number of events */
+};
+/*
+ * kernel_event - create a new kernel event with the given parameters
+ */
+static struct inotify_kernel_event * kernel_event(s32 wd, u32 mask, u32
cookie,
+ const char *name)
+{
+ struct inotify_kernel_event *kevent;
+
+ /* XXX: optimally, we should use GFP_KERNEL */
+ kevent = kmem_cache_alloc(event_cachep, GFP_ATOMIC);
indeed. having a new atomic memory allocation in every filesystem operation
sounds like a really bad idea.
+ /* XXX: optimally, we should use GFP_KERNEL */
+ kevent-name = kmalloc(len, GFP_ATOMIC);
and two is even worse. A notification that fails under slight load
isn't that helpfull.
+static inline int inotify_dev_has_events(struct inotify_device *dev)
+{
+ return !list_empty(dev-events);
+}
just remove this bit of obsfucation.
+ if (kevent-name)
+ kfree(kevent-name);
kfree(NULL) is just fine.
+
+repeat:
+ if (unlikely(!idr_pre_get(dev-idr, GFP_KERNEL)))
+ return -ENOSPC;
+ spin_lock(dev-lock);
+ ret = idr_get_new(dev-idr, watch, watch-wd);
+ spin_unlock(dev-lock);
+ if (ret == -EAGAIN) /* more memory is required, try again */
+ goto repeat;
what's the problem with a proper do { } while loop here?
+ watch-inode = inode;
+ spin_lock(inode_lock);
+ __iget(inode);
+ spin_unlock(inode_lock);
do you ever calls this when igrab() would fail? Don't think so,
and in that case I'd prefer you to use igrab instead of using these
lowlevel functions.
+void inotify_dentry_parent_queue_event(struct dentry *dentry, u32 mask,
+u32 cookie, const char *name)
+{
+ struct dentry *parent;
+ struct inode *inode;
+
+ spin_lock(dentry-d_lock);
+ parent = dentry-d_parent;
+ inode = parent-d_inode;
+ if (!list_empty(inode-inotify_watches)) {
So what's protecting -inotify_watches? There can be multiple dentries
so d_lock is not sufficient.
+
+/**
+ * inotify_super_block_umount - process watches on an unmounted fs
+ * @sb: the super_block of the filesystem in question
+ */
+void inotify_super_block_umount(struct super_block *sb)
+{
+ struct inode *inode;
+
+ /* Walk the list of inodes and find those on this superblock */
+ spin_lock(inode_lock);
+ list_for_each_entry(inode, inode_in_use, i_list) {
+ struct inotify_watch *watch, *next;
+ struct list_head *watches;
+
+ if (inode-i_sb != sb)
+ continue;
+
+ /* for each watch, send IN_UNMOUNT and then remove it */
+ spin_lock(inode-inotify_lock);
+ watches = inode-inotify_watches;
+ list_for_each_entry_safe(watch, next, watches, i_list) {
+ struct inotify_device *dev = watch-dev;
+ spin_lock(dev-lock);
+ inotify_dev_queue_event(dev, watch, IN_UNMOUNT,0,NULL);
+ remove_watch(watch, dev);
+
Re: [patch] inotify for 2.6.11
On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote: On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: The user interface is still bogus. I presume you are talking about the ioctl. I have tried to engage you and others on what exactly you prefer instead. I have said that moving to a write interface is fine but I don't see how ut is _any_ better than the ioctl. Write is less typed, in fact, since we lose the command versus argument delineation. But if it is a anonymous decision, I'll switch it. Or take patches. ;-) It isn't a big deal. See the review I sent. Write is exactly the right interface for that kind of thing. For comment vs argument either put the number first so we don't have the problem of finding a delinator that isn't a valid filename, or use '\0' as such. Also now version of it has stayed in -mm long enough because bad bugs pop up almost weekly. I don't follow this sentence. It means that every re3vision of inotify so far has been buggy in some respect and ig got dropped from -mm again and again. It should get some more testing there and not sent firectly for mainline. - 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: [patch] inotify for 2.6.11-mm1
Christoph Hellwig [EMAIL PROTECTED] wrote: -mm has a list of inodes per superblock, which Andrew said he'd send along to lines, you should probably use that one. That was merged a month or two ago. superblock.s_inodes, linked via inode.i_sb_list, protected by inode_lock. - 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: [patch] inotify for 2.6.11
Christoph Hellwig writes: On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote: On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: The user interface is still bogus. I presume you are talking about the ioctl. I have tried to engage you and others on what exactly you prefer instead. I have said that moving to a write interface is fine but I don't see how ut is _any_ better than the ioctl. Write is less typed, in fact, since we lose the command versus argument delineation. But if it is a anonymous decision, I'll switch it. Or take patches. ;-) It isn't a big deal. See the review I sent. Write is exactly the right interface for that kind of thing. For comment vs argument either put the number first so we don't have the problem of finding a delinator that isn't a valid filename, or use '\0' as such. That's just putrid. You've proposed an interface that combines the worst of ASCII with the worst of binary. It is now well-established that ASCII interfaces are horribly slow. This one will be no exception... but with the '\0' in there, you have a binary interface. So, it's an evil hybrid. An ioctl() is a syscall with scope restricting it to a single fd. This is a fine user interface, not a bogus one. (keep 32-on-64 operation in mind to be polite) If you'd rather have a normal (global) system call though, that'll do too, likely leading to a bit more type checking in the glibc-provided headers. Adding plain old syscalls is rather nice actually. It's only a pain at first, while waiting for glibc to catch up. - 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: [patch] inotify for 2.6.11
On Mon, 2005-03-07 at 01:23 +, Christoph Hellwig wrote: It means that every re3vision of inotify so far has been buggy in some respect and ig got dropped from -mm again and again. It should get some more testing there and not sent firectly for mainline. It was dropped from 2.6-mm once. Robert Love - 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: [patch] inotify for 2.6.11
On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: > The user interface is still bogus. I presume you are talking about the ioctl. I have tried to engage you and others on what exactly you prefer instead. I have said that moving to a write interface is fine but I don't see how ut is _any_ better than the ioctl. Write is less typed, in fact, since we lose the command versus argument delineation. But if it is a anonymous decision, I'll switch it. Or take patches. ;-) It isn't a big deal. > Also now version of it has stayed in -mm long enough because bad > bugs pop up almost weekly. I don't follow this sentence. Best, Robert Love - 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: [patch] inotify for 2.6.11
On Fri, Mar 04, 2005 at 01:37:24PM -0500, Robert Love wrote: > Below is inotify, diffed against 2.6.11. > > I greatly reworked much of the data structures and their interactions, > to lay the groundwork for sanitizing the locking. I then, I hope, > sanitized the locking. It looks right, I am happy. Comments welcome. > I surely could of missed something. Maybe even something big. > > But, regardless, this release is a huge jump from the previous, fixing > all known issues and greatly improving the locking. > The user interface is still bogus. Also now version of it has stayed in -mm long enough because bad bugs pop up almost weekly. - 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: [patch] inotify for 2.6.11
On Fri, Mar 04, 2005 at 01:37:24PM -0500, Robert Love wrote: Below is inotify, diffed against 2.6.11. I greatly reworked much of the data structures and their interactions, to lay the groundwork for sanitizing the locking. I then, I hope, sanitized the locking. It looks right, I am happy. Comments welcome. I surely could of missed something. Maybe even something big. But, regardless, this release is a huge jump from the previous, fixing all known issues and greatly improving the locking. The user interface is still bogus. Also now version of it has stayed in -mm long enough because bad bugs pop up almost weekly. - 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: [patch] inotify for 2.6.11
On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: The user interface is still bogus. I presume you are talking about the ioctl. I have tried to engage you and others on what exactly you prefer instead. I have said that moving to a write interface is fine but I don't see how ut is _any_ better than the ioctl. Write is less typed, in fact, since we lose the command versus argument delineation. But if it is a anonymous decision, I'll switch it. Or take patches. ;-) It isn't a big deal. Also now version of it has stayed in -mm long enough because bad bugs pop up almost weekly. I don't follow this sentence. Best, Robert Love - 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: [patch] inotify for 2.6.11
On Fri, 04 Mar 2005 13:37:24 -0500, Robert Love <[EMAIL PROTECTED]> wrote: > Below is inotify, diffed against 2.6.11. > > I greatly reworked much of the data structures and their interactions, > to lay the groundwork for sanitizing the locking. I then, I hope, > sanitized the locking. It looks right, I am happy. Comments welcome. > I surely could of missed something. Maybe even something big. > > But, regardless, this release is a huge jump from the previous, fixing > all known issues and greatly improving the locking. > > Best, > > Robert Love Hey Robert, Are there plans of reworking the "generic" hooking infrastructure (fsnotify.h) to be more like the security hooking framework (+ stacking)? I think it'd be nice to be able to have a fs_notify struct of function pointers, point at the one's I've chosen to implement, and then register / unregister with the framework. Maybe this is an overly complicated approach, but these don't seem like they're generic hooks in anyway. + * include/linux/fs_notify.h - >generic< hooks for filesystem notification, to + * reduce in-source duplication from both >dnotify and inotify<. I guess I don't fully understand that comment. Just quickly glancing at it, all you've done is added a level of indirection and shifted the same redundant code from the VFS to fs_notify.h -- Please correct me if I'm wrong (not at all uncommon). As you already know, there's work being done on the audit subsystem that also needs notifications from the filesystem and would require yet another set of hooks. However, where we get notified might differ from where inotify and dnotify get notified and it seems like fs_notify is tailored specifically for inotify (and accommodates dnotify out of obligation) and openly implements the "generic" hooks it requires. Regardless, if this is the way it's going to be done. We'll expand fs_notify.h to meet our needs as well. Also, FYI: I just purchased the 2nd edition of your book, looking forward to reading it. -- - Timothy R. Chavez - 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: [patch] inotify for 2.6.11
On Fri, 2005-03-04 at 15:38 -0600, Timothy R. Chavez wrote: Hi, Mr. Chavez. > Are there plans of reworking the "generic" hooking infrastructure > (fsnotify.h) to be more like the security hooking framework (+ > stacking)? I think it'd be nice to be able to have a fs_notify struct > of function pointers, point at the one's I've chosen to implement, and > then register / unregister with the framework. Maybe this is an > overly complicated approach, but these don't seem like they're generic > hooks in anyway. Personally, I think it is overkill. I don't think we are going to have the myriad of file notification systems that we have for security layers (indeed, the goal is to have just inotify). That said, we could always make the layer more pluggable once inotify is in. I would not fight that. But, personally I don't see any real benefit, just additional complexity and overhead. > + * include/linux/fs_notify.h - >generic< hooks for filesystem notification, > to > + * reduce in-source duplication from both >dnotify and inotify<. > > I guess I don't fully understand that comment. Just quickly glancing > at it, all you've done is added a level of indirection and shifted the > same redundant code from the VFS to fs_notify.h -- Please correct me > if I'm wrong (not at all uncommon). No, you are right. The "generic" part is supposed to be what is in the VFS. E.g., the fsnotify_foo() calls are supposed to be the generic interface. The body of these calls, as you can see, is static code, a simple copy and cleanup of the inotify + dnotify hooks. The idea, spurred by Christoph Hellwig's suggestion, was to keep the VFS clean. Not make a super neat pluggable notification system. I think the layers ARE generic, though, in the sense that foonotify could probably drop some static code into fsnotify.h and work. > As you already know, there's work being done on the audit subsystem > that also needs notifications from the filesystem and would require > yet another set of hooks. However, where we get notified might differ > from where inotify and dnotify get notified and it seems like > fs_notify is tailored specifically for inotify (and accommodates > dnotify out of obligation) and openly implements the "generic" hooks > it requires. > > Regardless, if this is the way it's going to be done. We'll expand > fs_notify.h to meet our needs as well. If we end up duplicating stuff and making a big mess, then the audit layer and the notification layer should DEFINITELY look at merging and consolidating. But I think that we need to wait until one or the other gets more traction and into the mainline kernel. > Also, FYI: > I just purchased the 2nd edition of your book, looking forward to reading it. Great. Hope you enjoy it! ;-) Best, Robert Love - 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/
[patch] inotify for 2.6.11-mm1
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
Hey, Andrew.
> I greatly reworked much of the data structures and their interactions,
> to lay the groundwork for sanitizing the locking. I then, I hope,
> sanitized the locking. It looks right, I am happy. Comments welcome.
> I surely could of missed something. Maybe even something big.
>
> But, regardless, this release is a huge jump from the previous, fixing
> all known issues and greatly improving the locking.
Attached is inotify, replacing the current version of inotify in 2.6-mm.
The patch is diffed against 2.6.11-mm1, modulo the two inotify patches
already in-tree.
I'd like to start moving forward on this, the locking is greatly
improved, resolve any new issues, etc.
Please, apply.
Your humble servant,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
* inotify supports much finer grained events.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
fs/Kconfig | 13
fs/Makefile|1
fs/attr.c | 33 -
fs/compat.c| 14
fs/file_table.c|4
fs/inode.c |4
fs/inotify.c | 1013 +
fs/namei.c | 38 -
fs/open.c |9
fs/read_write.c| 24 -
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 235 ++
include/linux/inotify.h| 113 +
include/linux/sched.h |2
kernel/user.c |2
18 files changed, 1453 insertions(+), 62 deletions(-)
diff -urN linux-2.6.11-mm1/fs/attr.c linux/fs/attr.c
--- linux-2.6.11-mm1/fs/attr.c 2005-03-04 14:06:21.732297568 -0500
+++ linux/fs/attr.c 2005-03-04 13:27:05.560490128 -0500
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid & ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid & ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid & ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid & ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry->d_inode;
@@ -194,11 +171,9 @@
if (ia_valid & ATTR_SIZE)
up_write(>d_inode->i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11-mm1/fs/compat.c linux/fs/compat.c
--- linux-2.6.11-mm1/fs/compat.c2005-03-04 14:06:21.734297264 -0500
+++ linux/fs/compat.c 2005-03-04 13:27:05.562489824 -0500
@@ -36,7 +36,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -1233,9 +1233,15 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) > 0)
- dnotify_parent(file->f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) > 0) {
+ struct dentry *dentry = file->f_dentry;
+
[patch] inotify for 2.6.11
Below is inotify, diffed against 2.6.11.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of missed something. Maybe even something big.
But, regardless, this release is a huge jump from the previous, fixing
all known issues and greatly improving the locking.
Best,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
* inotify implements provides finger grained event control.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
drivers/char/Makefile |1
fs/Kconfig | 13
fs/Makefile|1
fs/attr.c | 33 -
fs/compat.c| 14
fs/file_table.c|4
fs/inode.c |4
fs/inotify.c | 1013 +
fs/namei.c | 38 -
fs/open.c |9
fs/read_write.c| 24 -
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 235 ++
include/linux/inotify.h| 113 +
include/linux/miscdevice.h |1
include/linux/sched.h |2
kernel/user.c |2
18 files changed, 1455 insertions(+), 62 deletions(-)
diff -urN linux-2.6.11/drivers/char/Makefile linux/drivers/char/Makefile
--- linux-2.6.11/drivers/char/Makefile 2005-03-02 02:38:26.0 -0500
+++ linux/drivers/char/Makefile 2005-03-04 13:11:27.414110056 -0500
@@ -9,6 +9,7 @@
obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o
+
obj-$(CONFIG_LEGACY_PTYS) += pty.o
obj-$(CONFIG_UNIX98_PTYS) += pty.o
obj-y += misc.o
diff -urN linux-2.6.11/fs/attr.c linux/fs/attr.c
--- linux-2.6.11/fs/attr.c 2005-03-02 02:37:48.0 -0500
+++ linux/fs/attr.c 2005-03-04 13:13:00.689929976 -0500
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid & ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid & ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid & ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid & ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid & ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry->d_inode;
@@ -194,11 +171,9 @@
if (ia_valid & ATTR_SIZE)
up_write(>d_inode->i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11/fs/compat.c linux/fs/compat.c
--- linux-2.6.11/fs/compat.c2005-03-02 02:38:08.0 -0500
+++ linux/fs/compat.c 2005-03-04 13:11:31.336513760 -0500
@@ -36,7 +36,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -1233,9 +1233,15 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) > 0)
- dnotify_parent(file->f_dentry,
- (type
[patch] inotify for 2.6.11
Below is inotify, diffed against 2.6.11.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of missed something. Maybe even something big.
But, regardless, this release is a huge jump from the previous, fixing
all known issues and greatly improving the locking.
Best,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
* inotify implements provides finger grained event control.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
drivers/char/Makefile |1
fs/Kconfig | 13
fs/Makefile|1
fs/attr.c | 33 -
fs/compat.c| 14
fs/file_table.c|4
fs/inode.c |4
fs/inotify.c | 1013 +
fs/namei.c | 38 -
fs/open.c |9
fs/read_write.c| 24 -
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 235 ++
include/linux/inotify.h| 113 +
include/linux/miscdevice.h |1
include/linux/sched.h |2
kernel/user.c |2
18 files changed, 1455 insertions(+), 62 deletions(-)
diff -urN linux-2.6.11/drivers/char/Makefile linux/drivers/char/Makefile
--- linux-2.6.11/drivers/char/Makefile 2005-03-02 02:38:26.0 -0500
+++ linux/drivers/char/Makefile 2005-03-04 13:11:27.414110056 -0500
@@ -9,6 +9,7 @@
obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o
+
obj-$(CONFIG_LEGACY_PTYS) += pty.o
obj-$(CONFIG_UNIX98_PTYS) += pty.o
obj-y += misc.o
diff -urN linux-2.6.11/fs/attr.c linux/fs/attr.c
--- linux-2.6.11/fs/attr.c 2005-03-02 02:37:48.0 -0500
+++ linux/fs/attr.c 2005-03-04 13:13:00.689929976 -0500
@@ -10,7 +10,7 @@
#include linux/mm.h
#include linux/string.h
#include linux/smp_lock.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/fcntl.h
#include linux/quotaops.h
#include linux/security.h
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry-d_inode;
@@ -194,11 +171,9 @@
if (ia_valid ATTR_SIZE)
up_write(dentry-d_inode-i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11/fs/compat.c linux/fs/compat.c
--- linux-2.6.11/fs/compat.c2005-03-02 02:38:08.0 -0500
+++ linux/fs/compat.c 2005-03-04 13:11:31.336513760 -0500
@@ -36,7 +36,7 @@
#include linux/ctype.h
#include linux/module.h
#include linux/dirent.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/highuid.h
#include linux/sunrpc/svc.h
[patch] inotify for 2.6.11-mm1
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
Hey, Andrew.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of missed something. Maybe even something big.
But, regardless, this release is a huge jump from the previous, fixing
all known issues and greatly improving the locking.
Attached is inotify, replacing the current version of inotify in 2.6-mm.
The patch is diffed against 2.6.11-mm1, modulo the two inotify patches
already in-tree.
I'd like to start moving forward on this, the locking is greatly
improved, resolve any new issues, etc.
Please, apply.
Your humble servant,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
* inotify supports much finer grained events.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
fs/Kconfig | 13
fs/Makefile|1
fs/attr.c | 33 -
fs/compat.c| 14
fs/file_table.c|4
fs/inode.c |4
fs/inotify.c | 1013 +
fs/namei.c | 38 -
fs/open.c |9
fs/read_write.c| 24 -
fs/super.c |2
include/linux/fs.h |8
include/linux/fsnotify.h | 235 ++
include/linux/inotify.h| 113 +
include/linux/sched.h |2
kernel/user.c |2
18 files changed, 1453 insertions(+), 62 deletions(-)
diff -urN linux-2.6.11-mm1/fs/attr.c linux/fs/attr.c
--- linux-2.6.11-mm1/fs/attr.c 2005-03-04 14:06:21.732297568 -0500
+++ linux/fs/attr.c 2005-03-04 13:27:05.560490128 -0500
@@ -10,7 +10,7 @@
#include linux/mm.h
#include linux/string.h
#include linux/smp_lock.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/fcntl.h
#include linux/quotaops.h
#include linux/security.h
@@ -107,31 +107,8 @@
out:
return error;
}
-
EXPORT_SYMBOL(inode_setattr);
-int setattr_mask(unsigned int ia_valid)
-{
- unsigned long dn_mask = 0;
-
- if (ia_valid ATTR_UID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_GID)
- dn_mask |= DN_ATTRIB;
- if (ia_valid ATTR_SIZE)
- dn_mask |= DN_MODIFY;
- /* both times implies a utime(s) call */
- if ((ia_valid (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME))
- dn_mask |= DN_ATTRIB;
- else if (ia_valid ATTR_ATIME)
- dn_mask |= DN_ACCESS;
- else if (ia_valid ATTR_MTIME)
- dn_mask |= DN_MODIFY;
- if (ia_valid ATTR_MODE)
- dn_mask |= DN_ATTRIB;
- return dn_mask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry-d_inode;
@@ -194,11 +171,9 @@
if (ia_valid ATTR_SIZE)
up_write(dentry-d_inode-i_alloc_sem);
- if (!error) {
- unsigned long dn_mask = setattr_mask(ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- }
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
+
return error;
}
diff -urN linux-2.6.11-mm1/fs/compat.c linux/fs/compat.c
--- linux-2.6.11-mm1/fs/compat.c2005-03-04 14:06:21.734297264 -0500
+++ linux/fs/compat.c 2005-03-04 13:27:05.562489824 -0500
@@ -36,7 +36,7 @@
#include linux/ctype.h
#include linux/module.h
#include linux/dirent.h
-#include linux/dnotify.h
+#include linux/fsnotify.h
#include linux/highuid.h
#include linux/sunrpc/svc.h
#include linux/nfsd/nfsd.h
@@ -1233,9 +1233,15 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) 0)
-
Re: [patch] inotify for 2.6.11
On Fri, 2005-03-04 at 15:38 -0600, Timothy R. Chavez wrote: Hi, Mr. Chavez. Are there plans of reworking the generic hooking infrastructure (fsnotify.h) to be more like the security hooking framework (+ stacking)? I think it'd be nice to be able to have a fs_notify struct of function pointers, point at the one's I've chosen to implement, and then register / unregister with the framework. Maybe this is an overly complicated approach, but these don't seem like they're generic hooks in anyway. Personally, I think it is overkill. I don't think we are going to have the myriad of file notification systems that we have for security layers (indeed, the goal is to have just inotify). That said, we could always make the layer more pluggable once inotify is in. I would not fight that. But, personally I don't see any real benefit, just additional complexity and overhead. + * include/linux/fs_notify.h - generic hooks for filesystem notification, to + * reduce in-source duplication from both dnotify and inotify. I guess I don't fully understand that comment. Just quickly glancing at it, all you've done is added a level of indirection and shifted the same redundant code from the VFS to fs_notify.h -- Please correct me if I'm wrong (not at all uncommon). No, you are right. The generic part is supposed to be what is in the VFS. E.g., the fsnotify_foo() calls are supposed to be the generic interface. The body of these calls, as you can see, is static code, a simple copy and cleanup of the inotify + dnotify hooks. The idea, spurred by Christoph Hellwig's suggestion, was to keep the VFS clean. Not make a super neat pluggable notification system. I think the layers ARE generic, though, in the sense that foonotify could probably drop some static code into fsnotify.h and work. As you already know, there's work being done on the audit subsystem that also needs notifications from the filesystem and would require yet another set of hooks. However, where we get notified might differ from where inotify and dnotify get notified and it seems like fs_notify is tailored specifically for inotify (and accommodates dnotify out of obligation) and openly implements the generic hooks it requires. Regardless, if this is the way it's going to be done. We'll expand fs_notify.h to meet our needs as well. If we end up duplicating stuff and making a big mess, then the audit layer and the notification layer should DEFINITELY look at merging and consolidating. But I think that we need to wait until one or the other gets more traction and into the mainline kernel. Also, FYI: I just purchased the 2nd edition of your book, looking forward to reading it. Great. Hope you enjoy it! ;-) Best, Robert Love - 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: [patch] inotify for 2.6.11
On Fri, 04 Mar 2005 13:37:24 -0500, Robert Love [EMAIL PROTECTED] wrote: Below is inotify, diffed against 2.6.11. I greatly reworked much of the data structures and their interactions, to lay the groundwork for sanitizing the locking. I then, I hope, sanitized the locking. It looks right, I am happy. Comments welcome. I surely could of missed something. Maybe even something big. But, regardless, this release is a huge jump from the previous, fixing all known issues and greatly improving the locking. Best, Robert Love Hey Robert, Are there plans of reworking the generic hooking infrastructure (fsnotify.h) to be more like the security hooking framework (+ stacking)? I think it'd be nice to be able to have a fs_notify struct of function pointers, point at the one's I've chosen to implement, and then register / unregister with the framework. Maybe this is an overly complicated approach, but these don't seem like they're generic hooks in anyway. + * include/linux/fs_notify.h - generic hooks for filesystem notification, to + * reduce in-source duplication from both dnotify and inotify. I guess I don't fully understand that comment. Just quickly glancing at it, all you've done is added a level of indirection and shifted the same redundant code from the VFS to fs_notify.h -- Please correct me if I'm wrong (not at all uncommon). As you already know, there's work being done on the audit subsystem that also needs notifications from the filesystem and would require yet another set of hooks. However, where we get notified might differ from where inotify and dnotify get notified and it seems like fs_notify is tailored specifically for inotify (and accommodates dnotify out of obligation) and openly implements the generic hooks it requires. Regardless, if this is the way it's going to be done. We'll expand fs_notify.h to meet our needs as well. Also, FYI: I just purchased the 2nd edition of your book, looking forward to reading it. snip -- - Timothy R. Chavez - 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: [patch] inotify for 2.6.11-rc3-mm2
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote: > Fix the damn locking, already. Fast as I can. Robert Love - 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: [patch] inotify for 2.6.11-rc3-mm2
On Fri, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote: > inotify, bitches /me does "pick a random function, find a race" again. > +/* > + * inode_add_watch - add a watch to the given inode > + * > + * Callers must hold dev->lock, because we call inode_find_dev(). > + */ > +static int inode_add_watch(struct inode *inode, struct inotify_watch *watch) [snip] > + list_add(>i_list, >inotify_data->watches); ^ ... and that is protected by what? > + > + return 0; Fix the damn locking, already. - 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: [patch] inotify for 2.6.11-rc3-mm2
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:
> Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
Updated patch, fixes a bug.
Robert Love
inotify, bitches
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
arch/sparc64/Kconfig | 13
drivers/char/Kconfig | 13
drivers/char/Makefile |2
drivers/char/inotify.c | 1053 +
drivers/char/misc.c| 14
fs/attr.c | 34 -
fs/compat.c| 14
fs/file_table.c|4
fs/inode.c |3
fs/namei.c | 38 -
fs/open.c |9
fs/read_write.c| 28 -
fs/super.c |3
include/linux/fs.h |7
include/linux/fsnotify.h | 235 ++
include/linux/inotify.h| 118 +
include/linux/miscdevice.h |5
include/linux/sched.h |2
kernel/user.c |2
19 files changed, 1522 insertions(+), 75 deletions(-)
diff -urN linux-2.6.10/arch/sparc64/Kconfig linux/arch/sparc64/Kconfig
--- linux-2.6.10/arch/sparc64/Kconfig 2004-12-24 16:35:25.0 -0500
+++ linux/arch/sparc64/Kconfig 2005-02-01 12:24:26.0 -0500
@@ -88,6 +88,19 @@
bool
default y
+config INOTIFY
+ bool "Inotify file change notification support"
+ default y
+ ---help---
+ Say Y here to enable inotify support and the /dev/inotify character
+ device. Inotify is a file change notification system and a
+ replacement for dnotify. Inotify fixes numerous shortcomings in
+ dnotify and introduces several new features. It allows monitoring
+ of both files and directories via a single open fd. Multiple file
+ events are supported.
+
+ If unsure, say Y.
+
config SMP
bool "Symmetric multi-processing support"
---help---
diff -urN linux-2.6.10/drivers/char/inotify.c linux/drivers/char/inotify.c
--- linux-2.6.10/drivers/char/inotify.c 1969-12-31 19:00:00.0 -0500
+++ linux/drivers/char/inotify.c2005-02-09 16:05:07.959265648 -0500
@@ -0,0 +1,1053 @@
+/*
+ * drivers/char/inotify.c - inode-based file event notifications
+ *
+ * Authors:
+ * John McCutchan <[EMAIL PROTECTED]>
+ * Robert Love <[EMAIL PROTECTED]>
+ *
+ * Copyright (C) 2005 John McCutchan
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static atomic_t inotify_cookie;
+static kmem_cache_t *watch_cachep;
+static kmem_cache_t *event_cachep;
+static kmem_cache_t *inode_data_cachep;
+
+static int sysfs_attrib_max_user_devices;
+static int sysfs_attrib_max_user_watches;
+static unsigned int sysfs_attrib_max_queued_events;
+
+/*
+ * struct inotify_device - represents an open instance of an inotify device
+ *
+ * For each inotify device, we need to keep track of the events queued on it,
+ * a list of the inodes that we are watching, and so on.
+ *
+ * This structure is protected by 'lock'. Lock ordering:
+ *
+ * dev->lock (protects dev)
+ * inode_lock (used to safely walk inode_in_use list)
+ * inode->i_lock (only needed for getting ref on inode_data)
+ */
+struct inotify_device {
+ wait_queue_head_t wait;
+ struct idr idr;
+ struct list_headevents;
+ struct list_headwatches;
+ spinlock_t lock;
+ unsigned intqueue_size;
+ unsigned intevent_count;
+ unsigned intmax_events;
+ struct user_struct *user;
+};
+
+struct inotify_watch {
+ s32 wd; /* watch descriptor */
+ u32 mask; /* event mask for this watch */
+ struct inode*inode; /* associated inode */
+ struct inotify_device *dev; /* associated device */
+ struct list_headd_list; /* entry in device's list */
+ struct list_headi_list; /* entry in inotify_data's list */
+};
+
+/*
+ * A list of these is attached to each instance of the driver. In read(), this
+ * this list is walked and all events that can fit in the buffer are returned.
+ */
+struct inotify_kernel_event {
+ struct inotify_eventevent;
+ struct list_headlist;
+ char*filename;
+};
+
Re: [patch] inotify for 2.6.11-rc3-mm2
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:
Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
Updated patch, fixes a bug.
Robert Love
inotify, bitches
Signed-off-by: Robert Love [EMAIL PROTECTED]
arch/sparc64/Kconfig | 13
drivers/char/Kconfig | 13
drivers/char/Makefile |2
drivers/char/inotify.c | 1053 +
drivers/char/misc.c| 14
fs/attr.c | 34 -
fs/compat.c| 14
fs/file_table.c|4
fs/inode.c |3
fs/namei.c | 38 -
fs/open.c |9
fs/read_write.c| 28 -
fs/super.c |3
include/linux/fs.h |7
include/linux/fsnotify.h | 235 ++
include/linux/inotify.h| 118 +
include/linux/miscdevice.h |5
include/linux/sched.h |2
kernel/user.c |2
19 files changed, 1522 insertions(+), 75 deletions(-)
diff -urN linux-2.6.10/arch/sparc64/Kconfig linux/arch/sparc64/Kconfig
--- linux-2.6.10/arch/sparc64/Kconfig 2004-12-24 16:35:25.0 -0500
+++ linux/arch/sparc64/Kconfig 2005-02-01 12:24:26.0 -0500
@@ -88,6 +88,19 @@
bool
default y
+config INOTIFY
+ bool Inotify file change notification support
+ default y
+ ---help---
+ Say Y here to enable inotify support and the /dev/inotify character
+ device. Inotify is a file change notification system and a
+ replacement for dnotify. Inotify fixes numerous shortcomings in
+ dnotify and introduces several new features. It allows monitoring
+ of both files and directories via a single open fd. Multiple file
+ events are supported.
+
+ If unsure, say Y.
+
config SMP
bool Symmetric multi-processing support
---help---
diff -urN linux-2.6.10/drivers/char/inotify.c linux/drivers/char/inotify.c
--- linux-2.6.10/drivers/char/inotify.c 1969-12-31 19:00:00.0 -0500
+++ linux/drivers/char/inotify.c2005-02-09 16:05:07.959265648 -0500
@@ -0,0 +1,1053 @@
+/*
+ * drivers/char/inotify.c - inode-based file event notifications
+ *
+ * Authors:
+ * John McCutchan [EMAIL PROTECTED]
+ * Robert Love [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2005 John McCutchan
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/idr.h
+#include linux/slab.h
+#include linux/fs.h
+#include linux/namei.h
+#include linux/poll.h
+#include linux/device.h
+#include linux/miscdevice.h
+#include linux/init.h
+#include linux/list.h
+#include linux/writeback.h
+#include linux/inotify.h
+
+#include asm/ioctls.h
+
+static atomic_t inotify_cookie;
+static kmem_cache_t *watch_cachep;
+static kmem_cache_t *event_cachep;
+static kmem_cache_t *inode_data_cachep;
+
+static int sysfs_attrib_max_user_devices;
+static int sysfs_attrib_max_user_watches;
+static unsigned int sysfs_attrib_max_queued_events;
+
+/*
+ * struct inotify_device - represents an open instance of an inotify device
+ *
+ * For each inotify device, we need to keep track of the events queued on it,
+ * a list of the inodes that we are watching, and so on.
+ *
+ * This structure is protected by 'lock'. Lock ordering:
+ *
+ * dev-lock (protects dev)
+ * inode_lock (used to safely walk inode_in_use list)
+ * inode-i_lock (only needed for getting ref on inode_data)
+ */
+struct inotify_device {
+ wait_queue_head_t wait;
+ struct idr idr;
+ struct list_headevents;
+ struct list_headwatches;
+ spinlock_t lock;
+ unsigned intqueue_size;
+ unsigned intevent_count;
+ unsigned intmax_events;
+ struct user_struct *user;
+};
+
+struct inotify_watch {
+ s32 wd; /* watch descriptor */
+ u32 mask; /* event mask for this watch */
+ struct inode*inode; /* associated inode */
+ struct inotify_device *dev; /* associated device */
+ struct list_headd_list; /* entry in device's list */
+ struct list_headi_list; /* entry in inotify_data's list */
+};
+
+/*
+ * A list of these is attached to each instance of the driver. In read(), this
+ * this list is walked and all events
Re: [patch] inotify for 2.6.11-rc3-mm2
On Fri, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote: inotify, bitches /me does pick a random function, find a race again. +/* + * inode_add_watch - add a watch to the given inode + * + * Callers must hold dev-lock, because we call inode_find_dev(). + */ +static int inode_add_watch(struct inode *inode, struct inotify_watch *watch) [snip] + list_add(watch-i_list, inode-inotify_data-watches); ^ ... and that is protected by what? + + return 0; Fix the damn locking, already. - 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: [patch] inotify for 2.6.11-rc3-mm2
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote: Fix the damn locking, already. Fast as I can. Robert Love - 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/
[patch] inotify for 2.6.11-rc3-mm2
On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote: > -inotify.patch > -inotify-fix_find_inode.patch > > I think my version is old, and it oopses. It is old. I have sent you multiple updates. ;-) Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify. This version has numerous optimizations, bug fixes, and clean ups. It introduces a generic notification layer to cleanly wrap both dnotify and inotify hooks in fs/. Pending is a data structure reorganization, to untangle some of the locking. Andrew, please apply! Robert Love inotify! inotify is intended to correct the deficiencies of dnotify, particularly its inability to scale and its terrible user interface: * dnotify requires the opening of one fd per each directory that you intend to watch. This quickly results in too many open files and pins removable media, preventing unmount. * dnotify is directory-based. You only learn about changes to directories. Sure, a change to a file in a directory affects the directory, but you are then forced to keep a cache of stat structures. * dnotify's interface to user-space is awful. Signals? inotify provides a more usable, simple, powerful solution to file change notification: * inotify's interface is a device node, not SIGIO. You open a single fd to the device node, which is select()-able. * inotify has an event that says "the filesystem that the item you were watching is on was unmounted." * inotify can watch directories or files. Inotify is currently used by Beagle (a desktop search infrastructure) and Gamin (a FAM replacement). Signed-off-by: Robert Love <[EMAIL PROTECTED]> arch/sparc64/Kconfig | 13 drivers/char/Kconfig | 13 drivers/char/Makefile |2 drivers/char/inotify.c | 1053 + fs/attr.c | 33 - fs/compat.c| 14 fs/file_table.c|4 fs/inode.c |3 fs/namei.c | 38 - fs/open.c |9 fs/read_write.c| 24 - fs/super.c |3 include/linux/fs.h |7 include/linux/fsnotify.h | 235 ++ include/linux/inotify.h| 118 + include/linux/miscdevice.h |1 include/linux/sched.h |2 kernel/user.c |2 18 files changed, 1511 insertions(+), 63 deletions(-) diff -urN linux-2.6.11-rc3-mm2/arch/sparc64/Kconfig linux-mm-inotify/arch/sparc64/Kconfig --- linux-2.6.11-rc3-mm2/arch/sparc64/Kconfig 2005-02-10 13:17:32.212175080 -0500 +++ linux-mm-inotify/arch/sparc64/Kconfig 2005-02-10 13:18:40.358815216 -0500 @@ -88,6 +88,19 @@ bool default y +config INOTIFY + bool "Inotify file change notification support" + default y + ---help--- + Say Y here to enable inotify support and the /dev/inotify character + device. Inotify is a file change notification system and a + replacement for dnotify. Inotify fixes numerous shortcomings in + dnotify and introduces several new features. It allows monitoring + of both files and directories via a single open fd. Multiple file + events are supported. + + If unsure, say Y. + config SMP bool "Symmetric multi-processing support" ---help--- diff -urN linux-2.6.11-rc3-mm2/drivers/char/inotify.c linux-mm-inotify/drivers/char/inotify.c --- linux-2.6.11-rc3-mm2/drivers/char/inotify.c 1969-12-31 19:00:00.0 -0500 +++ linux-mm-inotify/drivers/char/inotify.c 2005-02-10 13:18:40.360814912 -0500 @@ -0,0 +1,1053 @@ +/* + * drivers/char/inotify.c - inode-based file event notifications + * + * Authors: + * John McCutchan <[EMAIL PROTECTED]> + * Robert Love <[EMAIL PROTECTED]> + * + * Copyright (C) 2005 John McCutchan + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +static atomic_t inotify_cookie; +static kmem_cache_t *watch_cachep; +static kmem_cache_t *event_cachep; +static kmem_cache_t *inode_data_cachep; + +static int sysfs_attrib_max_user_devices; +static int sysfs_attrib_max_user_watches; +static unsigned int sysfs_attrib_max_queued_events; + +/* + * struct inotify_device - represents an open
[patch] inotify for 2.6.11-rc3-mm2
On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote: -inotify.patch -inotify-fix_find_inode.patch I think my version is old, and it oopses. It is old. I have sent you multiple updates. ;-) Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify. This version has numerous optimizations, bug fixes, and clean ups. It introduces a generic notification layer to cleanly wrap both dnotify and inotify hooks in fs/. Pending is a data structure reorganization, to untangle some of the locking. Andrew, please apply! Robert Love inotify! inotify is intended to correct the deficiencies of dnotify, particularly its inability to scale and its terrible user interface: * dnotify requires the opening of one fd per each directory that you intend to watch. This quickly results in too many open files and pins removable media, preventing unmount. * dnotify is directory-based. You only learn about changes to directories. Sure, a change to a file in a directory affects the directory, but you are then forced to keep a cache of stat structures. * dnotify's interface to user-space is awful. Signals? inotify provides a more usable, simple, powerful solution to file change notification: * inotify's interface is a device node, not SIGIO. You open a single fd to the device node, which is select()-able. * inotify has an event that says the filesystem that the item you were watching is on was unmounted. * inotify can watch directories or files. Inotify is currently used by Beagle (a desktop search infrastructure) and Gamin (a FAM replacement). Signed-off-by: Robert Love [EMAIL PROTECTED] arch/sparc64/Kconfig | 13 drivers/char/Kconfig | 13 drivers/char/Makefile |2 drivers/char/inotify.c | 1053 + fs/attr.c | 33 - fs/compat.c| 14 fs/file_table.c|4 fs/inode.c |3 fs/namei.c | 38 - fs/open.c |9 fs/read_write.c| 24 - fs/super.c |3 include/linux/fs.h |7 include/linux/fsnotify.h | 235 ++ include/linux/inotify.h| 118 + include/linux/miscdevice.h |1 include/linux/sched.h |2 kernel/user.c |2 18 files changed, 1511 insertions(+), 63 deletions(-) diff -urN linux-2.6.11-rc3-mm2/arch/sparc64/Kconfig linux-mm-inotify/arch/sparc64/Kconfig --- linux-2.6.11-rc3-mm2/arch/sparc64/Kconfig 2005-02-10 13:17:32.212175080 -0500 +++ linux-mm-inotify/arch/sparc64/Kconfig 2005-02-10 13:18:40.358815216 -0500 @@ -88,6 +88,19 @@ bool default y +config INOTIFY + bool Inotify file change notification support + default y + ---help--- + Say Y here to enable inotify support and the /dev/inotify character + device. Inotify is a file change notification system and a + replacement for dnotify. Inotify fixes numerous shortcomings in + dnotify and introduces several new features. It allows monitoring + of both files and directories via a single open fd. Multiple file + events are supported. + + If unsure, say Y. + config SMP bool Symmetric multi-processing support ---help--- diff -urN linux-2.6.11-rc3-mm2/drivers/char/inotify.c linux-mm-inotify/drivers/char/inotify.c --- linux-2.6.11-rc3-mm2/drivers/char/inotify.c 1969-12-31 19:00:00.0 -0500 +++ linux-mm-inotify/drivers/char/inotify.c 2005-02-10 13:18:40.360814912 -0500 @@ -0,0 +1,1053 @@ +/* + * drivers/char/inotify.c - inode-based file event notifications + * + * Authors: + * John McCutchan [EMAIL PROTECTED] + * Robert Love [EMAIL PROTECTED] + * + * Copyright (C) 2005 John McCutchan + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include linux/module.h +#include linux/kernel.h +#include linux/sched.h +#include linux/spinlock.h +#include linux/idr.h +#include linux/slab.h +#include linux/fs.h +#include linux/namei.h +#include linux/poll.h +#include linux/device.h +#include linux/miscdevice.h +#include linux/init.h +#include linux/list.h +#include linux/writeback.h +#include linux/inotify.h + +#include asm/ioctls.h + +static atomic_t inotify_cookie; +static kmem_cache_t *watch_cachep; +static kmem_cache_t *event_cachep; +static kmem_cache_t
[patch] inotify for 2.6.11-rc3-mm1
Andrew, Attached patch is an updated inotify for 2.6-mm. It replaces inotify.patch and inotify-fix_find_inode.patch. A bunch of improvements over the current patch: - Implements a generic notification layer, simple wrappers to keep the dnotify and inotify hooks in fs/ clean. In response to hch request. - Merge Mike's fix for the unmount race Viro spotted. - dget_parent optimization - SPARC64 configure entry - Cleanup, bug fixes, etc. Please, apply. Best, Robert Love inotify, an awesome file change notification thing! inotify is intended to correct the deficiencies of dnotify, particularly its inability to scale and its terrible user interface: * dnotify requires the opening of one fd per each directory that you intend to watch. This quickly results in too many open files and pins removable media, preventing unmount. * dnotify is directory-based. You only learn about changes to directories. Sure, a change to a file in a directory affects the directory, but you are then forced to keep a cache of stat structures. * dnotify's interface to user-space is awful. Signals? inotify provides a more usable, simple, powerful solution to file change notification: * inotify's interface is a device node, not SIGIO. You open a single fd to the device node, which is select()-able. * inotify has an event that says "the filesystem that the item you were watching is on was unmounted." * inotify can watch directories or files. Inotify is currently used by Beagle (a desktop search infrastructure) and Gamin (a FAM replacement). Signed-off-by: Robert Love <[EMAIL PROTECTED]> arch/sparc64/Kconfig | 13 drivers/char/Kconfig | 13 drivers/char/Makefile |2 drivers/char/inotify.c | 1072 + fs/attr.c | 32 - fs/compat.c| 14 fs/file_table.c|4 fs/inode.c |3 fs/namei.c | 38 - fs/open.c |9 fs/read_write.c| 24 - fs/super.c |3 include/linux/fs.h |7 include/linux/fsnotify.h | 235 + include/linux/inotify.h| 119 include/linux/miscdevice.h |1 include/linux/sched.h |2 kernel/user.c |2 18 files changed, 1530 insertions(+), 63 deletions(-) diff -urN linux-2.6.11-rc3-mm1/arch/sparc64/Kconfig linux-mm/arch/sparc64/Kconfig --- linux-2.6.11-rc3-mm1/arch/sparc64/Kconfig 2005-02-04 12:16:50.596563736 -0500 +++ linux-mm/arch/sparc64/Kconfig 2005-02-04 12:23:42.265980472 -0500 @@ -88,6 +88,19 @@ bool default y +config INOTIFY + bool "Inotify file change notification support" + default y + ---help--- + Say Y here to enable inotify support and the /dev/inotify character + device. Inotify is a file change notification system and a + replacement for dnotify. Inotify fixes numerous shortcomings in + dnotify and introduces several new features. It allows monitoring + of both files and directories via a single open fd. Multiple file + events are supported. + + If unsure, say Y. + config SMP bool "Symmetric multi-processing support" ---help--- diff -urN linux-2.6.11-rc3-mm1/drivers/char/inotify.c linux-mm/drivers/char/inotify.c --- linux-2.6.11-rc3-mm1/drivers/char/inotify.c 1969-12-31 19:00:00.0 -0500 +++ linux-mm/drivers/char/inotify.c 2005-02-04 12:23:42.268980016 -0500 @@ -0,0 +1,1072 @@ +/* + * Inode based directory notifications for Linux. + * + * Copyright (C) 2004 John McCutchan + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +static atomic_t inotify_cookie; +static kmem_cache_t *watch_cachep; +static kmem_cache_t *event_cachep; +static kmem_cache_t *inode_data_cachep; + +static int sysfs_attrib_max_user_devices; +static int sysfs_attrib_max_user_watches; +static unsigned int sysfs_attrib_max_queued_events; + +/* + * struct inotify_device - represents an open instance of an inotify device + * + * For each inotify device, we need to keep track of the events queued on it, + * a list of the
[patch] inotify for 2.6.11-rc3-mm1
Andrew, Attached patch is an updated inotify for 2.6-mm. It replaces inotify.patch and inotify-fix_find_inode.patch. A bunch of improvements over the current patch: - Implements a generic notification layer, simple wrappers to keep the dnotify and inotify hooks in fs/ clean. In response to hch request. - Merge Mike's fix for the unmount race Viro spotted. - dget_parent optimization - SPARC64 configure entry - Cleanup, bug fixes, etc. Please, apply. Best, Robert Love inotify, an awesome file change notification thing! inotify is intended to correct the deficiencies of dnotify, particularly its inability to scale and its terrible user interface: * dnotify requires the opening of one fd per each directory that you intend to watch. This quickly results in too many open files and pins removable media, preventing unmount. * dnotify is directory-based. You only learn about changes to directories. Sure, a change to a file in a directory affects the directory, but you are then forced to keep a cache of stat structures. * dnotify's interface to user-space is awful. Signals? inotify provides a more usable, simple, powerful solution to file change notification: * inotify's interface is a device node, not SIGIO. You open a single fd to the device node, which is select()-able. * inotify has an event that says the filesystem that the item you were watching is on was unmounted. * inotify can watch directories or files. Inotify is currently used by Beagle (a desktop search infrastructure) and Gamin (a FAM replacement). Signed-off-by: Robert Love [EMAIL PROTECTED] arch/sparc64/Kconfig | 13 drivers/char/Kconfig | 13 drivers/char/Makefile |2 drivers/char/inotify.c | 1072 + fs/attr.c | 32 - fs/compat.c| 14 fs/file_table.c|4 fs/inode.c |3 fs/namei.c | 38 - fs/open.c |9 fs/read_write.c| 24 - fs/super.c |3 include/linux/fs.h |7 include/linux/fsnotify.h | 235 + include/linux/inotify.h| 119 include/linux/miscdevice.h |1 include/linux/sched.h |2 kernel/user.c |2 18 files changed, 1530 insertions(+), 63 deletions(-) diff -urN linux-2.6.11-rc3-mm1/arch/sparc64/Kconfig linux-mm/arch/sparc64/Kconfig --- linux-2.6.11-rc3-mm1/arch/sparc64/Kconfig 2005-02-04 12:16:50.596563736 -0500 +++ linux-mm/arch/sparc64/Kconfig 2005-02-04 12:23:42.265980472 -0500 @@ -88,6 +88,19 @@ bool default y +config INOTIFY + bool Inotify file change notification support + default y + ---help--- + Say Y here to enable inotify support and the /dev/inotify character + device. Inotify is a file change notification system and a + replacement for dnotify. Inotify fixes numerous shortcomings in + dnotify and introduces several new features. It allows monitoring + of both files and directories via a single open fd. Multiple file + events are supported. + + If unsure, say Y. + config SMP bool Symmetric multi-processing support ---help--- diff -urN linux-2.6.11-rc3-mm1/drivers/char/inotify.c linux-mm/drivers/char/inotify.c --- linux-2.6.11-rc3-mm1/drivers/char/inotify.c 1969-12-31 19:00:00.0 -0500 +++ linux-mm/drivers/char/inotify.c 2005-02-04 12:23:42.268980016 -0500 @@ -0,0 +1,1072 @@ +/* + * Inode based directory notifications for Linux. + * + * Copyright (C) 2004 John McCutchan + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include linux/module.h +#include linux/kernel.h +#include linux/sched.h +#include linux/spinlock.h +#include linux/idr.h +#include linux/slab.h +#include linux/fs.h +#include linux/namei.h +#include linux/poll.h +#include linux/device.h +#include linux/miscdevice.h +#include linux/init.h +#include linux/list.h +#include linux/writeback.h +#include linux/inotify.h + +#include asm/ioctls.h + +static atomic_t inotify_cookie; +static kmem_cache_t *watch_cachep; +static kmem_cache_t *event_cachep; +static kmem_cache_t *inode_data_cachep; + +static int sysfs_attrib_max_user_devices; +static int sysfs_attrib_max_user_watches; +static unsigned int
[patch] inotify for 2.6.11-rc1-mm2
Hey, Andrew.
Below is an updated inotify patch (e.g. drop-in replacement for the
current patch) for 2.6.11-rc1-mm2.
Primary changes are bugfixes, cleanups, and the much-demanded
dynamic-length filename. Also, this fixes the reported regression in
directory operation performance. More cleanups, particularly with
locking, are still on my TODO.
Best,
Robert Love
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
drivers/char/Kconfig | 13
drivers/char/Makefile |2
drivers/char/inotify.c | 1074 +
fs/attr.c | 73 ++-
fs/file_table.c|7
fs/inode.c |3
fs/namei.c | 36 +
fs/open.c |5
fs/read_write.c| 29 +
fs/super.c |2
include/linux/fs.h |7
include/linux/inotify.h| 150 ++
include/linux/miscdevice.h |1
include/linux/sched.h |2
kernel/user.c |2
15 files changed, 1379 insertions(+), 27 deletions(-)
diff -urN linux-2.6.11-rc1-mm2/drivers/char/inotify.c
linux-inotify/drivers/char/inotify.c
--- linux-2.6.11-rc1-mm2/drivers/char/inotify.c 1969-12-31 19:00:00.0
-0500
+++ linux-inotify/drivers/char/inotify.c2005-01-20 16:29:10.058805240
-0500
@@ -0,0 +1,1074 @@
+/*
+ * Inode based directory notifications for Linux.
+ *
+ * Copyright (C) 2004 John McCutchan
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static atomic_t inotify_cookie;
+static kmem_cache_t *watch_cachep;
+static kmem_cache_t *event_cachep;
+static kmem_cache_t *inode_data_cachep;
+
+static int sysfs_attrib_max_user_devices;
+static int sysfs_attrib_max_user_watches;
+static unsigned int sysfs_attrib_max_queued_events;
+
+/*
+ * struct inotify_device - represents an open instance of an inotify device
+ *
+ * For each inotify device, we need to keep track of the events queued on it,
+ * a list of the inodes that we are watching, and so on.
+ *
+ * This structure is protected by 'lock'. Lock ordering:
+ *
+ * dev->lock (protects dev)
+ * inode_lock (used to safely walk inode_in_use list)
+ * inode->i_lock (only needed for getting ref on inode_data)
+ */
+struct inotify_device {
+ wait_queue_head_t wait;
+ struct idr idr;
+ struct list_headevents;
+ struct list_headwatches;
+ spinlock_t lock;
+ unsigned intqueue_size;
+ unsigned intevent_count;
+ unsigned intmax_events;
+ struct user_struct *user;
+};
+
+struct inotify_watch {
+ s32 wd; /* watch descriptor */
+ u32 mask;
+ struct inode*inode;
+ struct inotify_device *dev;
+ struct list_headd_list; /* device list */
+ struct list_headi_list; /* inode list */
+};
+
+/*
+ * A list of these is attached to each instance of the driver. In read(), this
+ * this list is walked and all events that can fit in the buffer are returned.
+ */
+struct inotify_kernel_event {
+ struct inotify_eventevent;
+ struct
[patch] inotify for 2.6.11-rc1-mm2
Hey, Andrew.
Below is an updated inotify patch (e.g. drop-in replacement for the
current patch) for 2.6.11-rc1-mm2.
Primary changes are bugfixes, cleanups, and the much-demanded
dynamic-length filename. Also, this fixes the reported regression in
directory operation performance. More cleanups, particularly with
locking, are still on my TODO.
Best,
Robert Love
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
drivers/char/Kconfig | 13
drivers/char/Makefile |2
drivers/char/inotify.c | 1074 +
fs/attr.c | 73 ++-
fs/file_table.c|7
fs/inode.c |3
fs/namei.c | 36 +
fs/open.c |5
fs/read_write.c| 29 +
fs/super.c |2
include/linux/fs.h |7
include/linux/inotify.h| 150 ++
include/linux/miscdevice.h |1
include/linux/sched.h |2
kernel/user.c |2
15 files changed, 1379 insertions(+), 27 deletions(-)
diff -urN linux-2.6.11-rc1-mm2/drivers/char/inotify.c
linux-inotify/drivers/char/inotify.c
--- linux-2.6.11-rc1-mm2/drivers/char/inotify.c 1969-12-31 19:00:00.0
-0500
+++ linux-inotify/drivers/char/inotify.c2005-01-20 16:29:10.058805240
-0500
@@ -0,0 +1,1074 @@
+/*
+ * Inode based directory notifications for Linux.
+ *
+ * Copyright (C) 2004 John McCutchan
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/idr.h
+#include linux/slab.h
+#include linux/fs.h
+#include linux/namei.h
+#include linux/poll.h
+#include linux/device.h
+#include linux/miscdevice.h
+#include linux/init.h
+#include linux/list.h
+#include linux/writeback.h
+#include linux/inotify.h
+
+#include asm/ioctls.h
+
+static atomic_t inotify_cookie;
+static kmem_cache_t *watch_cachep;
+static kmem_cache_t *event_cachep;
+static kmem_cache_t *inode_data_cachep;
+
+static int sysfs_attrib_max_user_devices;
+static int sysfs_attrib_max_user_watches;
+static unsigned int sysfs_attrib_max_queued_events;
+
+/*
+ * struct inotify_device - represents an open instance of an inotify device
+ *
+ * For each inotify device, we need to keep track of the events queued on it,
+ * a list of the inodes that we are watching, and so on.
+ *
+ * This structure is protected by 'lock'. Lock ordering:
+ *
+ * dev-lock (protects dev)
+ * inode_lock (used to safely walk inode_in_use list)
+ * inode-i_lock (only needed for getting ref on inode_data)
+ */
+struct inotify_device {
+ wait_queue_head_t wait;
+ struct idr idr;
+ struct list_headevents;
+ struct list_headwatches;
+ spinlock_t lock;
+ unsigned intqueue_size;
+ unsigned intevent_count;
+ unsigned intmax_events;
+ struct user_struct *user;
+};
+
+struct inotify_watch {
+ s32 wd; /* watch descriptor */
+ u32 mask;
+ struct inode*inode;
+ struct inotify_device *dev;
+ struct list_headd_list; /* device list */
+ struct list_headi_list; /* inode list */
+};
+
+/*
+ * A list of these is attached to each
