diff options
author | Martin Orr <martin@martinorr.name> | 2012-03-26 17:31:25 +0200 |
---|---|---|
committer | Eric Paris <eparis@redhat.com> | 2012-03-28 14:52:14 -0400 |
commit | 72ea5dec7cbbc1c62a0850eff3a7a91df42bc104 (patch) | |
tree | 521ec9fdc25822b4ad4a282b33ef17d1f424e075 /libselinux/src/compute_create.c | |
parent | 38e93bad1ffd99e698d24541793148e1da587389 (diff) | |
download | android_external_selinux-72ea5dec7cbbc1c62a0850eff3a7a91df42bc104.tar.gz android_external_selinux-72ea5dec7cbbc1c62a0850eff3a7a91df42bc104.tar.bz2 android_external_selinux-72ea5dec7cbbc1c62a0850eff3a7a91df42bc104.zip |
policycoreutils: Fix infinite loop with inotify on 2.6.31 kernels
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>
Diffstat (limited to 'libselinux/src/compute_create.c')
0 files changed, 0 insertions, 0 deletions