With kernel 2.6.31, restorecond uses 99% of my CPU.
This is because removing and readding the watch on utmp triggers inotify to
return an IN_IGNORED event for the old watch descriptor. If the watch gets
allocated the same wd when it is readded, then restorecond thinks that utmp
has changed, so removes and readds the watch again, potentially looping.
With kernel <= 2.6.30, this never happened, because the kernel didn't reuse
watch descriptors. So the IN_IGNORED event comes with a wd that is no
longer in use, and gets ignored. But kernel 2.6.31 reuses the same watch
descriptor.
This patch fixes that by ignoring inotify events whose only bit set is
IN_IGNORED.
Note: it is not clear to me why it is necessary to remove and readd the
watch in the first place.
Note for testing: you need to log in (to cause a change in utmp) after
starting restorecond to trigger the bug. In fact you need to log in twice
before the kernel reuses a watch descriptor.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
c588b44219