Bug 1274632

Summary: Sometimes hald lost removing notification of device due to leak of needless device information.
Product: Red Hat Enterprise Linux 6 Reporter: Yuki Shibuya <shibuya.yk>
Component: halAssignee: Richard Hughes <rhughes>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.8CC: shibuya.yk
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-06 10:55:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yuki Shibuya 2015-10-23 08:06:30 UTC
Description of problem:
When we repeat connect and disconnect of devices, sometimes removing notification of device is lost. Therefore if our application use libhal to get dbus notification from hald, our application can't get removing notification from dbus. I found that the reason of this problem is leak of needless device information.

Version-Release number of selected component (if applicable):

hal-0.5.14-14.el6.src.rpm

How reproducible:


Steps to Reproduce:
This problem was occurred in other distribution using hal-0.5.13. In RHEL 6, I found following patch in hal-0.5.14-14.el6.src.rpm.

hal-fix-segfault-while-probing.patch

I think that lost removing notification of device is fixed by above patch. However I think that leak of needless device information exist yet.

Actual results:

hald doesn't lost removing notification of device with leak of needless device information.

Expected results:

hald doesn't lost removing notification of device without leak of needless device information.

Additional info:

If hal catches a removing event of device from udev, it search device data from hash table by
using sysfs.path. In removing process, hal does not delete this device data from
hash table. The key of hash table is pointer of device sysfs.path, and this pointer is freed in
removing process. However, sometimes data of pointer address is not cleared immediately.
When same device is connected to machine again, device data is registered with previous freed address 
to hash table. In this case, if this address is reused, hal can't find device data of same device 
in removing process.

hal-fix-segfault-while-probing.patch

In above patch, the key of hash table is not address depended on device structure because
it is result of g_strdup of original address. However, the entry of device in hash tables is not
removed in removing process. I think that is leak of needless device.

In hal-0.5.13, I applied following patch and confirmed that this problem is fixed. In this patch, 
the entry that value is an empty list is removed in removing process.
I think this operation is need to hal-0.5.14 to avoid leak of needless device.

===============================================================================
diff -ur a/hald/device_store.c b/hald/device_store.c
--- a/hald/device_store.c       2008-08-10 22:50:10.000000000 +0900
+++ b/hald/device_store.c       2015-10-23 10:03:23.027666861 +0900
@@ -519,7 +519,11 @@
                HAL_DEBUG (("removing %p from (%s,%s)", device, key, value));
                devices = g_slist_remove_all (devices, device);
        }
-       g_hash_table_insert (index, (gpointer) value, devices);
+       if (g_slist_length (devices)) {
+               g_hash_table_insert (index, (gpointer) value, devices);
+       } else {
+               g_hash_table_remove (index, value);
+       }
 }

 #if GLIB_CHECK_VERSION (2,14,0)
===============================================================================

Comment 2 Jan Kurik 2017-12-06 10:55:56 UTC
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/