watch_mount(), watch_sb(), and fsinfo() (again)

This doesn’t really seem like a big deal - novel and different mechanisms are a problem when they’re, well, novel and different. This is just a pipe, and unless I’ve missed something, it’s not requiring implementing anything.

I mean maybe netlink would be superior, but this seems nicely trivial. It’s not like they’re knocking up a netlink competitor, just using a trivial interface where they can.

I'm trying to make a generic notification system, with such properties as:
- messages can be longer than 8 bytes (say up to 128 bytes);
- message queueing requires no on-the-spot allocation and can be done from softirq/irq context or inside spinlocks;
- messages can come from a variety of sources (e.g. mount(2), add_key(2), keyctl(2), sb errors, usb notifications, ...);
- messages from different sources can be in the same queue;
- messages may need copying into multiple queues;
- filters can be easily employed;
- message loss reporting.

As has been mentioned, there are existing solutions:
- Netlink:
- would make the core VFS dependent on the networking code.
- would require GFP_ATOMIC message allocation at the point of generation (at least sometimes).
- doesn't seem to make it easy to do message loss reporting.
- epoll is for dealing with file descriptors - but we're not dealing with fd events.
- Not all sources I need notifications for can be addressed with fanotify.
- eventfd() has 8-byte messages.

Pipes have disadvantages too: no message loss reporting (I'm having to add it); pipe ring buffer metadata elements generally larger than common messages (might be able to optimise in future to store small data in the ring). Note that I didn't want to use pipes either: I was originally using a mappable chardev ring buffer but Linus said I had to use pipes instead.