Bug 68303

Summary: [PATCH] bunch of trivial patches
Product: dbus Reporter: Chengwei Yang <chengwei.yang.cn>
Component: coreAssignee: Havoc Pennington <hp>
Status: RESOLVED FIXED QA Contact:
Severity: trivial    
Priority: medium CC: chengwei.yang.cn, ralf.habacker
Version: 1.5Keywords: patch
Hardware: Other   
OS: All   
Whiteboard: review-
i915 platform: i915 features:
Attachments: [PATCH 01/10] Cleanup: polish verbose mode checking
[PATCH 02/10] Cleanup: polish inotify backend
[PATCH 03/10] Move function to the right place where it supposed to be used (merged)
[PATCH 04/10] DBusWatch: dbus_watch_get_socket deprecated the other two APIs
[PATCH 05/10] Cleanup: simplify assertion check
[PATCH 06/10] dbus-server.c: use the new _dbus_atomic_get function
[PATCH 07/10] dbus-server.c: trace all server ref count change events
[PATCH 08/10] Cleanup: remove temporary error
[PATCH 09/10] Fix reference doc in comments (merged)
[PATCH 10/10] Align behavior with document
[PATCH v2 1/7] Cleanup: polish verbose mode checking
[PATCH v2 2/7] Cleanup: polish inotify backend
[PATCH v2 3/7] Cleanup: simplify assertion check
[PATCH v2 4/7] Make sure the debug output ref is correct
[PATCH v2 5/7] Fix comment about atomic operations
[PATCH v2 6/7] Fix debug output about dbus server ref count
[PATCH v2 7/7] Align behavior with document

Description Chengwei Yang 2013-08-20 06:24:44 UTC
When crossing the dbus source code, I found there are several places to be polished. So here are some patches for them, not any big problem but small polishments.
Comment 1 Chengwei Yang 2013-08-20 07:40:56 UTC
Created attachment 84302 [details] [review]
[PATCH 01/10] Cleanup: polish verbose mode checking
Comment 2 Chengwei Yang 2013-08-20 07:42:32 UTC
Created attachment 84303 [details] [review]
[PATCH 02/10] Cleanup: polish inotify backend
Comment 3 Chengwei Yang 2013-08-20 07:42:59 UTC
Created attachment 84304 [details] [review]
[PATCH 03/10] Move function to the right place where it supposed to  be used (merged)
Comment 4 Chengwei Yang 2013-08-20 07:43:27 UTC
Created attachment 84305 [details] [review]
[PATCH 04/10] DBusWatch: dbus_watch_get_socket deprecated the other  two APIs
Comment 5 Chengwei Yang 2013-08-20 07:43:50 UTC
Created attachment 84306 [details] [review]
[PATCH 05/10] Cleanup: simplify assertion check
Comment 6 Chengwei Yang 2013-08-20 07:44:16 UTC
Created attachment 84307 [details] [review]
[PATCH 06/10] dbus-server.c: use the new _dbus_atomic_get function
Comment 7 Chengwei Yang 2013-08-20 07:44:38 UTC
Created attachment 84308 [details] [review]
[PATCH 07/10] dbus-server.c: trace all server ref count change  events
Comment 8 Chengwei Yang 2013-08-20 07:45:01 UTC
Created attachment 84309 [details] [review]
[PATCH 08/10] Cleanup: remove temporary error
Comment 9 Chengwei Yang 2013-08-20 07:45:21 UTC
Created attachment 84310 [details] [review]
[PATCH 09/10] Fix reference doc in comments (merged)
Comment 10 Chengwei Yang 2013-08-20 07:45:45 UTC
Created attachment 84311 [details] [review]
[PATCH 10/10] Align behavior with document
Comment 11 Simon McVittie 2013-08-22 17:33:51 UTC
Comment on attachment 84302 [details] [review]
[PATCH 01/10] Cleanup: polish verbose mode checking

Review of attachment 84302 [details] [review]:
-----------------------------------------------------------------

One logical change per commit, please, so I don't have to say "yes to this bit, no to this bit" so often :-)

::: bus/selinux.c
@@ +936,4 @@
>  void
>  bus_selinux_id_table_print (DBusHashTable *service_table)
>  {
> +#if defined (DBUS_ENABLE_VERBOSE_MODE) && defined (HAVE_SELINUX)

Sure

@@ +961,5 @@
>   */
>  static void
>  bus_avc_print_stats (void)
>  {
> +#if defined (DBUS_ENABLE_VERBOSE_MODE) && defined (HAVE_SELINUX)

This is also OK

@@ +1001,4 @@
>        sidput (bus_sid);
>        bus_sid = SECSID_WILD;
>  
> +      bus_avc_print_stats ();

and this

::: bus/signals.c
@@ +123,5 @@
>   */
>  static char*
>  match_rule_to_string (BusMatchRule *rule)
>  {
> +#ifdef DBUS_ENABLE_VERBOSE_MODE

I'm not so sure about this stuff with match_rule_to_string() - dbus_free() can't just be inlined like the rest. I'd prefer to leave this as it is.
Comment 12 Simon McVittie 2013-08-22 17:37:15 UTC
Comment on attachment 84303 [details] [review]
[PATCH 02/10] Cleanup: polish inotify backend

Review of attachment 84303 [details] [review]:
-----------------------------------------------------------------

::: bus/dir-watch-inotify.c
@@ +63,2 @@
>  
> +  pid = _dbus_getpid ();

Couldn't this, and the declaration of pid, even move into the {} with the kill()?

@@ +68,5 @@
>    else if (!ret)
>      _dbus_verbose ("Error reading inotify event: buffer too small\n");
> +  else
> +    {
> +      _dbus_verbose ("Sending SIGHUP signal on reception of %d inotify event(s)\n", (int)ret);

I'd prefer "%ld" and (long) ret, since (s)size_t is often larger than int.
Comment 13 Simon McVittie 2013-08-22 17:38:26 UTC
Comment on attachment 84304 [details] [review]
[PATCH 03/10] Move function to the right place where it supposed to  be used (merged)

Review of attachment 84304 [details] [review]:
-----------------------------------------------------------------

Yes
Comment 14 Simon McVittie 2013-08-22 17:43:47 UTC
Comment on attachment 84305 [details] [review]
[PATCH 04/10] DBusWatch: dbus_watch_get_socket deprecated the other  two APIs

Review of attachment 84305 [details] [review]:
-----------------------------------------------------------------

This API isn't amazingly well thought-out, but I'm not sure this patch really makes it much better. Fundamentally, we're not tracking enough information to get this right (see the FIXME).

The problem is that on Unix files, pipes, sockets etc. are all small integers chosen from the same "space" (you can never have a pipe and a socket that are both fd 23), but on Windows, C runtime file descriptors (including pipes) are small integers, and Winsock sockets are a potentially-overlapping set of small integers. On Windows, it is possible to have a pipe or file that is fd 23, and a Winsock socket that is *also* 23.
Comment 15 Simon McVittie 2013-08-22 17:46:10 UTC
Comment on attachment 84306 [details] [review]
[PATCH 05/10] Cleanup: simplify assertion check

Review of attachment 84306 [details] [review]:
-----------------------------------------------------------------

::: bus/driver.c
@@ +884,4 @@
>    /* The message signature has already been checked for us,
>     * so let's just assert it's right.
>     */
> +  _dbus_assert (dbus_message_iter_get_arg_type (&iter) == DBUS_TYPE_ARRAY);

OK

@@ +1925,5 @@
>    _dbus_verbose ("Driver got a method call: %s\n", name);
>  
>    /* security checks should have kept this from getting here */
> +  _dbus_assert (dbus_message_get_sender (message) != NULL ||
> +                strcmp (name, "Hello") == 0);

OK

::: dbus/dbus-connection.c
@@ +354,1 @@
>    _dbus_atomic_inc (&filter->refcount);

No, this one issues twice as many costly atomic operations.

::: dbus/dbus-memory.c
@@ +706,4 @@
>        check_guards (memory, TRUE);
>        if (memory)
>          {
> +          _dbus_assert (_dbus_atomic_get (&n_blocks_outstanding) >= 1);

Also an extra atomic operation.

@@ +719,4 @@
>    if (memory) /* we guarantee it's safe to free (NULL) */
>      {
>  #ifdef DBUS_ENABLE_EMBEDDED_TESTS
> +      _dbus_assert (_dbus_atomic_get (&n_blocks_outstanding) >= 1);

Also here.

::: dbus/dbus-object-tree.c
@@ +1006,4 @@
>  static DBusObjectSubtree *
>  _dbus_object_subtree_ref (DBusObjectSubtree *subtree)
>  {
> +  _dbus_assert (_dbus_atomic_get (&subtree->refcount) > 0);

And here.

::: dbus/dbus-server.c
@@ +112,4 @@
>                          const DBusServerVTable *vtable,
>                          const DBusString       *address)
>  {
> +  _dbus_assert (_dbus_atomic_get (&server->refcount) == 0);

And here.

::: dbus/dbus-string.c
@@ +335,4 @@
>     * disable asserts to profile, you don't get this destroyer
>     * of profiles.
>     */
> +#if defined (DBUS_ENABLE_EMBEDDED_TESTS) && !defined (DBUS_DISABLE_ASSERT)

OK
Comment 16 Simon McVittie 2013-08-22 17:49:20 UTC
Comment on attachment 84307 [details] [review]
[PATCH 06/10] dbus-server.c: use the new _dbus_atomic_get function

Review of attachment 84307 [details] [review]:
-----------------------------------------------------------------

No, I did this intentionally. Doing more atomic operations than we need to is expensive.

::: dbus/dbus-server.c
@@ +694,4 @@
>  
>    _dbus_return_val_if_fail (server != NULL, NULL);
>  
> +  old_refcount = _dbus_atomic_get (&server->refcount);

No, this issues an extra atomic operation on a normal code path. I know the "undo" is an extra atomic op, but it's on a "can't happen" path anyway.
Comment 17 Simon McVittie 2013-08-22 17:50:55 UTC
Comment on attachment 84308 [details] [review]
[PATCH 07/10] dbus-server.c: trace all server ref count change  events

Review of attachment 84308 [details] [review]:
-----------------------------------------------------------------

::: dbus/dbus-server.c
@@ +117,5 @@
>    server->vtable = vtable;
>    _dbus_atomic_inc (&server->refcount);
> +  _dbus_server_trace_ref (server, 0,
> +                          _dbus_atomic_get (&server->refcount),
> +                          "init_base");

I would rather avoid the double-atomic here.

@@ +776,4 @@
>    _dbus_return_if_fail (server != NULL);
>    _dbus_return_if_fail (_dbus_atomic_get (&server->refcount) > 0);
>  
> +  dbus_server_ref (server);

Hmm, maybe. I'll have to look at this bit in more detail later.
Comment 18 Simon McVittie 2013-08-22 17:54:20 UTC
Comment on attachment 84309 [details] [review]
[PATCH 08/10] Cleanup: remove temporary error

Review of attachment 84309 [details] [review]:
-----------------------------------------------------------------

No, in all these cases, error might be NULL, so we can't look at *error. We really do need the "inner error" pattern - it's a common idiom in GLib too.
Comment 19 Simon McVittie 2013-08-22 17:54:40 UTC
Comment on attachment 84310 [details] [review]
[PATCH 09/10] Fix reference doc in comments (merged)

Review of attachment 84310 [details] [review]:
-----------------------------------------------------------------

OK
Comment 20 Simon McVittie 2013-08-22 17:55:53 UTC
Comment on attachment 84311 [details] [review]
[PATCH 10/10] Align behavior with document

Review of attachment 84311 [details] [review]:
-----------------------------------------------------------------

What practical effect does this have?

Whenever the documentation and code disagree, there are two possibilities: either the code is wrong, or the documentation is wrong. Which will break fewest otherwise-correct programs?
Comment 21 Chengwei Yang 2013-08-23 09:31:34 UTC
Created attachment 84503 [details] [review]
[PATCH v2 1/7] Cleanup: polish verbose mode checking
Comment 22 Chengwei Yang 2013-08-23 09:58:30 UTC
Created attachment 84504 [details] [review]
[PATCH v2 2/7] Cleanup: polish inotify backend
Comment 23 Chengwei Yang 2013-08-23 09:59:13 UTC
Created attachment 84505 [details] [review]
[PATCH v2 3/7] Cleanup: simplify assertion check
Comment 24 Chengwei Yang 2013-08-23 10:09:35 UTC
Created attachment 84507 [details] [review]
[PATCH v2 4/7] Make sure the debug output ref is correct
Comment 25 Chengwei Yang 2013-08-23 10:10:04 UTC
Created attachment 84508 [details] [review]
[PATCH v2 5/7] Fix comment about atomic operations
Comment 26 Chengwei Yang 2013-08-23 10:10:38 UTC
Created attachment 84509 [details] [review]
[PATCH v2 6/7] Fix debug output about dbus server ref count
Comment 27 Chengwei Yang 2013-08-23 10:11:08 UTC
Created attachment 84510 [details] [review]
[PATCH v2 7/7] Align behavior with document
Comment 28 Simon McVittie 2013-08-23 10:58:01 UTC
Comment on attachment 84507 [details] [review]
[PATCH v2 4/7] Make sure the debug output ref is correct

Review of attachment 84507 [details] [review]:
-----------------------------------------------------------------

No, this is not desirable, and can even produce misleading debug output.

If two threads unref the connection at the same time, then the debug output will either look like

    unref: 6 -> 5
    unref: 5 -> 4

which is fine, or

    unref: 5 -> 4
    unref: 6 -> 5

which is slightly confusing until you realize that the first thread unreffed second, but printed its debug output first. However,

    unref: 5 -> 4
    unref: 6 -> 4

is worse: it makes it look as though our atomic operations didn't even work correctly.

(Also, it doubles the number of atomic ops.)
Comment 29 Simon McVittie 2013-08-23 10:59:09 UTC
Comment on attachment 84508 [details] [review]
[PATCH v2 5/7] Fix comment about atomic operations

Review of attachment 84508 [details] [review]:
-----------------------------------------------------------------

Makes sense now, thanks.
Comment 30 Simon McVittie 2013-08-23 11:10:21 UTC
Comment on attachment 84510 [details] [review]
[PATCH v2 7/7] Align behavior with document

Review of attachment 84510 [details] [review]:
-----------------------------------------------------------------

There are no callers where address_problem_type and _field don't have the same NULL'ness, and there shouldn't be.

Since the intention seems to be that you pass either type-and-field, or just other, I think this should either have something like:

_dbus_assert ((address_problem_other == NULL) != (address_problem_type == NULL));
_dbus_assert ((address_problem_type == NULL) == (address_problem_field == NULL));

or be two functions:

void _dbus_set_bad_address (DBusError *error, const char *problem);
void _dbus_set_bad_address_missing_field (DBusError *error, const char *type, const char *field);
Comment 31 Simon McVittie 2013-08-23 12:13:11 UTC
I merged most of this.
Comment 32 Chengwei Yang 2013-08-23 13:10:07 UTC
(In reply to comment #30)
> Comment on attachment 84510 [details] [review] [review]
> [PATCH v2 7/7] Align behavior with document
> 
> Review of attachment 84510 [details] [review] [review]:
> -----------------------------------------------------------------
> 
> There are no callers where address_problem_type and _field don't have the
> same NULL'ness, and there shouldn't be.
> 
> Since the intention seems to be that you pass either type-and-field, or just
> other, I think this should either have something like:
> 
> _dbus_assert ((address_problem_other == NULL) != (address_problem_type ==
> NULL));
> _dbus_assert ((address_problem_type == NULL) == (address_problem_field ==
> NULL));

Yeah, but I think once we do this, we need update the document.

> 
> or be two functions:
> 
> void _dbus_set_bad_address (DBusError *error, const char *problem);
> void _dbus_set_bad_address_missing_field (DBusError *error, const char
> *type, const char *field);

This is seems more complicated.

Given that this is an internal API and it's not much better if we change it, I agree to just left as it is or the original patch is acceptable given that all the user of this function are well done.
Comment 33 Simon McVittie 2013-08-27 13:42:05 UTC
Comment on attachment 84503 [details] [review]
[PATCH v2 1/7] Cleanup: polish verbose mode checking

applied
Comment 34 Simon McVittie 2013-08-27 13:43:10 UTC
Comment on attachment 84505 [details] [review]
[PATCH v2 3/7] Cleanup: simplify assertion check

applied
Comment 35 Simon McVittie 2013-08-27 13:43:46 UTC
Comment on attachment 84508 [details] [review]
[PATCH v2 5/7] Fix comment about atomic operations

applied
Comment 36 Simon McVittie 2013-08-27 13:44:21 UTC
Comment on attachment 84509 [details] [review]
[PATCH v2 6/7] Fix debug output about dbus server ref count

applied
Comment 37 Simon McVittie 2014-01-17 16:08:35 UTC
Some fixed in 1.7.x, remainder are WONTFIX.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.