tree fa077536ebcfdca6712ced940fb7471185cc7cc2
parent a804a73c39e12016cb94da9bf2de84be50ed68ad
author Andrew Jeffery <andrew@aj.id.au> 1558076644 +0930
committer Andrew Jeffery <andrew@aj.id.au> 1558078711 +0930

dbus: Unref replies to avoid leaks

Testing showed that failing to free DBus message replies was leaking
800-900kiB per boot. After adding the appropriate unrefs, mboxd memory
consumption stayed stable at 71920kiB across multiple reboots of the
host.

The root cause was identified using a DBus capture of the host's IPMI
traffic during boot, then reducing the output to mboxd-specific messages
and turning them into commands that could be run with ipmitool. Adding
all of these commands to a script and running `pmap` between ipmitool
invocations showed the growth in memory usage across the "boot" process,
but this did not correlate with any particular set of commands to mboxd.
The lack of correlation lead to the hypothesis that we might be able to
reproduce by sending a lot of dbus messages, such as:

```
root@witherspoon:/tmp# for i in `seq 1 10000`; do \
busctl call xyz.openbmc_project.Hiomapd \
	/xyz/openbmc_project/Hiomapd \
	xyz.openbmc_project.Hiomapd.Protocol.V2 \
	GetInfo y 2; \
done
```

Spamming the daemon in this way demonstrated the growth in memory seen
during a regular boot process, confirming that just sending DBus
messages was enough.

Add the necessary unrefs for the replies at the end of each method
handler to ensure the replies are appropriately freed.

Testing and confirmation of the fix were performed on a Witherspoon
system.

Change-Id: If5fe7576aaca1be617181526bf64511ccee1dd9f
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>