Previously, watch handle is saved in the udev databse. But in most cases,
the handle saved in the database is not updated. Especially, when udevd
is restarted, the inotify watch is restarted, but the database is not
updated.
Moreover, it is not necessary to save watch handle in the database, as
the handle is only take a effect during udevd is running, and the value
is meaningless when udevd is restarted.
So, this makes the opposite map from device ID to watch handle is saved
in /run/udev/watch as a symbolic link, and the handle not saved in the
database anymore.
Fixes#18525.
Some udev rule may erroneously set inotify watch on remove event.
For safety, silently ignore such an inotify watch enablement.
This also moves inotify watch enablement code to udev-event.c.
When udev rules are not applied correctly, then run program lists is
not perfect. So, udev_event_execute_run() later in
worker_process_device() should not be called.
When manager_exit() or manager_free() is called, the global variable in
udev-watch.c is not set '-1'. Of course, that is safe, as the event source
for the inotify fd is unref()ed in manager_exit() and manager_free().
But let's not store fd globally.
The maximum allowed value of the sysfs device index entry was limited to
16383 (2^14-1) to avoid the generation of unreasonable onboard interface
names.
For s390 the index can assume a value of up to 65535 (2^16-1) which is
now allowed depending on the new naming flag NAMING_16BIT_INDEX.
Larger index values are considered unreasonable and remain to be
ignored.
See kernel's rtm_to_fib_config() in net/ipv4/fib_frontend.c and
rtm_to_fib6_config() in net/ipv6/route.c.
Note that if both gateway and multipath routes are specified, then
kernel ignores gateway. So, strictly speaking, setting both gateway and
multipath routes is allowed by kernel. But such situation is mostly
user's misconfiguration. Let's refuse it.
Note that the conditions newly added in route_configure() are redundant,
as all static configurations are already verified in
route_section_verify(), and dynamic configurations do not set
nexthop_id or multipath routes. Just for safety.
Usually, removing non-existing addresses, routes, and etc, are safe.
However, when multiple interfaces lost their carriers simultaneously,
then manager_drop_routes() and manager_drop_nexthop() are called multiple
times. If a route with a blackhole nexthop is removed in that process,
the later removal requests of the route fail with -EINVAL, rathar
than -ESRCH, as the corresponding nexthop does not exist anymore.
So, let's not remove routes which managed by Manager more than once.
