Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 235307

Summary: hcid keeps trying despite hopeless situation
Product: [Fedora] Fedora Reporter: Ulrich Drepper <drepper>
Component: bluez-utilsAssignee: David Woodhouse <dwmw2>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bnocera
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-04 15:31:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
bluez-utils-better-inotify-error.patch none

Description Ulrich Drepper 2007-04-04 23:15:46 UTC
Description of problem:
Something changed in the SELinux policy in today update and hcid suddenly spits out

audit(1175727955.183:11107411): avc:  denied  { read } for  pid=1347 comm="hcid"
name="inotify" dev=inotifyfs ino=280 scontext=system_u:system_r:bluetooth_t:s0
tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir

Millions of lines, if you late it, and as fast as it can.  Yes, the policy
should be fixed, but the daemon should recognize that EPERM means there is no
hope and it should stop and not continue forever.

The machine basically ran in a busy loop and heated up and all this on a machine
with no bluetooth and no potential to have it (it's a xen domain).

Version-Release number of selected component (if applicable):
bluez-utils-3.9-2.fc7.x86_64

How reproducible:
once was enough, thank you

Steps to Reproduce:
1.perform today (Apr 4 2007) update
2.
3.
  
Actual results:
hcid loops, constantly producing the above violation

Expected results:
hcid should recognize EPERM and stop

Additional info:

Comment 1 Bastien Nocera 2007-09-20 09:53:04 UTC
Do you know where in the hcid code the loop was going on?
Still a problem with recent bluez-utils updates?

Comment 2 Ulrich Drepper 2007-10-04 14:57:56 UTC
I don't know what loop it was and I think at the very least the SELinux policy
has been fixed.  If we cannot determine this it's likely better to just close it
until it breaks again.

Comment 3 Bastien Nocera 2007-10-04 15:26:15 UTC
Created attachment 215931 [details]
bluez-utils-better-inotify-error.patch

Add better error checking, avoid infinite looping

This should fix it, although, without a reproducer, I'm not sure it's so
useful. I'll send it upstream for feedback.

Comment 4 Bastien Nocera 2007-10-04 15:31:46 UTC
Patch discussion at:
http://thread.gmane.org/gmane.linux.bluez.devel/13777