Bug 235307
| Summary: | hcid keeps trying despite hopeless situation | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ulrich Drepper <drepper> | ||||
| Component: | bluez-utils | Assignee: | David Woodhouse <dwmw2> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | 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: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Do you know where in the hcid code the loop was going on? Still a problem with recent bluez-utils updates? 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. 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.
Patch discussion at: http://thread.gmane.org/gmane.linux.bluez.devel/13777 |
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: