No description
c588b44219
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> |
||
|---|---|---|
| checkpolicy | ||
| libselinux | ||
| libsemanage | ||
| libsepol | ||
| policycoreutils | ||
| scripts | ||
| sepolgen | ||
| .gitignore | ||
| Makefile | ||