Re: [PATCH v1] gdbus: Skip BLE random-address devices and remove broad match rule

Hi Xiuzhuo,

On Fri, Jul 10, 2026 at 3:55=E2=80=AFAM Xiuzhuo Shang
<[email protected]> wrote:
>
> Two related changes to reduce dbus-daemon load caused by high-rate
> BLE advertising signals:
>
> 1. In parse_properties(), skip creating a GDBusProxy for Device1
>    objects whose AddressType is 'random' (BLE-only devices). Each
>    proxy registers a per-device PropertiesChanged watch via
>    g_dbus_add_properties_watch(); with hundreds of BLE peripherals
>    advertising simultaneously, this results in hundreds of match rules
>    and dbus-daemon routing thousands of RSSI PropertiesChanged signals
>    per second to ofono, none of which ofono processes. The
>    AddressType property is available in the InterfacesAdded dict at
>    the time parse_properties() is called, so the check is reliable
>    and race-free.
>
>    BR/EDR devices (AddressType=3D'public') are unaffected: their proxies
>    are created as before, and the property_changed callback continues
>    to receive Paired and ServicesResolved updates needed for HFP/HSP.
>
> 2. In g_dbus_client_new_full(), remove the broad
>    type=3D'signal',sender=3D<service>,path_namespace=3D<path> match rule.
>    This rule was the sole feeder for the signal_func path in
>    message_filter(). ofono never calls g_dbus_client_set_signal_watch()
>    so signal_func is always NULL; the broad rule therefore served no
>    purpose and caused dbus-daemon to route every bluetoothd signal
>    (including all BLE PropertiesChanged) to ofono.
>
>    InterfacesAdded and InterfacesRemoved are already covered by the
>    precise watches registered via g_dbus_add_signal_watch() earlier in
>    g_dbus_client_new_full(), so no functionality is lost.

Looks like this is on ofono though, why are you chaning the BlueZ side?

> Together these two changes prevent dbus-daemon from routing BLE
> advertising PropertiesChanged signals to ofono entirely, eliminating
> the dbus-daemon memory growth and bluetoothd socket backpressure seen
> after hours of BLE scanning.
>
> Signed-off-by: Xiuzhuo Shang <[email protected]>
> ---
>  gdbus/client.c | 46 ++++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 38 insertions(+), 8 deletions(-)
>
> diff --git a/gdbus/client.c b/gdbus/client.c
> index 48711ae8..dd3c17f9 100644
> --- a/gdbus/client.c
> +++ b/gdbus/client.c
> @@ -937,6 +937,44 @@ static void parse_properties(GDBusClient *client, co=
nst char *path,
>         if (g_str_equal(interface, DBUS_INTERFACE_PROPERTIES) =3D=3D TRUE=
)
>                 return;
>
> +       /*
> +        * Skip BLE devices (AddressType=3D'random') to avoid registering=
 a
> +        * per-device PropertiesChanged watch for every advertising BLE
> +        * peripheral. ofono only needs BR/EDR devices for HFP/HSP; the
> +        * high-rate RSSI PropertiesChanged signals from BLE scanners cau=
se
> +        * dbus-daemon memory bloat and socket backpressure in bluetoothd=
.
> +        *
> +        * The AddressType property is present in the InterfacesAdded dic=
t
> +        * (iter) at this point, so it can be checked before proxy_new().
> +        */
> +       if (g_str_equal(interface, "org.bluez.Device1") =3D=3D TRUE) {
> +               DBusMessageIter props, entry;
> +               DBusMessageIter copy =3D *iter;
> +
> +               if (dbus_message_iter_get_arg_type(&copy) =3D=3D DBUS_TYP=
E_ARRAY) {
> +                       dbus_message_iter_recurse(&copy, &props);
> +                       while (dbus_message_iter_get_arg_type(&props) =3D=
=3D
> +                                               DBUS_TYPE_DICT_ENTRY) {
> +                               const char *key;
> +                               dbus_message_iter_recurse(&props, &entry)=
;
> +                               dbus_message_iter_get_basic(&entry, &key)=
;
> +                               if (g_str_equal(key, "AddressType") =3D=
=3D TRUE) {
> +                                       DBusMessageIter var;
> +                                       const char *addr_type;
> +                                       dbus_message_iter_next(&entry);
> +                                       dbus_message_iter_recurse(&entry,=
 &var);
> +                                       dbus_message_iter_get_basic(&var,
> +                                                               &addr_typ=
e);
> +                                       if (g_str_equal(addr_type,
> +                                                       "random") =3D=3D =
TRUE)
> +                                               return;
> +                                       break;
> +                               }
> +                               dbus_message_iter_next(&props);
> +                       }
> +               }
> +       }

Nack, not going to introduce BlueZ specific logic into gdbus like
this. If we need to rate limit the RSSI notification then it means
it's not suitable to be a property, but I believe we have a threshold
logic in the likes of device_set_rssi_with_delta so perhaps we shall
check why it is not working in your case.

>         proxy =3D proxy_lookup(client, path, interface);
>         if (proxy) {
>                 update_properties(proxy, iter, FALSE);
> @@ -1255,14 +1293,6 @@ GDBusClient *g_dbus_client_new_full(DBusConnection=
 *connection,
>                                                 "InterfacesRemoved",
>                                                 interfaces_removed,
>                                                 client, NULL);
> -       g_ptr_array_add(client->match_rules, g_strdup_printf("type=3D'sig=
nal',"
> -                               "sender=3D'%s',path_namespace=3D'%s'",
> -                               client->service_name, client->base_path))=
;
> -
> -       for (i =3D 0; i < client->match_rules->len; i++) {
> -               modify_match(client->dbus_conn, "AddMatch",
> -                               g_ptr_array_index(client->match_rules, i)=
);
> -       }

This perhaps has a merit, but I can't recall what this watch was for.
Is it matching every signal from the sender? It seems it was introduce
before the watch infra existed, so if we can safely remove it we can
perhaps remove the whole client-->match_rules.

>         return g_dbus_client_ref(client);
>  }
> --
> 2.43.0
>


--=20
Luiz Augusto von Dentz