Are there still platforms that implement atomic_read() with locks? Iwonder if there isn't a cheaper way for inodes to find out that they'renot involved in inotify.. maybe an inode function pointer that is onlyset to queue_event when watchers are around?

I wonder if its worth walking the watches as they're added and removedto calculate a total mask of what is being watched so that uninterestingevents can be immediately ignored without walking the watches.

I also wonder about adding references to an event from each device thatis watching the inode rather than queueing events on all the devices.If it only ever copies the full event to user space anyway, you'd justneed a series of pointers on the dev that hold references to arefcounted event. It looks like events are only ever dequeued from thedevice as they're walked from the head of the list so it doesn't seemlike the ability to remove an event from the middle would be missed.

It'd be nice to get some wait_event_interruptible() love to replace thehand-rolled _wait()s and schedule(). It could probably be folded intothe second loop, I imagine. I suspect that the signal_pending() casewants to return ERESTARTSYS like w_e_i() does.

> + nonseekable_open(inode, file);

While it doesn't return errors today, it might be nice to test anyway.

How about deferring this atomic_inc() until it's known if the event isgoing to be queued or not so that renames that have nothing to do withinotify don't bounce the cache line around? If it's *only* used toassciate two different events with a single rename maybe it'd be betterto roll some compound rename event.

I hope this helps. I, for one, would be thrilled to see dnotify deprecated.