72ea5dec7c
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. The kernel has been fixed to not reuse watch descriptors. However as some kernels do reuse them, and its possible they may again, this patch fixes that by ignoring inotify events whose only bit set is IN_IGNORED. Signed-off-by: Martin Orr <martin@martinorr.name> Signed-off-by: Manoj Srivastava <srivasta@debian.org> Signed-off-by: Laurent Bigonville <bigon@debian.org> Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Dan Walsh <dwalsh@redhat.com> |
||
---|---|---|
.. | ||
Makefile | ||
org.selinux.Restorecond.service | ||
restorecond.8 | ||
restorecond.c | ||
restorecond.conf | ||
restorecond.desktop | ||
restorecond.h | ||
restorecond.init | ||
restorecond_user.conf | ||
stringslist.c | ||
stringslist.h | ||
user.c | ||
utmpwatcher.c | ||
utmpwatcher.h | ||
watch.c |